Wedge

I belong to the school of semantics, by far, although I think using inheritance is only sensible.

I know I'm often the first person to write my own version of something, and I love learning from it and see if I can do better.  And here as well, I think writing a PHP version makes a lot of sense.  But, considering Sassy recently moved to using CSS-style syntax, and I personally hate Python style syntax, perhaps it makes sense to gravitate to the rules of another syntax?

That could make the documentation needs lighter.

-[Unknown]

Best of both worlds here :)WeCSS is not a PHP version of Sass per se -- it's more like a Sass-inspired original library....And I'm not going down the same route.By another syntax, you mean the 'regular' CSS syntax?

Well, two things.
First, Sass added support for 'normal' syntax because of users requests. Probably couldn't get the hang of it... Dunno. From what they said on their website, it's quite clear to me they're still going to use the Sass syntax themselves.
Secondly, Wedge *does* support the CSS syntax. Really. It's just that you can't mix css and wecss syntaxes together. Only makes sense to me... Once you see my source code, you'll understand how complex it is already.
And because of multiple stylesheets and the styling system I described elsewhere, you can't use css syntax in any files that are related to the index stylesheet (i.e. index.css, sections.css, and any overrides like index.ie6.css etc.)
However, you may perfectly use wecss syntax in the index file, and css syntax in your plugin's file (my-stupid-addon.css), as long as you don't add it to the main file list. (i.e. your plugin must load it separately through add_css_file(), instead of adding it to the css file list array.)

One thing to note, though, is that I haven't tested the extent of what you can do in the css syntax. While all functions are available (color, etc), pseudo-language constructs like 'extend' may not be available (although you can use the alternative syntax for it, the 'base:' rule.)I'm foolishly hoping that themers will find enough documentation just by reading through the index.css file ;) It has an introduction comment as well... (About a page's worth of details.)

It's being developed as part of Wedge rather than a standalone module though off the top of my head I think you could probably separate it out without too much fuss.

It isn't implemented. My algorithm was flawed so I postponed it. Instead I implemented a remove keyword for graphic elements. Should be in Warm.

'final' means that related inherited classes will disregard this rule, which is only for the 'parent' to deal with.

'@remove' followed by a full line will scan the entire file (or set of files) for that line and remove it, allowing for easy removal of graphic files that might use space for nothing in an inherited skin.
It's not very practical, but it does its job.

'unextends?' (that is, in regex, 'unextend or unextends') means the ability to simply un-inherit a class from another...
i.e. .windowbg2 extends .windowbg, and if later in an inherited skin I say '.windowbg2 unextends .windowbg', it will cancel the previous request...
Although, as I said, I'm not sure it works. And it can probably get too complicated -- can I unextend .windowbg from .windowbg3 if .windowbg3 only extends .windowbg2, without unextending .windowbg from .windowbg2 as well? See, that kind of crap...
Thankfully, an inherited skin will always know what its parent is about, and what code it holds, so it should be easy to simply redefine the rules you don't like. But, ideally, unextends should be cool if it was thoroughly tested. Which it hasn't been.

WeCSS

I thought it was related to CSS but was unsure, I've been working my way through all the posts on the site but it takes some time ;)