Don’t get me wrong, I think CSS is awesome. It is a great way of defining the UI, but it could be even better. I’m excited about the special effects, transitions, and graphic elements currently being added to the CSS specification. They will help us write faster pages by eliminating the need for UI graphics for things like rounded corners. On the other hand, we also need to add structure to the language to make it easier for designers and developers to author new pages and applications. I hope the CSS Working Group will consider my suggestions.
- Make CSS a better declarative language
- Abstract repeating patterns in the code
- Do not make CSS a programming language
Suggestions for the CSS Working Group
The community has been talking about some form of constants or variables in different incarnations for almost a decade, it is time to make this a reality. While it is possible to duplicate this functionality with a preprocessor (an excellent stop gap until browser support catches up), ultimately this is a tool which should live within the CSS itself. It is a powerful way of expressing more about the objects we are building.
The mixins and prototypes (and associated includes and extends properties) are designed to allow document authors to abstract reusable bits of code and better manage and maintain their style sheets. The goal is to mimic the effect of using multiple class names in the HTML without the drawbacks associated with current implementations. Authors need extends and include in order to write faster, smaller, more efficient style sheets.
CSS is a powerful expressive language. It needs certain modifications so that it will be robust, maintainable, and easy to implement.
How did this begin?
At some point, I realized I was coding CSS with a bunch of “rules†and best practices that weren’t the currently accepted norm. I found myself writing comments to try to express these rules like:
/* ----- faq (extends mod) ----- */
and
/* margin top = bottom height - corner height */
At that point I realized that I was trying to express via comments something which was missing from existing CSS syntax. I looked at other proposals and my own work building web sites for the last 9 years (eek! almost a decade). I first cataloged many of the rules because, at this point, they were mostly intuition and I needed to figure out why I do things the way I do.
When that had stabilized, I began to explore a syntax for this new language of declarative objects. Trying to balance standard programming practices with a desire that the syntax fit well with document authors expectations for how the language works.
CSS Inheritance Today
It is currently possible to implement CSS inheritance in three ways, however, each has its drawbacks.
- Multiple class names, clog the HTML with classes that have the same semantic value (just more or less abstract). They introduce an unnecessary dependency because CSS inheritance is defined in the HTML.
- By chaining comma delimited selector strings, authors lose the ability to group related rules into discrete blocks of code. The quantity of code increases dramatically. A preprocessor could make option #2 more feasible, but abstracting a necessary part of the language into another layer isn’t a permanent solution. As well, the resulting CSS is not human readable, this step should take place in the document tree.
- With a JavaScript parser, the heavy lifting could be done on the client-side, however this would likely have a negative performance impact particularly on older browsers and slower machines.
A Concrete Example – Based on YUI Standard Module Format
I found myself writing the following code:
/* weatherModule (extends .mod) */
.weatherModule{...}
.weatherModule .hd{...}
.weatherModule .ft{...}
.weatherModule .bd{...}
The html looked like this:
<div class="mod weatherMod"> <div class="hd">Local Weather for SF</div> <div class="bd">Cloudy with 100% chance of rain, and fog.</div> <div class="ft"><a href="newLoc.html">Change your location?</a></div> </div>
I was using multiple class names (which is great because ultimately it reduces the footprint of the CSS file by an order of magnitude), but it would be better if the browser could understand my intention, and process any instance of weatherModule as if it was also a mod.
<div class="weatherMod"> <!-- Can the browser treat this as an instance of mod? --> <div class="hd">Local Weather for SF</div> <div class="bd">Cloudy with 100% chance of rain, and fog.</div> <div class="ft"><a href="newLoc.html">Change your location?</a></div> </div>
Thanks so much to the following people who gave invaluable advice, feedback, and (in some cases) tolerated an enormous number of iterations. Nothing gets created in a vacuum and dissenting opinions were as helpful as supporters. 🙂 William Cook, David Federman, Gopal Vijayaraghavan, Douglas Crockford, Stoyan Stefanov, Ryan Grove, Marcel Laverdet, Eric Meyer, Dan Cederholm, Ethan Marcotte, Jeffrey Zeldman, Gonzalo Cordero, Jenny Han Donnelly, Chris Klaiber, Tantek Çelik, Jeremy Keith, Wendy Chisholm, Aaron Gustafson, Fred Sauer, Dave Hyatt, Eric Schurman, Brad Neuberg, John Allsopp, Tom Hughes-Croucher, Chris Mills, Nicholas C. Zakas, Peter-Paul Koch, Doug Schepers, Amy Hoy, Kyle Simpson, Brian LeRoux, Chris Blizzard, Philippe Le Hegaret and (of course) Daniel Glazman.
Comments
22 responses to “CSS Wish List”
Interesting stuff, will take me a while to digest 🙂
I have experimented with attribute selectors to create inheritance that will work in most modern browsers, but it’s not pretty:
.mod, [class^=mod-], [class*=” mod-“] {…}
[class^=mod-extended], [class*=” mod-extended”] {…}
Very good points. Your syntax and behaviour looks very well thought out. Unfortunately, people on the working group think otherwise: http://www.w3.org/People/Bos/CSS-variables
@Andrew Vit – The resistance of the working group concerns me too, which is why this needs to live in a parser for now. We need this functionality *today*, not in 5 years when browsers support it.
FWIW, I think Bert is trying to do the right thing for the language, but I’m uncomfortable with the argument that designers are too dumb to understand OO inheritance.
He’s also wrong about the outcome. Adding @prototype actually makes the code much easier to understand because the complicated bits get abstracted into base objects that only architect level developers need to modify. Any domain needs to be able to have architect, intermediate, and entry level positions — CSS is currently too simple to make that a reality.
This functionality would go a long way towards reducing file size. The proof is in sites that have switched to using inheritance via the multiple class method. Someone told me recently about a site that went from 60K to 15K just by switching. I think the size of the files in my open source project also speaks to that. I don’t have the syntax available, but I’m doing the same thing without the tools to express it.
Interesting.
Can this all be done with a preprocessor step?
I think it would help adoption if you put your ideas down as a css compiler, built a few websites in your new language (as well as convinced others to do so too), and then proposed it as a standard with all the practical experience.
I like your point and the way you propose solutions. It would be so much easier to write and ,most important, manage css.
Have you tried http://www.compass-style.org? It’s actually sass, so it has to be compiled into css. It’s a good way to use mixins, variables, even colour adjustments (lighten, darken, etc…)
I was actually thinking about beginning to support extended @ values with eCSStender. When I get that together, it should be relatively easy to build an extension to test how well your suggestions might work.
@Aaron Gustafson – Sweet! I’d love to see this become a reality, either via server-side preprocessing or JS. Gopal supported it via adding additional classes to the DOM, which was a cool experiment. (Old version of the syntax)
Good points. While the CSS Working Group do not implement these sugestions. You can use LESS http://lesscss.org. That’s great
The working group essay reminds me of an old saying “methinks the maiden doth protest too much”. We do need variables. It will alleviate all the jumping through hoops we do otherwise. I have used moonfall to add this functionality, but it just adds another step every time you change or add to the styles. Not good.
Attribute Selectors and FTW!
It’s deeply depressing that we’re having the same discussions, about the same problems, with the same people blocking progress, as we were a year ago, and two years ago, and in the case of Bert Boss and his Variable arguments, a decade and a half ago.
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.
[…] セッションã®æ™‚é–“ãŒã‚ã¾ã‚Šã€ãƒ‹ã‚³ãƒ¼ãƒ«ã•ã‚“ã¯ãƒœãƒ¼ãƒŠã‚¹ãƒˆãƒ©ãƒƒã‚¯ã¨ã—ã¦ã€CSS Wish List見ã›ã¦ãã‚ŒãŸã€‚ シートを見ã¦ã€æ€ã‚ãšæ„Ÿæ¿€ã—ã¦ã—ã¾ã£ãŸã€‚ 「ãŠãŠã€ã‚ªãƒ–ジェクト指å‘ã®è¦ç´ 満載ã ãªã‚～。ã€ã£ã¦ã€‚ […]
[…] tme of her session was left over, so, Nicole showed us “CSS Wish List” as bonus track. When I saw her sheet, I was amazed. “Oh, there are plenty of Object […]
As previously mentioned these types of CSS extensions have been sought after by many and rejected by the powers that be. Thus there are som may great CSS preprocessors out there like Less:
Ruby: http://lesscss.org/
.NET: http://www.dotlesscss.com/
And I’m sure there is a php version out there somewhere.
Chris,
The variables (or global constants, seeing as CSS isn’t dynamic) idea is definitely useful, and the way you propose its implementation is perfect. The arguments against: namely that it’s a barrier to entry to newbies (who cannot understand abstraction simple keyword abstraction); that it makes CSS harder to read (because I’m going to use crap naming conventions, of course); and that it isn’t needed (because I want back-end work to do the abstraction? how’s about debugging?!)… Are ridiculous. These arguments are brought forward by people who do so in the name of ethereal, unreachable personas that come out of the void to embrace a mythical ideological CSS theory, and have no sympathy with the practicalities of dealing with widescale-application, modularly extended CSS constructions, which is made nightmarish by such things.
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…
Definitely some interesting thoughts there.
Variables, yes – this would be a great addition to CSS.
Prototype’s and sub nodes – Nahh, CSS is a simple and robust language e.g. if there’s a rule that isn’t understood it’s simply ignored. Putting more validation type features into the language isn’t good. These concepts are too complicated.
I like the mixin concept – it’s still very simple to understand and prevents duplication.
I’d rather other things like float: center; and float: bottom; before having these features though.
Note that Bert’s essay does not speak for the CSS Working Group, it’s his opinion only. Also, if you want to get the attention of the CSS Working Group, posting to your blog and *not telling the CSSWG about it* is really not the best way to go about it. It’s only an accident that I’m here.
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.
@fantasai absolutely, I’ve been working on a spec to accompany these examples, but as it turns out, spec writing is really hard. 🙂 The more I write, the less clear the result. Meh. I don’t expect working group members to visit my blog for feedback, I felt it should be in spec format before I submit it, which is why I haven’t done so yet.
@Mark, how would reflows work if float bottom was allowed? How would the browser determine which nodes changes cause reflows in other nodes?
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.
I saw the Object Oriented CSS video that you link too. That’s very interesting ‘holy grail’ type stuff. As an OO programmer to be able to do OO on the presentation side like that really floats my boat! I do, however, wonder if the technology is ripe enough for that sort of thing to be efficient/feasible at this stage.
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 😉
Nice one. Would definitely make CSS more logical and also cut down on lots of annoying repeated code 🙂
[…] to the CSS working group and I’d love your feedback and comments. For those who have seen my wish list for CSS, yes, there are more posts like this coming, but it turns out that spec writing is monstrously […]