Wedge

It's not working 100% for now, works fine when not using comma-separated lists but I did that on ie6+ie7 and they fail to load correctly... Will test later...

Oh god, I have so many leftover features to finish... Grmpf...

Oh, the Wireless skin was broken because of a test file I'd uploaded to stress-test the inheritance mechanism and forgot to remove when I was done... Sorry about that.
Will no one report that kind of issue when it's been going on for at least a few hours? :P

I did... Although I thought it was another parser bug, which turned out to be working fine...
(Except that Wine is seriously broken right now. Hmm, when did that start...? I'll have to fix it again. Maybe I'll use the opportunity to rewrite the sidebar to behave like in Weaving, because I've really grown tired of that nice little animation -- it doesn't work on touch devices, for starters...)

I think I've fixed everything...
Changed a lot of things internally, really.
I have no idea whether it's for the better. It's certainly a bit slower, whether it be the per-page file check, or the actual parsing (I now do some extra sorting on selector lists), but I did notice a minor improvement in CSS file size reduction, plus there's the added flexibility of using multiple suffixes...

Now I shouldn't forget about implementing per-member suffixes, and maybe other things... What about per-board and per-category suffixes, for instance? (A different skin can be chosen for another board, but this would allow having custom CSS in a single board across *all* possible skins for it...)

One thing I don't know about, though, is the 'admin' suffix (i.e. custom CSS for admins). That's because there's also an 'admin' radix (base?), which is used in the admin area... (the classic admin.css file.)
I'd like to change that, but I don't know what to, and I don't know if I should rename the radix or the suffix.

I think it's a bit too long for my taste...
What about mana.css? :P
It's like 'manage', but it pleases my RPG-addicted mischievous mind :lol:

Oh, also... Today I added support for:
- *.b1.css -> custom css for board #1
- *.c1.css -> category #1
- *.m1.css -> member #1 (no more annoying you with my tests :P)
- *.replace.css -> a new idea of mine... It basically acts like a local replace-type skin, for one radix type.
e.g. Wine was broken because it included custom.css from its parent skin, which was geared towards modifying Weaving, not Wine. So I added an empty custom.replace.css file in the Wine folder and voilà -- all custom.*.css files from Weaving are subsequently ignored.

What I like about my skin system is that I actually use it. Thus, when I meet a new problem, I try to find an innovative solution to it.
Heck, I could even get away with removing skin types entirely, and relying on the 'replace' keyword everytime it's needed... What do you think? I can't think of a situation where a global replace type would be better.

Except for the idea that it's still called the Admin area, but whatever... :lol:If anything, it has a use for me :) (Of course I can always use the admin suffix if you prefer to see what I'm doing.)That's the problem... Which would feel the most 'natural' to people?
skin.xml has many options, but the skin type is the option regarding CSS files and their ordering. It feels more natural to have this put into the file names themselves.
However, people may get confused with where to put the replace suffix... And even I don't know to which extent they should be applied. For instance, should they put it into every available file? index.replace.css + index.replace,ie6.css -- currently, Wedge doesn't need that because it will delete any index.*.css file if a replace suffix is found on any index.*.css file. But what if they only provide an index.replace,ie6.css file into their skin folder? Now that's an issue... It'd logically mean, "keep the parent index.css and everything, but replace the index.ie6.css with mine". I guess if I had to implement this, I'd need to add even more extra code to Wedge so that it goes through the parent list and removes only those files with suffixes found in our list (in this case, ie6). Meh. OTOH it also gives more flexibility than replace-type skins. But it also introduces a potential complexity that could scare themers away.

All in all, for now I'll be keeping the replace type, but I'd like more opinions on this.

Hey, I've been busy, out yesterday fighting viruses, out today to London and back for a 15 minute interview >_>

I'm not sure which would be more natural, that's half the problem. I suspect ditching the separate skin types would make more sense, though. As long as it's documented, it'll be OK.

Yes, yes we should. That implies to me that we should load these as standard:

index.css
Sub/index.css (to extend index.css)

If IE6 is present, also load
index.ie6,ie7.css
Sub/index.replace.ie6.css

The replace keyword replaces the equivalent suffix earlier up, so Sub/index.replace.ie6.css replaces index.ie6.css but leaves index.ie6,ie7.css alone, as it's a different suffix.