In the last few days I’ve just discovered one new thing after another about what’s available for producing CSS and it’s very heartening (though suffering from information overload) because we can do all the variable/abstraction type things now, rather than waiting until the browser vendors get their act together in whatever ‘non compatible’ ways they decide to do that

For those that think prototypes are too complicated, I think what has made CSS over complicated and unmanageable is its total lack of constraints. The beauty of poetry is in the limitations. Allowing syntax to express some limitations in CSS allows a lot more logical consistency. It makes it *easier* for beginners, not harder.

My main comment is that I have yet to see a proposal for this type of class-extending mechanism people keep talking about that actually defines what it means in terms of the CSS model. Examples != definition. See also my proposal, which tries to address some of these use cases without making classes first-class citizens. (Right now they’re only used for pattern-matching against the DOM tree.)

I believe a clear statement of the problem, with real-world examples like you have here, would be much more helpful to the CSSWG discussions about variables than simply trying to introduce a particular solution. I think many of the CSSWG members don’t understand the problem that you’re trying to solve here because they don’t spend all day building with production-level CSS.

I’d rather other things like float: center; and float: bottom; before having these features though.

Your more complex ideas for mixins and prototypes are not at all my cup of tea, though.

The idea that these extensions can make basic CSS declarations invalid, while they themselves are ambiguous in their potential for being overwritten/undone, let alone how they fit into the cascade, are more difficult to embrace. In practice, how will these be debugged? Suddenly the factors for what’s affecting, say, that inexplicable positioning bug in your layout… have gained an extra dimension. Meanwhile the idea of certain classes being extensions of others… Is something that can already be done with an extra selector, isn’t it?

I do see immense value in writing this way for the quick prototyping from scratch of elaborate applications… But for generic maintenance and debugging, I believe it would make CSS too programmatic, when the existing solution is simply more explicit selectors — which can easily be traced and compared side-by-side to see where precedence comes in case of conflict.

The slideshow is cool but I think you could get through to detractors better by showing, for each of your proposals, examples of the confusing, laborious, bad practice of CSS as it stands for certain use cases; with ‘after’ showcases of how much easier things would be with your implementation…

Ruby: http://lesscss.org/
.NET: http://www.dotlesscss.com/

And I’m sure there is a php version out there somewhere.

Chris,

An old post of mine on the same subject of extending CSS: http://mattwilcox.net/archive/entry/id/991/
And another about the fundamental problems with CSS as it stands: http://mattwilcox.net/archive/entry/id/1031/

Both are as valid now as they were when published. It saddens me.

With regard to your particular points: we could get past the issues you call attention to by having CSS made aware of the DOM, instead of relying on the feeble cascade. It’s the one major thing CSS needs to allow massive flexability – to be able to inspect OTHER dom elements, and apply their styles back to a reference element.