Wedge

(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:


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.