Nao

  • Dadman with a boy
  • Posts: 16,079
CSS caching
« on May 10th, 2011, 06:43 PM »Last edited on September 11th, 2011, 06:57 PM by Nao
Feature: CSS caching
Developer: Nao
Target: everyone
Status: 100% (believed to be complete.)
Comment:

This is pretty much the same as for JavaScript caching, except that there's only one code path for CSS, since there aren't 50 ways to minify stylesheets.

Now, I'd just like to point out that thanks to the preparser, Wedge's cached CSS files will also embed all of the icon data, saving you yet another number of additional hits that servers and browsers usually don't like too much. IE6 and IE7 don't support data embedding, so they'll simply keep using external links. Who uses these stupid browsers anyway?

Re: CSS caching
« Reply #16, on May 3rd, 2013, 08:08 AM »
If you ate using we::is for browser testing, there are no changes involved.
Also, we::$user['is_mod'] becomes we::$is['mod'] or of course we::is('mod').
Re: CSS caching
« Reply #17, on May 3rd, 2013, 03:37 PM »
Okay, I'm pretty done with the caching rewrite, but I'm not even started with the plugin caching rewrite. It will still work *if you don't use tests or suffixes in their CSS files*, so I've just got a question... Can I commit "as is", and deal with plugins later..?

Also, I'm seriously considering removing the 'replace' suffix entirely, for at least two reasons: it doesn't make sense at all inside an @if test (although it's the same for the 'global' keyword, but I can always remove that one later as it really is the equivalent of 'true' and should only be used for clarity reasons...), and even as a suffix, it's still handled separately from the other suffixes, which I'm not too thrilled about...
I'm not going to ask for opinions on this one, though, as it's likely that it's all about difficulty of implementation, for me, rather than whether or not it's a welcome/useful keyword...

Re: CSS caching
« Reply #18, on May 3rd, 2013, 03:42 PM »
Quote
Can I commit "as is", and deal with plugins later..?
Course you can, how often do I do that, after all? ;)

Re: CSS caching
« Reply #19, on May 3rd, 2013, 04:15 PM »
Quote from Arantor on May 3rd, 2013, 03:42 PM
Quote
Can I commit "as is", and deal with plugins later..?
Course you can, how often do I do that, after all? ;)
You'd never commit anything that breaks what I'm working on, or the general behavior of our forum, and I'm expecting you to expect me to do exactly the same, of course... ;)

Re: CSS caching
« Reply #20, on May 3rd, 2013, 04:24 PM »
At least, not intentionally ;)

That's why the infractions system has been driving me mad, because it's not like I can deploy any of it and leave here without a functional warning system. Though, fortunately, we haven't had to use it much anyway (but you just know that if I broke it here, we'd end up having to warn people and stuff)

Re: CSS caching
« Reply #21, on May 3rd, 2013, 04:33 PM »
Quote from Arantor on May 3rd, 2013, 04:24 PM
At least, not intentionally ;)

That's why the infractions system has been driving me mad, because it's not like I can deploy any of it and leave here without a functional warning system. Though, fortunately, we haven't had to use it much anyway (but you just know that if I broke it here, we'd end up having to warn people and stuff)
Yes, I guess so...

Oh... And now for a bug I just found out... The local keyword. :-/

skins/index.local.css
skins/sub-skin/index.local.css

When compiling the default skin, the first file will be added to it. When compiling the sub-skin, the first file will be ignored, and the second one will be added to it. In short: 'local' means that the code should only be included in we're in the right folder; it's important for sub-skins of the 'replace' type.
Now, if I use "@if local" inside a CSS file, I would expect it to do the same: ignore the block if it's within a CSS file that's not part of the sub-skin's folder...
And 'oops': CSS file contents is only analyzed after loading them back to back, in hierarchy order. There's no way, currently, to know 'where' we are... The only keyword that supports is is $here, and it's only because I've added some special code for it...
So, how do I keep track of where @if local is called from...?

- Just like $here, I could do a test on the contents of the current file, and turn all 'local' keywords to 'global' if we're within the right folder, or to '!global' if we're not... That seems like the best solution, but I'm wary of changing anything that can affect regular CSS... For instead, "background-attachment: local", while not used in Wedge, would get broken. Then, err... Does that mean changing '!global' or whatever back to 'local' once all variables are tested against...?

- Just tell people not to use the local keyword inside CSS files..?! But part of my rewrite, was specifically to merge suffixes and keywords together, so... :-/

- Add some keywords at the beginning and end of each file, something like <file="..."> </file>, indicating where we're in; this can also be used by $here to determine the folder, instead of using our special code. However, that one might be slower to parse, I guess..?

- Something else..?

Re: CSS caching
« Reply #22, on May 3rd, 2013, 04:45 PM »
* Arantor has no idea, never built replace skins.

Re: CSS caching
« Reply #23, on May 3rd, 2013, 06:08 PM »
I'll commit as is, then, and re-think about it later...
Re: CSS caching
« Reply #24, on May 4th, 2013, 12:24 AM »
Found bug over bug while documenting for the changelog... Impressive.
In the end, the current rewrite is very different from the one I originally planned to commit today... Uh.
And it's still buggy. >_<
For instance, a negative test currently returns an incorrect value, and I don't even know how to deal with that... (I understand the logic of what I was trying to do; I understand the logic of where it fails; I just don't understand how to do it in a way that it doesn't fail.)

Note for later: if it seems like an easy change in Wess, DON'T DO IT. Even if the current product is buggy, as long as you don't see it, it's alright! :P

Well, at least now I've got 'b1' properly working inside CSS files, as I was trying to do...

Re: CSS caching
« Reply #25, on May 4th, 2013, 12:25 AM »
Quote
Note for later: if it seems like an easy change in Wess, DON'T DO IT. Even if the current product is buggy, as long as you don't see it, it's alright!
If a bug is in the code and no-one ever sees the bug, does it really exist?

(It's the computer equivalent of 'if a tree falls in a forest and no-one was around to see it, what colour was it?' Herman Toothrot owes me a lot for that one.)