Been busy IRL blah blah blah, worked on a few things that I wanted to fix in my CSS. Not happy with the things I've had to give up for that... So I want your opinion, because all of this has been accumulating over the last couple of days, and last time I checked, I really wanted to commit everything I have before I'm ready for an alpha.
1/
Gradients in headers (Wine and children): for a long time, what I used was a very small PNG image, which allowed it to work in IE6+. Recently, I decided to replace gradient images with proper gradients, as IE6 doesn't deserve any non-essential goodies anyway. So I did that.
Then I realized that an issue with linear-gradient, is that to get the same effect as an image, you have to specify color stops in pixels, and then set an explicit background-size... It's a bit complicated, but I did it. (Unfortunately, it also meant that the resulting CSS was probably on par with the earlier one in terms of size :P)
Okay, so this morning, I was thinking... "What the hell?! I could simply be using an inset box-shadow to act as the inner gradient! And I get to set my pixel dimensions!"
And it works fantastic. Really. It's just a single line of code. It works in IE9+, and it's cleaner.
However... There's a catch.
The performance is excruciatingly slow when there are lots of these, e.g. alternating backgrounds in the error log or display page. Really. Under Opera 12.5, it runs fine, just a bit less responsive, but when you show a confirm box, you can see how long it takes to show up... Under Firefox 16, it's like night and day. Super fast with a gradient, HORRIBLY slow with a box-shadow.
That's really, really annoying because the results are much better in box-shadow mode!
So... What do you reckon I should do? Is there a way to fix performance? I'm talking about a test done on a Core i7 computer... :-/
2/
Another thing that always bothered me... Wedge using JavaScript to reposition the sidebar, instead of media queries. This was originally because I would 'switch' positions between two different elements, so that I could set a specific target for the sidebar inside the DOM, instead of using CSS tricks to reposition it. As time went by, I decided to save bandwidth in all HTML pages by applying a 'responsive' ID to the DOM's top instead, and I hacked into the CSS in a relatively clean way that I was satisfied with. Okay, so far so good...
Now, this morning I was looking at my code, and the first thing that came to mind was, "WTF?! I use #responsive to set specific media queries... Why not just use @media $responsive?". And this is exactly what I did...
So, $responsive is set to a max-width of 1000px for now, it's working okay. The main benefit here is that because it's done on the CSS level, there's absolutely zero FOUC effect when reloading a page. (There used to be a very, very short one when doing a F5 refresh.)
Plus, I think themers will be comfortable with that... As long as they know about responsive design, of course.
Now for the drawbacks...
- @media doesn't have a set precedence factor, so it doesn't change priorities in the code, unlike #responsive. This means that if you set a #responsive #sidebar to 'display: block' in index.css (or even in an hypothetical extra.css file in Weaving), and then set #sidebar to 'display: table' in a sub-skin's extra.css file, the resulting responsive page will have #sidebar set to display:block because #responsive has higher priority. But if you start replacing all of these with @media $responsive, the resulting responsive page has #sidebar set to display:table because it was filled in after the original media query. The (clean!) solution I'm using, is to take the original media query, copy it at the end of my extra.css file, and add a reset suffix to it. Yes, "@media $responsive reset" is all that's needed. This way, the original media query is removed, and the new one is set at the one, and it includes the original media query's rewrites. Yes, it isn't as bulletproof as direct inheritance because if Weaving is heavily modified you'll have to modify your sub-skin as well. But it's probably something that could also happen with #responsive, albeit with different issues.
- Perhaps an even worse one... Unfortunately, @media being a special construct, you can have a selector like ".myclass, #myid, @media all .anotherclass", ah ah. Well, Wedge doesn't even bother checking... It actually does build such a selector if you add an 'extends' keywords to .anotherclass in the media query. Which pretty much makes the css declaration fail. So, yes, it does mean that whenever you start declaring a media query, *you can't use any extends in it.* Bummer!
So, I'm seriously considering going back to the 'original', as flawed as it is.
3/
And finally... The menu arrows.
Currently, they're using a lightweight (150-byte) image with horizontal and vertical positions, as well as a hover version.
I decided that I wanted to associate the arrows with the text next to them -- so that you can set the text to any color and they'll follow the color. So I replaced the arrows with CSS right-floated 'content' set to '\a0\25bc' (IIRC), in a pseudo-class of course. It seems to work really fine. This also allowed me to remove a couple of CSS hacks I had for the arrows. Unfortunately, this technique also has its limitations... Apart from the fact that pseudo classes don't work in IE6 (fuck you IE), there's the fact that Firefox shows arrows using a largely different size compared to Opera (?!), and float issues in the different places where it's all used, e.g. menu arrows aren't floated the same way when they're in the top-level menu or inside the menu itself. Same with linktrees...
This one is more of a technical issue to me, as philosophically I think I'm really good with using CSS content rather than images.
Anyone got any experience with that...?
1/
Gradients in headers (Wine and children): for a long time, what I used was a very small PNG image, which allowed it to work in IE6+. Recently, I decided to replace gradient images with proper gradients, as IE6 doesn't deserve any non-essential goodies anyway. So I did that.
Then I realized that an issue with linear-gradient, is that to get the same effect as an image, you have to specify color stops in pixels, and then set an explicit background-size... It's a bit complicated, but I did it. (Unfortunately, it also meant that the resulting CSS was probably on par with the earlier one in terms of size :P)
Okay, so this morning, I was thinking... "What the hell?! I could simply be using an inset box-shadow to act as the inner gradient! And I get to set my pixel dimensions!"
And it works fantastic. Really. It's just a single line of code. It works in IE9+, and it's cleaner.
However... There's a catch.
The performance is excruciatingly slow when there are lots of these, e.g. alternating backgrounds in the error log or display page. Really. Under Opera 12.5, it runs fine, just a bit less responsive, but when you show a confirm box, you can see how long it takes to show up... Under Firefox 16, it's like night and day. Super fast with a gradient, HORRIBLY slow with a box-shadow.
That's really, really annoying because the results are much better in box-shadow mode!
So... What do you reckon I should do? Is there a way to fix performance? I'm talking about a test done on a Core i7 computer... :-/
2/
Another thing that always bothered me... Wedge using JavaScript to reposition the sidebar, instead of media queries. This was originally because I would 'switch' positions between two different elements, so that I could set a specific target for the sidebar inside the DOM, instead of using CSS tricks to reposition it. As time went by, I decided to save bandwidth in all HTML pages by applying a 'responsive' ID to the DOM's top instead, and I hacked into the CSS in a relatively clean way that I was satisfied with. Okay, so far so good...
Now, this morning I was looking at my code, and the first thing that came to mind was, "WTF?! I use #responsive to set specific media queries... Why not just use @media $responsive?". And this is exactly what I did...
So, $responsive is set to a max-width of 1000px for now, it's working okay. The main benefit here is that because it's done on the CSS level, there's absolutely zero FOUC effect when reloading a page. (There used to be a very, very short one when doing a F5 refresh.)
Plus, I think themers will be comfortable with that... As long as they know about responsive design, of course.
Now for the drawbacks...
- @media doesn't have a set precedence factor, so it doesn't change priorities in the code, unlike #responsive. This means that if you set a #responsive #sidebar to 'display: block' in index.css (or even in an hypothetical extra.css file in Weaving), and then set #sidebar to 'display: table' in a sub-skin's extra.css file, the resulting responsive page will have #sidebar set to display:block because #responsive has higher priority. But if you start replacing all of these with @media $responsive, the resulting responsive page has #sidebar set to display:table because it was filled in after the original media query. The (clean!) solution I'm using, is to take the original media query, copy it at the end of my extra.css file, and add a reset suffix to it. Yes, "@media $responsive reset" is all that's needed. This way, the original media query is removed, and the new one is set at the one, and it includes the original media query's rewrites. Yes, it isn't as bulletproof as direct inheritance because if Weaving is heavily modified you'll have to modify your sub-skin as well. But it's probably something that could also happen with #responsive, albeit with different issues.
- Perhaps an even worse one... Unfortunately, @media being a special construct, you can have a selector like ".myclass, #myid, @media all .anotherclass", ah ah. Well, Wedge doesn't even bother checking... It actually does build such a selector if you add an 'extends' keywords to .anotherclass in the media query. Which pretty much makes the css declaration fail. So, yes, it does mean that whenever you start declaring a media query, *you can't use any extends in it.* Bummer!
So, I'm seriously considering going back to the 'original', as flawed as it is.
3/
And finally... The menu arrows.
Currently, they're using a lightweight (150-byte) image with horizontal and vertical positions, as well as a hover version.
I decided that I wanted to associate the arrows with the text next to them -- so that you can set the text to any color and they'll follow the color. So I replaced the arrows with CSS right-floated 'content' set to '\a0\25bc' (IIRC), in a pseudo-class of course. It seems to work really fine. This also allowed me to remove a couple of CSS hacks I had for the arrows. Unfortunately, this technique also has its limitations... Apart from the fact that pseudo classes don't work in IE6 (fuck you IE), there's the fact that Firefox shows arrows using a largely different size compared to Opera (?!), and float issues in the different places where it's all used, e.g. menu arrows aren't floated the same way when they're in the top-level menu or inside the menu itself. Same with linktrees...
This one is more of a technical issue to me, as philosophically I think I'm really good with using CSS content rather than images.
Anyone got any experience with that...?
