Friday, December 12th, 2008
Why the Cascade is no longer enough
HTML has been re-purposed to represent only the semantic properties of the page. Because CSS is only capable of cascading through the DOM, that means CSS can only be applied to elements that have semantic meaning. The trouble is that web-design today is more art than decoration. I’m not taking one wall and painting it green, I’m taking one canvas and painting a complete scene on it.
- There are many times where a designer wants to create or manipulate a visual element for which there is no semantic hook.
- Because CSS can not query, freely traverse, nor manipulate the DOM, we are forced to add non-semantic hooks to the HTML.
- Because CSS can not query, freely traverse, nor manipulate the DOM, designs are dependent on the structure of the mark-up.
CSS’s fundamental weakness means that true separation of presentation from content is not achievable even today.
And then, What does CSS need to overcome these problems?
irst let me say what I think it really does not need. It does not need more ill thought out modules that provide half-baked solutions to explicitly defined problems and take a full decade to mature. We do not need the Working Group to study individual problem cases and propose a pre-packaged “solution” that either misses the point, is fundamentally wrong, or is inflexible (Advanced Layout Module, Marquee Module, display:table;, – I am looking at you). Here’s what we do need:
- DOM traversal, reference, and injection on the same order provided by jQuery. There’s a damned good reason why designers are flocking to jQuery.
- Programmatic variables, and basic Math
he crux of the issue is that W3C seem to try providing high-level “solutions” instead of low-level tools. It’s a limiting ideology. With the CSS3 WG strategy as it’s been over the last decade, they would have to look at all of the problem points I proposed above, and come up with a module to provide a solution to each. But by giving CSS an ability to traverse and manipulate the DOM, we designers can build out own solutions to all of them, and innumerable other issues we have right now, and in the future. Allow me to give an example; take the first “impossible” CSS challenge above, the unknown number of tabs that must fill a given width. It’s impossible – but the Multi Column Module does in fact allow the exact same functionality – you can specify a container of a given width and then specify a given number of columns (which you can change), and CSS will do the math internally to get the right widths! But I can’t use that module to achieve what I need with the tabs, despite it having the same basic function! Because they’ve provided a pre-packaged “solution” to a very specific problem instead of giving a more abstracted set of tools with which I could build my own solution.
All of the “impossible” CSS tasks set above can be solved by providing CSS an ability to inspect and modify the DOM, and use basic Math. And I can think of a dozen other impossible things that would rock if I had those tools in my CSS.
The CSS WG argue that CSS is meant to be simple, whilst missing the point that CSS is not meant to be anything. It’s a tool that must do a job, and the job has changed over time. CSS needs to keep up with requirements, and the best way to do that is provide adaptable tools rather than pre-packaged modules. There’s continual argument that maths, and dom traversal are too advanced for CSS, which is utter rubbish. I contest that if we are expected to understand selectors like nth-child : 4n+3; (explained in the CSS3 spec as “an element that has an+b-1 siblings before it”) then we can cope very well with creating and assigning variables, a little flow logic, and doing some simple adding. If we can handle jQuery, we can handle that.
What do you think? How would you like to see CSS changed? Would you like to separate style from layout?
Posted by Dion Almaer at 6:55 am