(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:
.horizontal_arrow virtual
:after
opacity: .25
&:hover:after
opacity: .5
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...?
Posted: September 3rd, 2012, 12:44 AM
:edit: Edited this post to add clear separations between multiple choices.
@To everyone: right now, the minimum version of PHP that may run Wedge is 5.2.3. I just found out that v5.2.4 can use "\h" to represent "[\t ]" in a regex (i.e. horizontal whitespace), and "\v" for "[\r\n]" (vertical whitespace), which is SUPER cool IMHO. I was wondering if anyone was against the idea of upping the minimum version to 5.2.4 just for that...? (Keeping in mind I may not even use it.)That is exactly the reason I suggested a toggle: I already know that most of the things that are (and could be) in the sidebar on *any* forum are *for me* useless (dunno, most likely I have a rather peculiar way to use forums). The only one that from time to time *I* use is "Unread replies".
That's doable. Anyone? Opinions?Funny enough the message area (that I think is the most important part of a topic) in a 1024x is 450px, that is less than half the size of the screen (44%) and the space actually filled with text is only ~386ps (38%, a bit more than one third of the screen size).
That would work if the sidebar is visible for the entire length of the page, but at the moment is visible just in the first screen, going down the topic the result is a single narrow column (16 page-down long against 12 without sb)...and your signature is too wide for a 1024px monitor. ;)
Posted: September 16th, 2012, 06:32 PM
Re: bad space at the right, I could use a position: fixed or something on the sidebar, or use JS to reposition it to always have the contents on the side, but that would mean having to ensure the sidebar height isn't bigger than your viewport height. That, or using JavaScript to help dynamically, ah ah... Lots of work, no time for that.