Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
4531
Off-topic / Re: Doctor Who
« on September 5th, 2012, 08:43 AM »
Something tells me I should really rewatch that scene...
4532
The Pub / Re: Controversial idea: post moderation on by default
« on September 5th, 2012, 08:42 AM »
Just my humble opinion...
- I've always said that I'm not too fond of the fact that the post moderation flag depends exclusively on moderation rules. This makes it impossible to add an 'Unapprove' button to the posts, among other things.
- I have no qualms with post moderation being set by default (mostly as per the above), but it would be cleaner if such a rule was adopted (if not already written?): "For a user's first 10 posts, approve the post only if it has no link in it. If it has a link, unapprove it. If a user's post is moderated and approved, remove the moderation flag from them."
Basically, the idea is that if a user goes through their first post with a link with no issues, it's unlikely they're a spammer...
Also, we should tell them that at post time. (Not at submit time or never ;))
- I've always said that I'm not too fond of the fact that the post moderation flag depends exclusively on moderation rules. This makes it impossible to add an 'Unapprove' button to the posts, among other things.
- I have no qualms with post moderation being set by default (mostly as per the above), but it would be cleaner if such a rule was adopted (if not already written?): "For a user's first 10 posts, approve the post only if it has no link in it. If it has a link, unapprove it. If a user's post is moderated and approved, remove the moderation flag from them."
Basically, the idea is that if a user goes through their first post with a link with no issues, it's unlikely they're a spammer...
Also, we should tell them that at post time. (Not at submit time or never ;))
4533
The Pub / Re: Logo Madness
« on September 4th, 2012, 11:53 PM »
Never saw that, I'm afraid... Does it still do it?
Oh, BTW, the French version has a new logo. This time it's the monochrome version. I find it... Interesting. I also did a lozenge vesion, it's interesting too, but a bit too busy[1]
Oh, BTW, the French version has a new logo. This time it's the monochrome version. I find it... Interesting. I also did a lozenge vesion, it's interesting too, but a bit too busy[1]
| 1. | It even says "Wedge Forum" instead of the usual "Wedge"... :wow:), I won't bother posting it for now. |
4534
Features / Re: New revs - Public comments
« on September 4th, 2012, 11:44 PM »
Sorry about the media_unseen error... It was a failed copy & paste operation, I'm afraid.
Okay, I'm nearly done with the @media query conversion process. The one thing that bothers me is that IE6/7 still don't support these, actually they do (thanks to a plugin I added on top of them), but it doesn't have any point because these browsers use a table layout for the sidebar, and thus I can't manipulate the sidebar into getting floated to the bottom. All I can do is (1) remove the padding around the window, (2) hide the sidebar entirely.
I'm not sure people would like solution 2, so I'll just stick to 1 for now.
(Uh, I could have posted this on the right topic, but it has too many unread posts right now... I try not to focus on answering posts when I'm busy with a backlog of code...)
Okay, I'm nearly done with the @media query conversion process. The one thing that bothers me is that IE6/7 still don't support these, actually they do (thanks to a plugin I added on top of them), but it doesn't have any point because these browsers use a table layout for the sidebar, and thus I can't manipulate the sidebar into getting floated to the bottom. All I can do is (1) remove the padding around the window, (2) hide the sidebar entirely.
I'm not sure people would like solution 2, so I'll just stick to 1 for now.
(Uh, I could have posted this on the right topic, but it has too many unread posts right now... I try not to focus on answering posts when I'm busy with a backlog of code...)
4535
The Pub / Re: Great start !
« on September 4th, 2012, 02:54 PM »
Never had any problems with Firefox, in fact Opera is my main testing platform and Firefox my second (I always have a copy of it running in the background -- especially since they implemented lazy loading of tabs, which is nice for a heavy user like me.)
I'm going crazy after all the work that's left to do just to release a private alpha... And I swear, I'm not adding any new features for now, nor am I planning to! My priority really is to fix the current outstanding bugs and be done with it... :-(
I'm going crazy after all the work that's left to do just to release a private alpha... And I swear, I'm not adding any new features for now, nor am I planning to! My priority really is to fix the current outstanding bugs and be done with it... :-(
4536
Features / Re: New revs
« on September 4th, 2012, 02:49 PM »
rev 1681
(14 files +2-3, 12kb)
* Rewrote window resizing code. Instead of JavaScript (which always added about 150 bytes per page), we'll now be relying entirely on media queries, which feel more natural in this case. Moved the responsive CSS from index.css to a new extra.css file (well, it's new for Weaving), although it's totally not needed so I may change that in the future. Doesn't work in IE6 for now, and sub-skins have yet to be committed (it's working, but it's not ready yet.) (index.template.php, index.css, sections.css)
@ There are a few caveats involved in media queries compared to my earlier #responsive implementation -- first of all, extending a class inside a media query is impossible, because you can't target it outside of a media query (@media keywords don't act like a selector themselves). Also, #responsive targets any changes in the main div's width, while @media will only see changes to the window/tab width, so you need to take sidebar width into account, and if for instance you change its width without changing the window size, the sidebar won't be moved. Finally, precedence order is no longer the same, as @media selectors don't change priority in source order, so you'll have to either be very careful with sub-skins, or use tricks like targeting an upper ID first inside the media query. This is what I'm doing right now, may change if it causes other issues: the media query targets 'body #edge' for instance, so if you override #edge later in your sub-skins, the media query won't get in your way. You will, however, have to target #wedge #edge as well if you need to rewrite #edge in a sub-skin's media query. As unlikely as it sounds.
* Due to the above, reverted the window.weres test in sbox.js to use window.eves instead, and made sure that eves is always set (i.e. if there are no delayed events, it's set to 1 regardless.) (Subs-Template.php, index.template.php, sbox.js)
* Deleted whitespace from all menu code. While it was 'nice' to have these properly indented, it's still my #1 goal to save bandwidth, especially at the beginning of a page. If a HTML page isn't gzipped, it can save up to 1.5KB on admin pages! Plus, it saves us a CSS hack akin to text-space-collapse, and it makes it easier to just skip to the proper content when you're examining the source code. (GenericMenu.template.php, index.template.php, index.css)
* Renamed latest-packages to latest-plugins. Even though the feature is disabled for now, it's no reason not to update the terminology... (other/xml/latest-plugins.php, Packages.template.php)
* Added support for newest version of the skin selector plugin. (Themes.php)
* Commented out the alert/confirm variations, as I'm not using them for now, and we might as well saved the compiled space... This will be for a future version, I'm afraid. (script.js)
* Changed extra.firefox[-2].css prefix to common.*, so that the inline-block fix is also applied to non-main CSS files. Eh. (*.firefox[-2].css)
! Fixed a couple of issues with the error log layout. (Errors.template.php, mana.css)
- Deleted duplicate hacks from IE6 and IE7 specific files. (extra.ie6.css, extra.ie7.css, editor.ie[-7].css)
* Commenazi. (Poll.php, index.css)
(14 files +2-3, 12kb)
* Rewrote window resizing code. Instead of JavaScript (which always added about 150 bytes per page), we'll now be relying entirely on media queries, which feel more natural in this case. Moved the responsive CSS from index.css to a new extra.css file (well, it's new for Weaving), although it's totally not needed so I may change that in the future. Doesn't work in IE6 for now, and sub-skins have yet to be committed (it's working, but it's not ready yet.) (index.template.php, index.css, sections.css)
@ There are a few caveats involved in media queries compared to my earlier #responsive implementation -- first of all, extending a class inside a media query is impossible, because you can't target it outside of a media query (@media keywords don't act like a selector themselves). Also, #responsive targets any changes in the main div's width, while @media will only see changes to the window/tab width, so you need to take sidebar width into account, and if for instance you change its width without changing the window size, the sidebar won't be moved. Finally, precedence order is no longer the same, as @media selectors don't change priority in source order, so you'll have to either be very careful with sub-skins, or use tricks like targeting an upper ID first inside the media query. This is what I'm doing right now, may change if it causes other issues: the media query targets 'body #edge' for instance, so if you override #edge later in your sub-skins, the media query won't get in your way. You will, however, have to target #wedge #edge as well if you need to rewrite #edge in a sub-skin's media query. As unlikely as it sounds.
* Due to the above, reverted the window.weres test in sbox.js to use window.eves instead, and made sure that eves is always set (i.e. if there are no delayed events, it's set to 1 regardless.) (Subs-Template.php, index.template.php, sbox.js)
* Deleted whitespace from all menu code. While it was 'nice' to have these properly indented, it's still my #1 goal to save bandwidth, especially at the beginning of a page. If a HTML page isn't gzipped, it can save up to 1.5KB on admin pages! Plus, it saves us a CSS hack akin to text-space-collapse, and it makes it easier to just skip to the proper content when you're examining the source code. (GenericMenu.template.php, index.template.php, index.css)
* Renamed latest-packages to latest-plugins. Even though the feature is disabled for now, it's no reason not to update the terminology... (other/xml/latest-plugins.php, Packages.template.php)
* Added support for newest version of the skin selector plugin. (Themes.php)
* Commented out the alert/confirm variations, as I'm not using them for now, and we might as well saved the compiled space... This will be for a future version, I'm afraid. (script.js)
* Changed extra.firefox[-2].css prefix to common.*, so that the inline-block fix is also applied to non-main CSS files. Eh. (*.firefox[-2].css)
! Fixed a couple of issues with the error log layout. (Errors.template.php, mana.css)
- Deleted duplicate hacks from IE6 and IE7 specific files. (extra.ie6.css, extra.ie7.css, editor.ie[-7].css)
* Commenazi. (Poll.php, index.css)
4537
Features / Re: Plugin revs
« on September 4th, 2012, 01:21 PM »
rev 46
(1 file, 2kb)
* [theme_selector] Updated JS code to be much, much shorter. Instead of relying on a theme variable that is only valid for the current session, it will now call the skin selector page implicitly and thus set the new skin permanently. The skin selector page will then redirect back to the current page. (ThemeSelector.php)
@ Note that this relies on a change that will be in the next Wedge commit.
(1 file, 2kb)
* [theme_selector] Updated JS code to be much, much shorter. Instead of relying on a theme variable that is only valid for the current session, it will now call the skin selector page implicitly and thus set the new skin permanently. The skin selector page will then redirect back to the current page. (ThemeSelector.php)
@ Note that this relies on a change that will be in the next Wedge commit.
4538
The Pub / Re: Getting ready for an alpha release: CSS fixes
« on September 4th, 2012, 09:16 AM »
So... No opinions from anyone? Even those who suggested going for HTML arrows? :whistle:
4539
The Pub / Re: Getting ready for an alpha release: CSS fixes
« on September 3rd, 2012, 07:51 AM »
(Back from a BBQ party that lasted all day at my place... 30 people there, what a mess >_< My girlfriend definitely has a lot of cousins I never heard from until now.) (Some of them quite on the cute side, mwahah.) (Don't mind me.)
b isn't much of a problem. After all, thinking about it, a theme's quality is determined by the viewer, not by its author. It's up to the author to ensure it works best for users. Having media queries make their life more complicated, is trumped by the fact that users won't get that dreaded FOUC.
HTML arrows are more of a problem. Indeed, IE9 and Firefox don't play well with horizontal arrows in menu items. I had to make a specific rule for them, and even then IE9 will show the arrows under the text (if the text is the longest in the menu item list, otherwise it works as expected).
Also, there are a few complications that I'll have to deal with. One of these is caused by a limitation in the "&" keyword.
This is a simplified version of the horizontal arrow code, taken from common.css, with only the code that interests me right now:
Code: [Select]
But nested menu items are a problem, because :hover doesn't apply on parent items. For that reason, I implemented long ago a .hove class on the parent <li>, so that I can target .hove & (instead of &:hover), and be done with. Here's where it gets funny... The selector that inherits .horizontal_arrow is called "li.subsection > a". Which is fine in regular times... However, doing ".hove li.subsection" doesn't work because it really is "li.subsection.hove" I should be targeting. But then, how do I represent that in WeCSS code...? Doing ".hove &" won't do, but "&.hove" won't do either, because it's developed to "li.subsection > a.hove"... And, anyway, it's never a good idea to add a 'specific' class like .hove to a 'generic' virtual like .horizontal_arrow!
(x) So, one way of doing it could be to 'simply' apply the hove class to both the li parent and its anchor child. I like the idea, but it means a few more bytes in the JS code, and it contradicts what I just said about what a good idea is...
(y) An alternative would be to only care about &:hover, as above (or even not at all?), and instead have an extra rule in index.css do the opacity change (i.e. clearly add a "li.hove > a" selector in plain view).
(z) Finally, another alternative is (very similarly to (y)) to simply remove that specific horizontal rule from the common definitions list, because it's really only used in the menu items, so I could just have the code above inserted into index.css. (There is also another horizontal_arrow class for inline elements.)
All in all, the CSS for HTML arrows is a bit weightier than the background-image version, because the image is only 150 bytes and when gzipped, its base64-encoded version is around that size. Of course, it's likely that the gzipped version of the CSS code above is smaller than 150 bytes, I'm not exactly sure. But still, it's funny that by trying to remove a few background-image hacks that were in the original arrow code, I ended up finding new issues with various browsers... (Even when taking IE6 and IE7 aside, as they never supported the background-image version really well anyway.)
What do you think, guys...?
:edit: Edited this post to add clear separations between multiple choices.
b isn't much of a problem. After all, thinking about it, a theme's quality is determined by the viewer, not by its author. It's up to the author to ensure it works best for users. Having media queries make their life more complicated, is trumped by the fact that users won't get that dreaded FOUC.
HTML arrows are more of a problem. Indeed, IE9 and Firefox don't play well with horizontal arrows in menu items. I had to make a specific rule for them, and even then IE9 will show the arrows under the text (if the text is the longest in the menu item list, otherwise it works as expected).
Also, there are a few complications that I'll have to deal with. One of these is caused by a limitation in the "&" keyword.
This is a simplified version of the horizontal arrow code, taken from common.css, with only the code that interests me right now:
.horizontal_arrow virtual
:after
opacity: .25
&:hover:after
opacity: .5But nested menu items are a problem, because :hover doesn't apply on parent items. For that reason, I implemented long ago a .hove class on the parent <li>, so that I can target .hove & (instead of &:hover), and be done with. Here's where it gets funny... The selector that inherits .horizontal_arrow is called "li.subsection > a". Which is fine in regular times... However, doing ".hove li.subsection" doesn't work because it really is "li.subsection.hove" I should be targeting. But then, how do I represent that in WeCSS code...? Doing ".hove &" won't do, but "&.hove" won't do either, because it's developed to "li.subsection > a.hove"... And, anyway, it's never a good idea to add a 'specific' class like .hove to a 'generic' virtual like .horizontal_arrow!
(x) So, one way of doing it could be to 'simply' apply the hove class to both the li parent and its anchor child. I like the idea, but it means a few more bytes in the JS code, and it contradicts what I just said about what a good idea is...
(y) An alternative would be to only care about &:hover, as above (or even not at all?), and instead have an extra rule in index.css do the opacity change (i.e. clearly add a "li.hove > a" selector in plain view).
(z) Finally, another alternative is (very similarly to (y)) to simply remove that specific horizontal rule from the common definitions list, because it's really only used in the menu items, so I could just have the code above inserted into index.css. (There is also another horizontal_arrow class for inline elements.)
All in all, the CSS for HTML arrows is a bit weightier than the background-image version, because the image is only 150 bytes and when gzipped, its base64-encoded version is around that size. Of course, it's likely that the gzipped version of the CSS code above is smaller than 150 bytes, I'm not exactly sure. But still, it's funny that by trying to remove a few background-image hacks that were in the original arrow code, I ended up finding new issues with various browsers... (Even when taking IE6 and IE7 aside, as they never supported the background-image version really well anyway.)
What do you think, guys...?
Posted: September 3rd, 2012, 12:44 AM
:edit: Edited this post to add clear separations between multiple choices.
4540
Off-topic / Re: Doctor Who
« on September 3rd, 2012, 12:51 AM »Joking Apart is a sitcom but it is based on him splitting up with his wife, so not surprising that it makes you feel that way. It's also why I haven't gone to check it out. You might find Press Gang watchable, though.
Moffat really is a genius writer...
Press Gang doesn't have any subtitles available. My spoken English is too rotten to let me enjoy these without having to pause and rewind every 10 seconds, which isn't exactly my idea of 'watchable' ;)
Find me some subtitles and I'm all ears!
As for 7x01...
Well, it absolutely rocked. Moffat's first Dalek-centric episode was a real blast. I wasn't too happy with most of his season 6 episodes (I mostly liked the fun parts in 'Let's kill Hitler!' and the last part of the final episode, although I'd already seen a few weeks before that an older show that had the *exact* same idea, I think I discussed it at the time.) I think that he was too busy writing the very best Sherlock episode ever (The Woman!), so I'm fine with it. Looks like he's back to Who with a bang. The meeting between that girl and the Doctor was a pure moment of emotion, not only because of how it was written, but also because of how it was shot. I think I already saw a similar scene in another show, years ago, but that one, I can't put my finger on it. Doesn't matter, the overall episode was just flawless. :)
Next week, I'm not so sure... But it's probably going to be good fun! I like that in Who, too.
4541
The Pub / Re: Getting ready for an alpha release: CSS fixes
« on September 1st, 2012, 08:13 PM »
Okay, bump...
I'll try to use clear English for my questions (for everyone.)
1/ What kind of sidebar do you want to have when you reduce the width of your window?
a- The same sidebar... Fuck small windows, fuck mobile! Don't touch it ah ah ah. (This has no impact on anything else, obviously.)
b- Move it below the content, and if possible above the footer. (Uses @media -- this has an impact on how you can write media queries. You simply can't use inheritance or odd little things in media queries -- has to be mostly 'clean' CSS code.)
c- Move it below the content, and if possible above the footer, using JavaScript. (Uses #responsive ID insertion -- this has an impact on performance, i.e. when you load the page in a small window, you might see the un-modified sidebar show up for a few milliseconds before it goes to the footer.)
d- Move it just above the footer, whatever the internal CSS or HTML layout. (Uses DOM manipulation with JavaScript -- this is the cleanest solution, but has the same 'sidebar flash' as solution (c), and uses a few more bytes of JavaScript code at the end of your HTML.)
2/ Do you prefer the idea of having menu arrows (and linktree arrows etc) as HTML content, or as background images? (Both have their pros and cons. It's mostly a philosophical question, like do you believe John Carmack exists?)
I'll try to use clear English for my questions (for everyone.)
1/ What kind of sidebar do you want to have when you reduce the width of your window?
a- The same sidebar... Fuck small windows, fuck mobile! Don't touch it ah ah ah. (This has no impact on anything else, obviously.)
b- Move it below the content, and if possible above the footer. (Uses @media -- this has an impact on how you can write media queries. You simply can't use inheritance or odd little things in media queries -- has to be mostly 'clean' CSS code.)
c- Move it below the content, and if possible above the footer, using JavaScript. (Uses #responsive ID insertion -- this has an impact on performance, i.e. when you load the page in a small window, you might see the un-modified sidebar show up for a few milliseconds before it goes to the footer.)
d- Move it just above the footer, whatever the internal CSS or HTML layout. (Uses DOM manipulation with JavaScript -- this is the cleanest solution, but has the same 'sidebar flash' as solution (c), and uses a few more bytes of JavaScript code at the end of your HTML.)
2/ Do you prefer the idea of having menu arrows (and linktree arrows etc) as HTML content, or as background images? (Both have their pros and cons. It's mostly a philosophical question, like do you believe John Carmack exists?)
4542
Features / Re: New revs
« on September 1st, 2012, 11:32 AM »
rev 1680
(8 files, 7kb)
@ This commit adds my hacks and fixes to the BBC parser that pretty much makes quotes work better than anywhere else (provided you supply them with clean CSS and collapsible margins.)
* Rewrote more BBC parsing code. Optimized whitespace discovery in trim_wspace code. Optimized footnote handling (by a tiny bit.) And other minor fixes. (Subs-BBC.php)
* Rewrote loadSource() to add an extra layer of filename caching. This should be about twice faster than directly calling require_once, but only in critical situations. So, yeah, basically you could say that it's useless. Still, it should be faster than even a function_exists() call, so it helps here and there, too. (Load.php, PersonalMessage.php, Post2.php, Subs-BBC.php, Subs-Media.php, Subs-Template.php, Subs.php)
+ Added a quote handler hack to trim whitespace inside and around them. Reset database trim settings for them as well, as there's no need for them to go through more code. (install.sql, Subs-BBC.php)
(8 files, 7kb)
@ This commit adds my hacks and fixes to the BBC parser that pretty much makes quotes work better than anywhere else (provided you supply them with clean CSS and collapsible margins.)
* Rewrote more BBC parsing code. Optimized whitespace discovery in trim_wspace code. Optimized footnote handling (by a tiny bit.) And other minor fixes. (Subs-BBC.php)
* Rewrote loadSource() to add an extra layer of filename caching. This should be about twice faster than directly calling require_once, but only in critical situations. So, yeah, basically you could say that it's useless. Still, it should be faster than even a function_exists() call, so it helps here and there, too. (Load.php, PersonalMessage.php, Post2.php, Subs-BBC.php, Subs-Media.php, Subs-Template.php, Subs.php)
+ Added a quote handler hack to trim whitespace inside and around them. Reset database trim settings for them as well, as there's no need for them to go through more code. (install.sql, Subs-BBC.php)
4543
Features / Re: New revs
« on September 1st, 2012, 12:25 AM »
rev 1679
(3 files +1-1, 9kb)
* Modified database structure to help future developments to custom boards and membergroups. id_board and id_group both went from smallint(5) to mediumint(8) (unsigned for boards, signed for groups.) Contact lists are now unsigned. Cleaned up more fields like UNIX timestamps that were often recorded as int(11) signed instead of int(10) unsigned. Added a few 'default 0' where needed. The media tables now get more realistic, with unsigned fields where needed, less int fields where not needed, etc. (install.sql)
+ Added default support for a few more file types in media documents: diff/patch (for developers), mht (generic cached HTML), torrent (it doesn't have to be illegal), and srt/ssa (for fansubbers etc.) I'm not adding ass to the list. People may think the forum admin is dirty. (install.sql)
+ Added default support for a few more file types in attachments: diff/patch, rtf, rar, 7z, docx, and removed mpg files (usually too large anyway.) (install.sql)
* As requested, replaced the classic YouTube embed link with the no-cookie version. Untested, though. (Subs-Aeva-Sites.php)
+ Added animations to MoveTopic pages. (MoveTopic.template.php)
* Renamed extra.gecko.css to extra.firefox[-3.6].css, to avoid processing an old CSS hack on recent Firefox versions. (extra.firefox[-3.6].css)
(3 files +1-1, 9kb)
* Modified database structure to help future developments to custom boards and membergroups. id_board and id_group both went from smallint(5) to mediumint(8) (unsigned for boards, signed for groups.) Contact lists are now unsigned. Cleaned up more fields like UNIX timestamps that were often recorded as int(11) signed instead of int(10) unsigned. Added a few 'default 0' where needed. The media tables now get more realistic, with unsigned fields where needed, less int fields where not needed, etc. (install.sql)
+ Added default support for a few more file types in media documents: diff/patch (for developers), mht (generic cached HTML), torrent (it doesn't have to be illegal), and srt/ssa (for fansubbers etc.) I'm not adding ass to the list. People may think the forum admin is dirty. (install.sql)
+ Added default support for a few more file types in attachments: diff/patch, rtf, rar, 7z, docx, and removed mpg files (usually too large anyway.) (install.sql)
* As requested, replaced the classic YouTube embed link with the no-cookie version. Untested, though. (Subs-Aeva-Sites.php)
+ Added animations to MoveTopic pages. (MoveTopic.template.php)
* Renamed extra.gecko.css to extra.firefox[-3.6].css, to avoid processing an old CSS hack on recent Firefox versions. (extra.firefox[-3.6].css)
4544
The Pub / Re: Getting ready for an alpha release: CSS fixes
« on September 1st, 2012, 12:09 AM »What I can say is that:
1. No matter how pretty it is, if it's visibly sluggish on an i7 box, let it go.
Box shadow gradients are visibly *better looking* than linear gradients, so it's really tempting to stick to them. (Plus, IE9 supports box-shadow insets, while it ignores linear gradients.)
I could simply add a hack to extra.firefox.css to reset the box-shadow and use gradients instead just for that browser...
2. How much of a *practical issue* is the inability to use extends on a media query? What would you actually want to do that it would prevent you from doing?
So I had to stick to using 'display: inline-block' on it. It's all fine on IE because inline-block was supported before media queries were implemented at all, but I'm attaching respond.js for these, which adds support for MQs, uh...
Anyway, it was just an example. I guess that in a common situation, you wouldn't need to extend MQ stuff because you'd want to try and keep it simple.
What's your favorite solution? (1) JS to finely tune the positioning of the sidebar (swapping it with another div, original implementation), (2) JS to add a #responsive class (selector order is easy), (3) JS-free classic media queries (have to be careful with selector order).
3. I'm not sure it's worth the effort. The only thing that strikes me as relevant is the fact that some people like the style of linktree like XenForo uses, where you have a container and capsules with > ends that are highlighted on hover. Can this be done in the current setup just in CSS? Would it require a change in markup? Would the changes in markup that might be required also make this possible?
Yes, 2 years is a lot of progress towards an alpha.
4545
The Pub / Re: Getting ready for an alpha release: CSS fixes
« on August 31st, 2012, 11:18 PM »
Was my post too long? Did anyone read it? Or have an opinion on any of these points..?
I'm just saying -- I myself find I don't have enough time to participate in all topics (I'm planning to play catch-up later, for now I'm just resorting to reading new posts via the Recent Posts feature), maybe I'm not alone...
I'm just saying -- I myself find I don't have enough time to participate in all topics (I'm planning to play catch-up later, for now I'm just resorting to reading new posts via the Recent Posts feature), maybe I'm not alone...