Friday, December 12th, 2008

The fundamental problems with CSS3

Category: CSS

>Matt Wilcox thinks that there are fundamental problems with CSS3 and he shared his thoughts. He starts by giving us some history of CSS and then gets into the meat:

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
30 Comments

+++--
3.5 rating from 35 votes

30 Comments »

Comments feed TrackBack URI

We all see these “issues”, but I strongly doubt these will be addressed in the next 2-3 years. If you want a clean dom, add an extra layer, like xml + server side xslt and there you have it; I know this is not an answer people would like, but we’re just “not there” yet..

Comment by deadcabbit — December 12, 2008

“CSS’s fundamental weakness means that true separation of presentation from content is not achievable even today.”
.
CSS has always been broken, how can you pretend to separate presentation from content with a language :
.
- which his based on the flow layout model, and therefor totally dependant from the source code
- has no property for controling layout (no, float has never been intended for that it’s just a hack, in proper css you should not use it for layout)
- lacks the more basic features that every stylesheet language have since the 80′s (no variable, no simple math, no bases)
.
The truth is that CSS sucks, it’s been designed by computer science folks who refuse to see what works, and constantly reject every possible enhancement.
We only use it because they’re is no alternative.
.
Back to the topic : we need xPath instead of selectors (much more powerfull and much more comprehensible than css3 pseudo-class) and for god sakes : please give us bases and different layout model !

Comment by ywg — December 12, 2008

I think the idea that CSS and HTML can be teased apart is something of a myth. Perhaps that means I’m agreeing with the OP. In practice, if you redesign, 95% of the time you need to change the markup as well as the CSS. But thats ok, because your markup is generated from nice well-thought out templates, right? The post seems to be angling at something like XSLT. We have that already, but who in their right mind would consider XSLT “styling”. I guess I’m saying its not a CSS problem, you need to look further down the stack, and that is as it should be.

Comment by sfoster — December 12, 2008

Sure some points are right. But do we really need javascript inside css? There is perfectly good reason why IE deleted them in IE8..

Comment by V1 — December 12, 2008

Bring back a refurbished version of JSSS + E4X. Turn Tag ID’s into global varables. Take some of the “C” out of CSS..

Comment by TNO — December 12, 2008

The guy who wrote this article is obviously an idiot who doesn’t know why CSS is there in the first place, there’s a reason why JS and CSS are seperated. He didn’t even bother to look at CSS3 as it fixes most of his designer/jquery problems, he must have figured throwing CSS3 in there would be a nice way to pimp his article.

Comment by Jadet — December 12, 2008

@Jadet

I’ve been reading Ajaxian for a while now but I finally decided to register an account because I wanted to tell you two things:

A) Your response is pretty rude and also wrong.

B) In fact it is you who are obviously the idiot.

Comment by okonomiyaki3000 — December 12, 2008

I’m all in favor of adding advanced selectors, that allow more complex math, to the spec. I don’t understand the arguments of those that say this sort of thing shouldn’t be added because it would make CSS too complex – advanced selectors would be optional, and would not affect those who only wish to do basic styling.

Comment by WillPeavy — December 12, 2008

I think the guy is a bit stupid too, but also right about CSS being a bit lame. CSS doesn’t need to have JS in though, in fact it’s a really bad idea.

Firstly he can already do DOM manipulation in JS (or hey, just change the html). You don’t HAVE to use CSS you know. It doesn’t break the semantic web to use JS.

There is always XSLT. Hate it or loathe it, XPATH is far more powerful than even jQuery’s CSS selectors, and it works now if you are willing to do it server side.

Lastly and more cogently DOM manipulation is a hack. All his impossible cases are positioning cases that don’t require any DOM manipulation at all. CSS would be incredibly enhanced by math and query support. It would be awesome to solve his lame unsolveable cases with CSS like:

.menuitem { width: 800/count(.column); }
.column { height: max(height(.column)); }
#copyright { top: bottom(#title)+5px; left: left(#title); }

but I’m not exactly crying for him when he can just use his beloved jQuery for the first two and edit the HTML for the last one. The complexity involved in implementing math and formulas in CSS, not to mention the computation overhead would be massively painful. You’d be wasting all those CPU cycles that you need for JS benchmarks.

The major problem with CSS3 is that the dominant browser is so crap.

Comment by Deadmeat — December 12, 2008

There are definitely pages/layout which need more than CSS3, but I think we’re better moving along conservatively.
1. CSS should never be turing complete (like XSLT)
2. We should recognize that requiring some added classes in HTML motivated by styling is not a horrible thing. In my experience, this process ends up coaxing more semantic information into the HTML than the authors desire on their own.
3. Basic math and variables would significantly improve a style sheet’s readability when I can say width: (#neighbor)+10px instead of width:131px.
4. Manipulation on the other hand sounds like it’s out of the realm of CSS, but perhaps some declarative rearrangement of the elements and their hierarchy would be useful, yet still readable?
5. I also wonder whether SVG will solve these things. The more pages need to look like drawings, why not…make them drawings.

Comment by schuyler1d — December 12, 2008

@shuyler1d – SVG also uses CSS. And it lacks (or at least lacked) some of the things that make HTML good for layout, like text flowing and tables.

Comment by JonathanLeech — December 12, 2008

As much as I don’t like the syntax, XBL is also a pretty good solution to the problem of generating the extra markup. Also, as much as I may like to say scrap the whole thing (html/js/css) and do it better (at least for applications), that would take far longer than getting CSS3 here.

The fact is that even if CSS3 isn’t ideal, it would allow us to do a lot of things we can’t do now. Same with SVG and Canvas and other next generation web technologies.

At some point though, when there’s a layer of cruft too thick to use, we will likely wind up having to use an abstraction layer like gwt just to be productive. Not that these technologies aren’t powerful, but they aren’t quite cohesive, and the cross-browser support will be a nightmare.

Comment by genericallyloud — December 12, 2008

We should replace html/css with canvas like technology, and have google index on formats based on json.

Comment by marcelbeumer — December 12, 2008

I think a lot of problems could be solved if we just had
.myClass {
max-width: ‘as wide as I can be without shoving other stuff off the same row or increasing the width of my parent container’;
max-height: ‘similar to above’
}

Comment by ProggerPete — December 12, 2008

When you disagree with someone, the most likely cause must be that they are “an idiot” (Jadet) or they are “stupid” (DeadMeat). Disagreeing because of the merit of your own position and argument simply isn’t good enough.
.
If you wish to be taken a little more seriously, you may want to attempt to discuss a topic like an adult instead of some childish brat. It’s a bad reflection on you, rather than what you’re commenting on. Facts win arguments, name calling is for the school yard.

Comment by Diodeus — December 12, 2008

@marcelbeumer. I like the revolutionary thinking. Then you could do anything on your page, and still have the semantics in json. You would have to simulate the html controls (textareas, selects) though…

Comment by drewlesueur — December 12, 2008

I agree with Diodeus, you guys need to stop being such knuckleheads plus my dad can beat your dad up so there.

As for all this debate I feel one of the fundamental problems is this dumbing down issue with CSS. Real world developers need CSS to have advanced features, the CSS working group’s response to that is “CSS needs to be simple” so people understand it.

CSS needs to stop only supporting the lowest common denominator. If everybody did that we’d still be writing assembly or ASP or some god awful un wrist friendly language because other programmers can’t wrap their heads around functions, inheritance, reflection, etc.

I say CSS needs to be both. It needs to be simple, but the development community needs advanced features so CSS WG get your @$$ in line and start providing them. All languages have simple features and then advanced ones. You can write procedural code with JavaScript and you can write Object Oriented code. I want multiple background images, I want variables, I want better layout techniques, fonts, text shadows, animation, element shadows, transforms, and I want it all yesterday :)

Comment by someguynameddylan — December 12, 2008

I have never worked with jQuery yet nor will I see the need for me to do so. Would I need to have to in the future, to learn a js-lib for my CSS Stuff?

I see much need in css-maths like
width: 100% – 200px;

:)

Comment by gossi — December 12, 2008

The post is awesome and totally right to bring this all up. I don’t think CSS needs everything it proposes. For example, variables are great, bug not really needed IMHO. I think that math has to come sooner or later, 100%-10px and 800px/3 has to work right. I’m tired of creating thins like the folowing because of the 1px rounded down:

#something .left {width:266px;}
#something .center {width:266px;}
#something .right {width:267px;}

I think DOM traversal is a little too much, but DOM inserting sort of exists today with p:after {content:’.';} it only could be more complete:

.blocks {insert-before:''; insert-after:'';}
#content {insert-wrapper:'';}

Or it could be even simpler:

.blocks {insert-before:'span.round-top'; insert-after:'span.round-bottom';}
#content {insert-wrapper:'div#content-wrapper';}

Comment by Irae — December 12, 2008

DSSSL?

http://www.jclark.com/dsssl/

I remember reading about this 8-10 years ago — a book I was perusing in the local Borders had chapters on both DSSSL and CSS. And some of the advantages of DSSSL sounded quite a bit like what Wilcox is after here…

Comment by westonc — December 12, 2008

Just wanted to drop a line for everyone who likes to get to the bottom of stuff :)

Pretty much all of us use some kind of template engine. And the server side is a perfect place to pursue expressions like 100%-10px or 800px/3. It looks like this: 100%- and 800px/ (examples in ASP, but you get the point I assume). Basically you just run expressions on server-side.

The problem – something changes on client-side. The solution – use javascript then. Hint – javascript is text and can be also generated from template. Using same objects and values etc.

What I don’t want to see, is implementations of CSS3000 with variables and whole blown language and whatnot created by 3 different teams. One would be perfect but slow, the other fast but rough on edges, and you don’t want to even consider the possibility of something like this coming from the land where the shadows lie!

Comment by justforthiscomment — December 12, 2008

I think the analogy of painting a whole scene on a canvas is fundamentally wrong. If you want to do that open Photoshop, create a new PSD document and go crazy. HTML pages are interactive, which means you need some sort of structure for the content, and that implies limits. Absolute separation of content from presentation in programs of any kind (and that includes web pages) is impossible – it’s like trying to build a building without any regard for physics – you cannot just put up whatever you imagine.
You can introduce extra layers of script, language, or what have you, that separate (in this case) css from html, and they might give you the illusion of content and presentation separation but that’s ultimately what it is – an illusion.

CSS is not perfect but it’s a good start and it’s moving in the right direction. Adding “DOM traversal, reference, and injection” to CSS breaks another desired separation idea – functionality and presentation. If CSS is only about layout, and that’s what it is, and should stay so, then it shouldn’t be able to mess around with DOM.

You have HTML for content, JS for functionality, and CSS for presentation (roughly speaking). Neither of these is perfect, and in many instances they tread on each other’s domains, but I believe as web grows and as each is evolving they will keep improving in that regard, and DOM traversal is a step, nay a leap, backwards.

I do agree, however, that the whole process should be faster – there’s no good reason why HTML5 and CSS3 are taking so long other than bureaucracy.

Comment by iliad — December 12, 2008

So ok, examples are busted, I’m sorry. Here it comes again. Hopefully
_____
Just wanted to drop a line for everyone who likes to get to the bottom of stuff :)

Pretty much all of us use some kind of template engine. And the server side is a perfect place to pursue expressions like 100%-10px or 800px/3. It looks like this:

100%-<%= Consts.widthOfSth %>
800px/<%= Consts.NoOfCols %>

(examples in ASP, but you get the point I assume). Basically you just run expressions on server-side.

The problem – something changes on client-side. The solution – use javascript then. Hint – javascript is text and can be also generated from template. Using same objects and values etc.

What I don’t want to see, is implementations of CSS3000 with variables and whole blown language and whatnot created by 3 different teams. One would be perfect but slow, the other fast but rough on edges, and you don’t want to even consider the possibility of something like this coming from the land where the shadows lie!

Comment by justforthiscomment — December 12, 2008

The poster is spot-on. Most responses that argue otherwise give examples of workarounds or even hacks- only validating the point even more.

For the equally spaced tabs example, how hard would this be:

ul.tabs li {
width: distribute;
}

Seriously, look at absolutely any design application and take a hint.

I do not see the need for dom manipulation. That would just be a new method to implement the same old hack- wrapping everything in n divs just to get a reasonable level of control.

Comment by Bub — December 13, 2008

I must agree with Matt.
Creating a couple of divs just to make my navigation bar with rounded corners without the use of JS is completely missing the point.

Adding s here and there to create custom backgrounds for elements that already have background, is again, missing the point…

how about floating object, but in the center?

And I agree about basic math, hopefully some of Matts’ ideas will be picked up, and rather then giving us pre-built solutions, we will get better tools…

Comment by Eli — December 14, 2008

How about this simple solution: make “50%%” mean “50 percent of the remaining space in the container when taking into account all non-%% sized elements”. This solves most problems people want math for, and introduces flex elements. And it does this without requiring dramatic changes to how css works.

Comment by Joeri — December 14, 2008

“The truth is that CSS sucks, it’s been designed by computer science folks who refuse to see what works, and constantly reject every possible enhancement.”

The inverse is that designer refuse to see that wiring and automatizing every case is not the solution.

There is CSS and JS. Maybe the solution is to allow JS in CSS.

Comment by nithril — December 15, 2008

This discussion reminds me of the time I applied for work at Opera, I met this guy I didn’t know who were (Håkon Wium Lie) and he asked me what I thought of CSS (he’s the initiative owner of CSS and wrote his PhD thesis on it) and I told him I think it sucks and that XSLT was a far superior technology and should have been used instead…
.
This was almost ten years ago, needless to say I didn’t get the job … ;)
.
Anyway, I tend to agree with mostly all here, though a great start would be to get people to implement what’s there TODAY…! (—as in MSFT, ARE YOU LISTENING…?)
.
98% of my “troubles” with CSS is getting Internet Exploder to work with the damn thing that “all other browsers just takes for granted”…
.
And I don’t really think there any other ways to get those guys to listen then to *stop-caring* about IE which will make the entire web have two looks in 5 years from now; 1) Normal, through any std compliant browser. 2) Exploded and impossible to use, through Internet Exploder based browsers.
.
When we get there IE will either fix itself or cease to exist, anyways I’m in better moods … ;)

Comment by ThomasHansen — December 15, 2008

I really like the dynamism of the debate and the topic itself… it’s really good for the community to bring these questions and reflect extensively on them. Totally new to ajaxian and lovin’ it already…

Now, to the topic: I love being able to completely alter the presentation of an html document using simple and very high-level descriptors, eve if it is through hacks that twitch the original purpose of the language. CSS was *not* built with layout in mind, it just turned out to be a far better alternative to tables… Sure, I’d love to write width:100%-200px center and then see it work even in Internet Exploiter, and I too have experienced frustration when the perfect, most semantic, lightweight and simple-to-maintain solution to a layout (yet again, the “L” word) challenge needed only a simple if statement somewhere in the description.

But DOM injecting, querying and manipulation? IMHO, not for CSS… JS does it well only thanks to frameworks! But you know what? rather than advocating for more “complex” CSS, I say screw the DOM! It’s an excessively and unnecessarily complex solution to a much simpler need: the parsing and rendering on information, which is increasingly dinamically generated.

I say the X in Ajax it’s the way to go, and the sooner the better.

Comment by Aldebaran — December 16, 2008

As I commented, more powerful pseudo-elements would take care of much the problem of missing DOM hooks. We were just starting to scratch the surface with ::after, etc. when progress stalled (cough IE).

Comment by mrclay — December 18, 2008

Leave a comment

You must be logged in to post a comment.