Wedge

Well, that's the reason I asked. (I could use 'index.replace.ie6,ie7.css' but I'm not sure people would follow.)
I'm already getting the list of suffixes for a file -- I could just as well remove 'replace' from the array, and then do a search on all parent folders, get all files with the same radix, explode the suffix list and compare the arrays. (Perhaps doing a sort() before maybe? I don't think array(1, 2) == array(2, 1)...)

There also is the point of replacing non-suffixed files in the same skin. Like, 'custom.replace,ie6.css' could be a request to entire remove 'custom.css' when IE6 is used, and replace it with 'custom.replace,ie6.css'...

You're right, array(1, 2) != array(2, 1) but that's sort of the point.

I'd keep it simple: if you indicate replace, and there's a suffix after that, that's all that's replaced. Bear in mind that we'll have to explain this to other people!

Lulz yeah...

But there's hardly any reason to account for the replace keyword's position when already I'm getting the suffixes as an array...
Could simply test for implode(',', array_diff($suffix_list_from_this_file_that_has_a_replace_suffix, (array) 'replace'))...

Putting aside the position of the replace keyword, just consider the remainder of the terms - index.replace.some,thing.css should replace index.some,thing.css but not index.thing,some.css.

While I can see the logic of arguing either way, I'd strongly be in favour of keeping it simple.

Nao, I think your rewrite is broken somewhat. My custom board icons don't show (full path instead of URI). Also, my custom menu is completely broken. Does the reset keyword still work?

I don't think anything's broken in here...?

Even the reset keyword seems to work.

Can you look into it further, please? You know I'm as careful as possible when touching my skin code, but maybe I missed something, given the number of possibilities wetem and wecss offer...

Not surprised. WeCSS has trouble with any complex css2/3 that uses commas or quotes. I think one of my comments warns against that.
What shall we do? Protect all code at parse time? In what order? etc.... Headaches ahead.

Thing is, my entire skin worked just as  expected before the rewrite.

Can you help determine what revision broke it?

Yep. Latter on today after I finish this small plugin[1]. I reverted to r1595 yesterday to see if something after that broke it, still broken. :(

1.	The Javascript is a bitch..

Can you revert to an even older copy then? Just check the log for Class-CSS.php to see the relevant revs... Thanks!

OMG so many changes... so fucking lost.

it works in r1584

also in 1590

and not in 1593
I'd assume that has something to do with it.