Wedge

Meanwhile... everyone's been very busy discussing SMF licensing changes and other things that were already discussed last month... and the month before... etc. I don't get why everyone is wasting their time repeating themselves continually. I get it that people don't give a damn about Wess, I'd just appreciate if they posted to say it here, because that would help me prioritize my own share of work on it...

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..."

Bugger.

:edit: 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.

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
guest
rtl
admin
mod
member ID (m1, m2...)
board ID (b1...)
category ID (c1...)

Anything else..?

No, Win98 was released in 1998, so it couldn't have had IE5 if IE4 was out in 1999... ;)

From what I can remember:
- IE1 was in MS Plus Pack for Win95, a stupid add-on.
- IE2 was a free download; it was great.
- IE3 added support for frames (which were primordial at the time), and had a better looking interface, but wasn't as fast as IE2.
- IE4 was released along with Win98, and this is the version that was 'tightly integrated', had support for dynamic desktops (news feed push), and crap like that; it was much slower than IE4 and more resource-intensive. I hated it, with all my heart.
- IE5 was released a year or two after that one. It was much better. That's when Netscape started to become a thing of the past, as it was becoming horribly bloated (Netscape Communicator...! Who remembers that one!)
- IE6 was even better. At the time, there was just no valid competition. Standards were an anachronism. The real standard was IE6... It hurts me to say that, but at the time, it seemed like an okay browser, and I used it for many years until I had my revelation with Opera 8. Lol.

I think I'll just remove b1 and c1. I can instead add them as classes in the body... ;)

Jelly Bean is also 4.2, so uh... :^^;:

And back in 1999, IE6 didn't exist, heck I'm not even sure IE5 existed at that point... Maybe IE4!

- web 2.0 is just a marketing word, yes. However, its original definition was that web 1.0 gave power to authors, while web 2.0 added power to the community, i.e. the development of comments in websites and blogs. It is largely accepted that web 2.0 was simply 'inspired' by what Amazon has been doing for a very, very long time (user reviews). From a designer's point of view, the 'web 2.0' definition relates to the trend that took off a few years ago, where websites started using bright, contrasted primitive colors on a white background. Typography is also a large parge of it.

- Wireless is pretty much the same as Weaving, with the exception of a few differences on the homepage, and topic pages showing the userbox on top of messages, rather than to their left... I don't see the reason for comparing the two..? They're the same really, but Wireless is optimized for narrow widths, that's all there is to say..?

Wedge is super-fast, mostly because its HTML is very tidy and all JavaScript is loaded at the end of the page (except if it's already cached and running fast, then it's loaded at the beginning, because I'm very much a mad optimizer.)
That's one of its points... I've always found SMF to be slower than some competitors like Fluxbb, which to be fair doesn't have the same amount of features or JavaScript. I wanted it to be on par... And still retain the same speed.

Also, most images are loaded through CSS embedding, so it's all a single server hit, meaning you don't get that delay in loading the later icons.

Web 2.0, far from it... I have a WIP skin around, but it's not ready for primetime. It's supposed to be more 2.0ish than the other skins.