tl:dr; if someone's interested in Wess and caching and everything, please just err... read this post, and give your opinions... I can't really force anyone to get into something this complicated, so I'll guess it'll stay that way, but hopefully I'll sleep over it..? :-/
So... I've sold part of the problem, by removing support for b1/c1 entirely.
I've replaced it with b1/c1 classes that are added next to the dynamic ID that already gives the ability to style the current action... (e.g. <div class="content"><div class="frame b3 c1" id="topic"> means you're in the main content div of a topic page located in board #3, which is part of category #1.)
I don't know yet if it's worth showing the category ID, though...
All in all, I don't even know if everything's really useful, because if your goal is to offer a different layout for a specific board, you can just as well create a new sub-skin, and then assign it to your board, and that's it, you're done... Of course, users are then free to change it... (Are they? I don't remember if we have an option to force a skin no matter what...?)
Still, I need to fix the rest... It's really much, much more complicated than I first expected.
For instance, let's say I'm member #1 and I'm running a skin that has an index.m1.css override. It'll see that keyword, add it to the list of special suffixes, and subsequently to my CSS filename. "member-m1-12345.css.gz" it is. Good.
Now, if by chance I've also added an "@if m1" test within the main index.css file, everything will work just the same. Good.
And that's when you decide to remove the index.m1.css file and move everything to the index.css file itself, ah...
So, Wess will first gather a list of existing file suffixes. Not a single 'm1' among them, so it doesn't test against 'm1' either, and thus doesn't add m1 to the suffix list. So, we're getting a filename that just says, "member". Now, we're accessing the cache that we stored relative to this 'member' key, which will return the complete filename *after* all internal @if tests were done and all positive keywords were added to the filename in the first place... So, that cache entry will return, for instance, 'member', same as the original, because no extra tests were triggered in index.css... Except that yes, we should have returned 'member-m1' instead, because there's a test for m1 in it, right..? Wrong. The cache key 'member' was generated during a page load for member #3854, and member #3854 failed the m1 test, and thus the returned cache key didn't have 'm1' in it... Very obviously.
It can get worse... For instance, if you're changing your language to a RTL one, how exactly do we tell Wess that you are now requiring it to return a positive on all "@if rtl" tests..?
I guess we'd need to either store a list of all tests per skin, and then do quick tests on these on each page load, or instead store the 'final filename' for each user, in their member data. But that DOES mean going through the caching process every time they do something, like a skin/language/sex/mod-status change. NOT FUN.
Another possibility, as mentioned before, would be to store all keywords that would return TRUE in your situation, i.e. at worst every one of your CSS files would start with the filename "member-m1-admin-webkit526.1-win6.1"... Uh. Then again, if ALL files use that filename, the HTML should compress well, but you're also generating a frigging single file per OS/browser/member-status combination. (And that's not even taking m1 into account; unless I use some extra caching, I'll have to get rid of m1 testing as well... Which I'd rather not do, since I've found good use for it even on this site..???)
Anyway... It just means I'm stumped. I can't figure out what the cleanest solution is. Every time I think of something, it feels like a regression to me. "Oh, okay, let's just get rid of board and categories... Oh, and member IDs too... And let's generate 3 times more files than I used to..."
Yay, this topic triggered the 'new'-indicator-on-quick-edit bug for me... And as always, it's always on the first one and not subsequent ones.
Posted: May 1st, 2013, 11:24 PM
Perhaps I should also ask this simple one:
Which keywords are most likely to be used by a themer, or plugin author, or admin, in crafting their CSS...?
browser (ie6, firefox[17-], whatver...)
os (android, ios[-5], whatever...)
member ID (m1, m2...)
board ID (b1...)
category ID (c1...)