The fundamental problems with CSS3
This post brings to a head a lot of my thoughts and feelings with regard to CSS3 and the way the W3C is developing it. It does not aim to look at specific topics in detail, but to step back and question some fundamental issues that I feel need to be addressed.
What was CSS created to do?
I need to establish a little history, but if you’ve been a web designer a long time, you can skip this section.
CSS1 was released 12 years ago, in 1996. At that time the current version of HTML was HTML 2 (HTML 3 wouldn’t be out until the year after). HTML controlled the layout, the look, and the information of the page - it did everything. Tables were the only way to do any layout, and web design consisted of slicing up graphics which were then placed into table cells to position them.
CSS was created to provide a better tool for developers to control the styling of HTML elements. That’s a carefully written statement. CSS was not designed to “control the visual presentation of a web page”; it was designed to control the visual properties of specific elements that existed in the mark-up. i.e., CSS offered a way to control fonts, colours, and sizes, all in one place. But that was all it was really meant to do. If you look at the specification there was only one property in CSS1 that could be used to effect layout - float. position didn’t even exist, and in HTML 2 neither did <div>, the two essential tools without which no modern design could be achieved (without resorting to tables). When CSS was released, using it for the layout of an entire page was barely even a concept, and it certainly wasn’t possible.
A lot of what we use CSS to do today wasn’t in the original scope for the technology. As CSS and HTML evolved some forward thinking people came up with a web development work-flow we are now all familiar with, but which was revolutionary at the time. That was where Zeldman, Meyer, Molly and co came in and introduced the modern Web Stack. HTML’s role was re-defined as conveying the semantic context of the page, CSS was expanded to include responsibility for the layout and presentation of the page as a whole (rather than the individual elements within it), and JavaScript was re-imagined as being responsible only for user-interaction and behaviour of the page. Content, Presentation, Behaviour. HTML, CSS, JavaScript. With this new thinking out went layout-tables and presentational mark-up, in order to promote the separation of content from the presentation and the behaviour. Result: things loaded faster, were easier to develop, redesigns would be easier, the web would be more semantic, the disabled could use the web, and progress in general could be made. Three cheers to everyone involved!
What are the design implications of how CSS works?
CSS was designed to work with whatever HTML was in the page. You point it at a specific element and you tell it specific things about that element to style: “look for paragraphs and change their colour to green”. The Cascade is a critical part of how this is managed. And because all CSS was designed to do was change a few visual properties of existing elements, there was no need for anything more complex than that.
The continuing omission of anything more powerful than the Cascade is the one serious hold-over that cripples the entire Web Stack to this day: CSS’s only tool for inspecting the DOM is the passive method of the Cascade. The result is that an element knows only about its direct ancestor elements, and can only do “simple” inheritance (my parent is green, therefore I am green. My parent has been positioned, therefore I take my position reference from my parents’ origin point). The limitation of the cascade is the single biggest problem with the Open Web technologies today, and it’s the one problem the W3C refuse to address.
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.
How are we working around CSS’s lack of capability?
Regardless of best practice, we need to add non-semantic hooks to the HTML in order to produce modern designs. To avoid contaminating the mark-up directly, the task of adding this “litter” is often given to JavaScript, which is used to traverse the DOM and wrap/append/prepend countless <div>’s to the mark-up, which can then be targeted by our CSS. Take a look at any JavaScript library, or effects library, and you’ll find a large percentage of that code is concerned purely with achieving this. This is not what JavaScript is intended to be doing. These are display issues, not behaviour issues.
Even discounting this problem of requiring “wrapper” mark-up, CSS still fails us; allow me to give a few examples of fundamental things which are impossible with CSS:
- Create a tabbed pane such that an unknown number of tabs can adjust their dimensions to ensure the tab-row always occupies a total given width. e.g., I want the tab row to always be 800px wide, whether there are three tabs or five tabs. (display:table is not an option, for the reasons given here)
- Ensure that one semantically arbitrary (but visually linked) content block is the same height as another. e.g., ensure the “news” pane and the “poll” pane are the same height as they are visually linked, despite them having different ancestors and not being siblings in the mark-up.
- Position a given element relative to another given element, that is not itself a positioned ancestor. e.g., move the “copyright” message that’s at the end of the mark-up to be directly below the
<h2>near the top of the mark-up. - Create a layout that adapts by grid unit.
If you are thinking of a solution to any of those problems which involves re-organising or re-writing the mark-up that is exactly the problem.
What does CSS need to overcome these problems?
First 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
The 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.
The W3C attitude to non-specific architecture changes is summed up here (emphasis mine)…
On inspecting an object to determine a value and use that value on a reference object (e.g., create equal height columns that don’t rely on mark-up order):
I think we’d need a lot of detailed use cases to understand exactly why something this complicated and this powerful is needed
On positioning relative to another element:
A feature like this would be extremely complex and difficult to design and implement. Without concrete use cases to define the problem, there no way to even understand the requirements for creating such a feature
I think the problem is exactly the opposite. Step back and look at how CSS is making separation of semantics/display/behaviour impossible and understand how those suggestions fix that and allow massive flexibility. The problem with CSS isn’t that I can’t always do fancy things (though often it is), but much more importantly, that I can’t do many things at all without corrupting the web-stack in the first place. I’m talking about fundamental architectural problems, not petty display grudges.
Further reading
Just in case this hefty post hasn’t bored you silly, and you find this article interesting, you may be interested in a couple of related older posts: Why CSS needs to borrow from programming languages, The fundamental problem with CSS is it’s reliance on the DOM, and CSS Tables for layout are a bad idea.
Entry Information
- Posted:
- Tue, 9th Dec 2008 at 23:12 UTC
- Filed under:
- Tags:
Comments
skip to comment formI agree wholeheartedly with this and your previous article about CSS tables. There certainly is a necessity to style a document independent of its markup. We cannot speak of true separation of presentation and content if there's a constant necessity of adding or moving around elements (or just as bad, class names and ids) to achieve various design goals.
I apologise for the bad experience using this site. I’m aware of how bad the form is, it’s one of the things responsible for the banner at the top of the page saying I hate my site and a redesign is on the way. I have temporarily eased up on the email and URL filtering.
It's still nearly impossible as a designer to get a HTML document from an external party complete with all the hooks you need to get a working CSS design going. Even if the external party is a capable, well informed, standards aware programmer or fellow designer. And it shouldn't even be that way, there should not be a need for spurious elements and attributes to get your style on.
Maybe Javascript truly is the future of styling content, just as it was proposed in the past (http://en.wikipedia.org/wiki/JavaScript_Style_Sheets), albeit in a different form. The need for variables, node selecting and even styling are all covered by JS so I don't see the need to create a new language. I can only dream of the day that it's standard(ized) practice to just select a bunch of nodes, iterate over them and apply styles to only those nodes I see fit based on whatever arbitrary condition I might phantom. Maybe I could even style nodes based on their child content, now that's a common heard idea you hadn't yet mentioned.
The easiest and fastest way would be just allowing Javascript in style blocks. If some standard could formulate the implications of [style type="application/javascript] and [link rel="stylesheet" type="application/javascript"] things would be easier. We could even use CSS and JS side by side. It's not the attributes of CSS that are lacking, it's just the selector model.
PS. For some reason this form kept complaining about my email address. Luckily I have a bunch of email address, the one I used now appears to be accepted. The validation seems to take offense in using dots in the username part and dashes in the domain part.
PPS. The URL field also has some validation issues. It did not accept my url with dashes or with a http prefix.
PPPS. The title (as in the HTML element) of the error page is "Success"
Matt Says: Thanks for your input
Whilst it would be nice to have a technology that didn't require constant work-arounds and "make-dos" I do wonder, especially in light of the first comment, whether something like jQuery is what we need.
Another layer, if you will. That in itself is a workaround but it's one I can live with.
I have to agree, personally I feel that CSS (and HTML for that matter) is fundamentally heading in the wrong direction. Your comments regarding "pre-packaged solutions" hit the nail on the head. Give us the tools to roll our own instead of set solutions to set problems.
The popularity of jQuery among designers and developers says it all. Advanced DOM traversal + Math + DOM manipulation is in high demand.
jQuery meets these demands, and does a damn good job of it too but at the cost of littering our behavioral layer. I'd love to see a jQuery style API as a part of the CSS spec but until then (or until something better comes along) I'll be sticking with jQuery to patch up CSS's shortcomings.
"The crux of the issue is that W3C seem to try providing high-level ’solutions’ instead of low-level tools."
This is 100% spot on. Part of what makes CSS so great is that, in everything before CSS3, we were given low-level tools. Even if CSS as we use it now is missing capabilities, I'd rather have today's strong language that lets me do almost anything than the current direction of CSS3: an inconsistent language that still doesn't let me do everything, design-wise.
I've agreed with you before, and I'll agree with you again.
Most of what we are wary about is using Javascript to control the presentational or visual layer. We all know that the behavioral layer is what we use Javascript for. That being said, is there a reason Javascript can't also be used for the presentation as well? The first analogy that popped in my head was this:
Square == Rectangle
Rectangle != Square
Behavior == Javascript
Javascript != Behavior
If we can get over the fact that it feels odd for one tool to have control over multiple sectors, would the web be a happy place again? To reiterate, I still find this idea to be "not right." Guess I'm just trying to make sure I view it from all angles.
If only XPath and XSLT could apply to HTML we would be able to select all kinds of crazy things or even transform the whole document to fit our needs.
Now I think of it, both could apply to XHTML, sadly that standard has been killed by content producers because it never was properly implemented. By which I mean, sending it as text/html and pretending all is well even though browser handle it as normal tagsoup.
Speaking as someone who both designs and codes, XSLT is a truly horrible system and must be destroyed.
I agree with your sentiments and reasoning completely Matt.
@andrew ingram I've got to protest there.
Ive used xslt (and lots of other languages) for years, and while initially it can seem a bit shoddy, I find it actually quite good if you know what you're doing. It forces your code to be well formed and theres not a single instance when I've wanted to something, and havn't been able. It might be more code than other languages, but it does work for certain applications.
Imho we need one feature above all:
positioning relative to other elements.
let's say you want 2 rows, row1 with its height according to its content and row2 from row1 to bottom.
If you could say:
#row2
{
top: #row1;
bottom: 0;
}
it would save us all sorts of problems.
And it would/could be so simple to use.
Matt says: I proposed that, it got shot down. Glad you agree though.
I can't see why you need JS in CSS when you already have JS in HTML. If you want to use JS for manipulating HTML, just do so, you don't need it in CSS. If you like JQuery so much, just use JQuery. Using JS for look and feel doesn't affect any of the uses of purely semantic content. Since they all ignore JS and CSS.
As for math support. I'm largely on board. I'd personally replace DOM maniuplation with pure DOM query in your math formulas. Most of your probelms would be solved if you could query the width, height and number of other DOM elements. I'd be looking for basic math functions, count, sum, floor, ceiling, min, max, etc, plus a few layoutisms, height, width, top, left etc…
.menuitem { 800/count(.menuitem)px; }
.column { height: max(height(.column)) ; }
To be bluntly clear:
CSS3 already has most of jQuery's selectors.
DOM manipulation in CSS is a bit silly when you can modify the DOM in HTML, or JS.
If you insist on rewriting the document, you really should use XSLT. XPATH isn't as simple as CSS selectors, but it does everything you want plus a whole lot more. It could do with improvements of it's own of course.
The biggest problem by far with CSS3 is that the most popular browser is such a pile of s***.
Matt says: I want it in the CSS because that’s how to respect the separation of content/behaviour/style. I know a lot is do-able by abusing the role of JS, and practically speaking that’s exactly what a lot of us have to do - but it’s still wrong.
Ever looked at XUL? It makes so much more sense than CSS (although it uses CSS for styling) for layout.
Here's the point, I think: CSS stands for style, not layout. It's not inherently better, as it stands, than TABLES for layout.
PS: Note that you can force XUL-type layout behavior on HTML elements in Firefox by using its CSS extensions (-moz-box, etc)
I'm from the old fashioned school that believes in 'truth to the medium'. In other words, if you are carving wood, you respect the grain. You work with it, not against it. Like it or not, the medium and the tools we are given, are only as good as the workman using them.
I don't need to know the chemistry of acrylic paints to paint. Artists of yore had to know how to make their paint but not any more. I don't want to fight with paint and canvas, I just want to use it. The process between thought and action should be transparent.
HTML and CSS are not perfect tools for the creation of a Web page but if the designer uses them instead of abusing them, there will be a better chance of success.
You know what they say about bad workmen blaming their tools?
I say, "stop decorating and start designing". The medium is NOT the message, it is the messenger. Stop blaming HTML and CSS because it won't what you want it to. Do something else. Be creative!
Matt says: I rather think you’re missing the point. There are NO tools to allow flexible layout on the web. If we don’t invent better tools, then we only get more intricately botched solutions. Imagine if people never invented better wheels because they were happy with the nice wooden ones on carts. You’d never have anything like a modern car. Building better tools drives better end results. You can’t suddenly leap to amazing results if the tools don’t work well enough.
Matt,
Great write-up and I whole-heartedly agree! I think what it broils down to is programmable CSS, though that sounds a bit like Microsoft's .htc behaviors???
Still, I think we essentially have all the components in place and I'm not certain it makes sense to expand the CSS syntax to provide things such as math. Perhaps down the road as a higher level layer. But in order to get things to move quicker (as in: not waiting 5 years for the browsers to catch up to the spec - if ever…) we'd just need a standardized way for CSS and Javascript to interact better.
That includes not only deferring styling to script as Jaap suggested above, but also the reverse - manipulating stylesheets objects from within Javascript which remains a PITA to this day. Needless to say that for something like that function properly, browsers need to correctly support the current CSS standards in the first place, plus provide proper results for computed/geometrical style data.
Cheers,
J
I'd have to say that DOM manipulation should not be in a style language. The document should be able to fail in such a way that absent CSS or Javascript one can still navigate the site and make use of the information presented. If you're depending on manipulating the structure of the document for it to function properly in it's initial state, then it isn't a shortcoming of the style language: you've poorly designed your data.
Further, the logical operations needed to decide what to do with the DOM are all present in ecma-262. jQuery et al provide a convenient interface to the DOM handling api but are not necessary. It's reinventing the wheel and doing it a third time in CSS seems an unnecessary waste of talent. It reminds me of when people thought adding loops and other programming primitives to XML was a good idea. It wasn't.
Truth is people always reach for some sort of Plato's perfect object of separation of data, style and programmatic ops as a de jure holy grail. But de-facto we're always going to be less than 100% there.
Excellent article!
For as long as I can remember, I've wished CSS had variables and math. But also giving CSS the ability to traverse and manipulate the DOM like JQuery is simply genius.
It would certainly be nice not to have to rely on Javascript for what should otherwise be simple layout and presentation challenges. More and more I find myself blurring the line between the presentation and behavioral layer.
The problem with blurring that line is that I have to then maintain very interdependent code in two different languages, plus I'm stuck with the overhead of a Javascript library.
"If only XPath and XSLT could apply to HTML"
DSSSL?
http://www.jclark.com/dsssl/
You can do math, you can do most if not all of what you can do with both CSS and XSL, and it's purposed for this, unlike Javascript.
Maybe the browser world missed the boat 10 years ago by picking CSS…
The problem is that Microsoft inversely gains from improving the ease of browser development. The easier it becomes to develop software using open source tools(No Visual studios) on an OS-independent platform(The web with browsers) the less money they make.
Google's recent project (Native Client) is what I've been waiting for as a C++ developer. It basically allows you to run native code(assembler) in browser. But then has security mechanism so that the code cannot do anything to the client computer unless the user of that client has given the container(Sandbox) that runs the code permission.
This will allow people to build their own UI frameworks, that render much more rich graphics and hopefully behave the same no matter what Browser/OS combination you are running on.
References:
Announcement:
http://google-code-updates.blogspot.com/2008/12/native-clien…
Native client code base hosted at Google code:
http://code.google.com/p/nativeclient/
Ars Technica review:
http://arstechnica.com/news.ars/post/20081209-safer-than-act…
Do people really think we'll ever reach a point where different vendors building code-bases based on documentation built by a committee will ever behave even remotely the same? Have you read any of the W3C documentation, it's f****** ridiculous. We should be sharing implementations, it's the only way to ensure bit-level identical behavior of a target system(Performance characteristics aside).
I really hope Native Client takes off. In combination with Gears for client side storage it would allow us to build desktop quality software but with the web advantages of cross platform development, zero install applications(well as long as you don't consider caching a form of installing), user's pulling down the latest client at all times, and etc.
Awaiting our new Google overlords. Endergen
Have you checked out XBL 2 (google XBL2)? Although not implemented yet, it may do some of the things your are describing. We might see it in Firefox 4 or 5.
Consider this comment a whole-hearted endorsement of your position. Insightful, sir, and spot-on!
Thanks for your responses everyone, I am glad that a lot of you are thinking along similar lines. From what I'm reading however, it's also clear I still have some work to do to explain why CSS with computation and DOM manipulation is not simply essential, but also does NOT harm any of the ideology behind CSS/HTML/JS.
I'd like to point out a good comment thread on this topic that can be found at http://news.ycombinator.com/item?id=395614
@tack "If you're depending on manipulating the structure of the document for it to function properly in it's initial state, then it isn't a shortcoming of the style language: you've poorly designed your data." - I absolutely agree with you. My requirement of DOM manipulation directly in CSS is NOT about making semantic changes. With CSS off the document should be perfect. However, a properly ordered and marked up document limits design and layout choices at the moment. A lot of things simply can't be done - which is why sometimes you HAVE to have the menu at the top of a page when it ought to be at the bottom. Why you HAVE to have cerntain elements in a certain order despite it being semantically backward - because otherwise a design can't be done.
When I say CSS needs to manipulate the DOM I'm really talking about some sort of pseudo-DOM, a Visual Object Model. An abstracted presentational layer onto which CSS can be applied. The semantics should never change. This is entirely about getting CSS able to provide flexible styling WITHOUT manipulating the semantics of a document. Which is why the jQuery solution fails - although it does what we want, it also mangles the DOM.
Matt, I think you sort of have a point but some of your article is irrelevant or inaccurate (and I'm going to offer up somewhat of a dissenting argument).
) and then I think we'll see some progress.
1. CSS1 was designed for HTML documents but CSS2 was designed to be agnostic. The use of "display:table" isn't so much for semantic nazi's to say, "hey, don't use tables for layout" but rather to have a way to say, "here's what's required to make a set of elements behave like an HTML table, whether that's in HTML or XML".
2. I agree that neither CSS1 nor CSS2 really solved the layout issue. Position relative/absolute/fixed was really all there was. display:table and floats are creative solutions by the community using what they have available. CSS3 is trying to solve this with grid and template layouts. Whether they hit the mark remains to be seen, mainly because no browser maker has decided to implement them. The W3C can dream up the very best layout spec in the world but it means nothing if IE, Firefox or Safari choose to ignore it (I think display:table is a prime example of this).
3. Having DOM traversal in CSS doesn't solve the problem. The fact is, CSS is complicated and we can't assume what would be easy or difficult for a browser developer to implement. Constants, for example, sound brilliant. But, do they cascade across all documents? What if one stylesheet, where your constants are defined, doesn't load? (maybe page-only constants is the solution.) Some simple element relation would be nice but what about something like this:
#a { height: #b; } /* element A equals height of element B */
#b { height: #a; } /* and now vice versa; um, how high is it? */
You can see where it suddenly because a damn right pain in the ass to implement this kind of feature (and is the reason your idea got shot down).
The fundamental problem with CSS1 and CSS2 is that neither solved our layout issues (or really came that close to trying). The fundamental problem with CSS3 is that it's still being developed. Nobody has yet to define a solution to the layout problem that browser developers feel confident enough to implement. Somebody needs to come up with that solution (maybe you, Matt
With that said, I think many of the tricks we try to pull off these days will be solved once browser developers implement many of the simpler CSS3 features already defined like multiple backgrounds, border-radius, border-image, and CSS transformations (as seen in Webkit builds and IE via filters).
Firstly let me state that I am not a long-experienced web designer, nor do I consider myself an apologist for the W3. I agree with you on some parts regarding deficiencies with CSS, but disagree with most of your conclusions, as I hope to explain below…
First of all, I believe you are incorrect to state that HTML should be (or has evolved to be, or whatever exactly you're saying led to it being) used only for semantic information. Yes, there is the concept of Semantic HTML, and certainly it seems that HTML should be used for semantic information; but I object to the argument that HTML is only suitable for semantic information. On the contrary, HTML is suitable for *content*, and not just semantic content.
One of HTML's (along with SGML and XML) important features is organizing the content of a document into a hierarchical tree. Some of this hierarchy may provide semantics, but much of it does not. Is the fact that a particular paragraph is a child of a div representing a chapter of a book semantic information? I'm not a linguist, but to this layman it doesn't appear to be.
In other words, document content is not just about the semantics of the text and images displayed, but also about its structure.
(You can read more of my lengthy response at http://blog.sacrilicio.us/2008/12/13/response-to-matt-wilcox/ )
@snook
Thanks for your thoughts on this. I think we actually agree on the majority of points, and don't get me wrong - this post is from the "purist" side of the argument. Day to day, I'm all for the pragmatist solutions, I use them a lot. But, I'd like for CSS to aim higher than "a series of acceptable hacks". My solutions may well not be right - but neither are any of the W3C's yet. With that said:
CSS 2&3, agnostic or not, still suffers from the basic issue of having too few and too inflexible tools for layout. The display:table issue is a symptom of that. The idea of using tables for layout is a throwback, and all display:table does is emulate a layout hack that was imperfect to begin with - the only advantage of which is to remove the semantics problem - it remains highly dependant on the mark-up order and structure. So, as a layout solution, it's not good enough on multiple levels.
I also agree that this all depends on the browser vendors. However I've looked into the CSS3 modules quite a bit, and for me those modules fail badly. The W3C solutions are all about slicing & dicing content into a table. All these modules do is find a fancy new way of defining the table. I have little hope that any of CSS3's modules will solve the problem of allowing me to create any layout I wish from one unchanging HTML document. In fact I am working on a few example documents to show some things I'd want to do, but can not. Hopefully they will clear some things up that my writing has not. The modules proposed do not answer the layout problem well enough because the proposers seem not to have listened to a designer in order to understand the problem properly. And when they DID try getting a designer on board, he quit citing insurmountable problems with the Working Group and W3C process.
With regard to your point about the difficulty of advancing CSS's featureset: It is not my job, responsibility, or care as to how hard or not it is to get CSS to do certain things. The fact of the matter is that jQuery has better support for CSS selectors than any of the browsers we use today. It's exactly what Eric Meyer has been talking about when he commented on John Resig's Sizzle engine. It's not just about selectors though - CSS requires some other bits and bobs from the JS world to do it's job properly, and that is exactly why designers are using tools like jQuery to get layouts done. We are already using a tool to traverse and manipulate the DOM to then apply and calculate CSS properties. It's just all in the behaviour layer when it should be in the display layer. My real point is this: the W3C continue to argue that it's hard to implement practically anything in CSS. Well, look at JavaScript and you'll see it's already doing everything we want. So it can be made to work. All of the problem area's with a programmatic and DOM-capable CSS have an equivalent in JS. Which is fine from a pragmatist standpoint - we'll end up all using JS to produce our visuals - but at the price of requiring JS (a behaviour layer tool) in order to produce an acceptable layout.
PS in your example; I'd fully expect that column A and column B are equal height given that code, and have expanded to display whichever is that largest content area.
There's a lot of promise with CSS3, as you point out, and I'm looking forward to using the features available in it more than I currently do. However as we both agree - the major issue is a continuing inability to produce a layout that works without relying on a particular structuring of the HTML; for which CSS3 does not have a solution (Advanced Layout is not flexible enough).
my concern with css is that is not practical to write reusable components, the language itself laks tools to do it, basic math and variables but class like inheritance too, can alleviate this problem.
I agree with you, Matt. I think you're spot on in most of your criticism. While I'm not sure that CSS should be all about tools and not about specific solutions, I have to give credit to the idea that CSS3 is moving way to deep into the solutions quagmire. The "Advanced Layout Module" is a perfect example of this.
You’ve understood me perfectly, and hopefully someone will understand your explanation better than mine 
I think your idea of a "VOM" (Visual Object Model) is excellent. It gives way for another virtual layer on top of the semantically marked up content that is the HTML document, and with it separates the hooks for visual style away from the structure of the document.
When you talk about transforming the DOM with CSS, what I think you really mean is transforming style-able DOM so #menu can be positioned relative to #header even though its element appears somewhere else completely in the HTML DOM tree. Thus; VOM.
Yea, the more I think of it, the more I think having a VOM would be the correct solution. Whether the VOM is created with JavaScript, XSLT, XUL or whatever isn't really that interesting. What's important is that the CSS WG understands this and realizes that this indeed is an issue that needs to be addressed.
Matt says: Thanks
Quite a lenghty post and even more so: quite a lengthy discussion.
After reading the post first I had the feeling that I disagreed with you on a lot of things. But reading the discussions (ignoring all 'the yes you are right, great post") I have come the conclusion that we could be agreeing to a certain point.
When I read your article with your desire to completely separate content, style and behavior in the back of my head, than YES CSS3 fails. But so do other versions of CSS. This :hover thing isn't that behavior? Someting happens on screen because a cursor moves.
Your other desire seems to take a completely semantic html document (with no structural markup, no ) and the apply css to really style it anyway you like it. A semantic CSS zen garden. An interesting experiment.
A holy grail type achievement when you succeed. If you succeed.
I have been experimenting some time ago with 3 column layouts without any divs and as little classes or IDs as possible. I came a long way, but in the end it all was no more than an interesting excercise.
I have the feeling that you try to achieve things a bit beyond what you can (or maybe even should) achieve with CSS.
On the other hand it is good to be critcal at what is coming at us, but for the time being we have to work with the tools that are available. With the slow implementation of parts of CSS3 we get more tools to the job and all the bright minds of developers around the world combined will make new inventive use of those.
We are not there yet, we are still on a very long journey.
I have posted a long-ish reply to your post here:
http://news.ycombinator.com/item?id=395820
I'm going to summarise here, that I wordily break down in my second post:
I have a different opinion to you. We have different opinions on the extremes of separating design and content and the purpose of CSS. You think they should be completely seperated. You have a solution that does this. This solution is not necessarily the best one. You're choosing the most flexible choice, but "most flexible" has its own set of trade-offs that don't automatically mean best, and in your search for flexibility you avoid considering the advantages of the proposed CSS3 layout model, most notably accessibility and relative simplicity, and ignore potential syntax problems of flexibility. Any potential syntax which allows unrestricted access to the DOM could easily lead to unmaintainable code much easier than the other CSS solutions. Additionally, nothing is stopping you use JavaScript and jQuery for layout today - it basically is the CSS that you're after, and I don't see why you're trying to make CSS be something it's not designed to be.
You are also overly broad in criticising CSS3 when it obviously makes some big fixes (improved selectors and calc). Oh, and display:table has been around since CSS2 back in 1998. Saying "it's come to this" but in reality float hacks weren't supposed to be the be-all and end-all to begin with. I see "display: table" as generally a good thing.
Matt says: I know there is nothing stopping me using jQuery to achieve an awful lot of what we have all been talking about - if you read the post in full you will see that I have already said that (and again in the comments). My objection is that JavaScript is about user interaction behaviour and should not be relied upon for layout or other visual functions. That’s the job of CSS. The broadness of my criticism of CSS/HTML/JS is total - where I see problems I will talk about them. The problems I have talked about here are not fixed by any of the CSS3 specification and that is why I am raising them.
As for display:table, I wrote a post about that some time ago - you’ll find a full criticism of why it is harmful and should not be used for page-layout at http://mattwilcox.net/archive/entry/id/1030/
Thinking about it, perhaps it's down to a misunderstanding of the purpose of CSS:
HTML is inherently designed to be structured. CSS isn't designed to let you change the structure, just change the layout. It's not the "separating of content and design" as some people make out (but not the standard), but rather "the separation structure and layout".
When you see things from that point of view, the design of CSS makes perfect sense and many of your criticisms don't. It also means that using JavaScript may not be evil, since you want to change the structure and not the layout - you're using the wrong tool!
Part of me agrees, and part of me doesnt.
I agree that the toolset could be upgraded to provide some better options for some tasks that seem trivial, but I disagree that CSS & HTML arent the right tools. I believe they are the right tools, and need to be supplemented. The same thing can and is said about Photoshop - its become a much more print-capable tool this version with introduction of better vectors and on-the-fly page rotation - essentials in proper print product layout.
It doesnt help that nothing but Opera follows strict standards as well.
Just a note: As for missing DOM hooks, more powerful pseudo-elements would take care of a lot of this problem. Generating extra "elements" would be simple, and generating more complex trees at least possible.
I am glad to know that I am not alone in finding it somehow wrong to use JS to position an element relative to another that is not the parent. What has this to do with User Behaviour?
Thanks for this post!
I like using tables for layout. It simply works. HTML is not semantic, XML is. I structure my xsl to generate multiple layout skins referencing css for styling. My javascript is unobtrusive and kept to a bare minimum. My pages look good and work even when CDs and javascript are disabled. The transformation of XML semantic content into presentation whether that be HTML or PDF or svg are all quite simple when you add DSL to the stack. Add xquery and you have a complete stack. My only code is logic to map HTML form elements to XML nodes with xpath (because xforms isn't good enough). My pages load blazingly fast. I go for what's fast and simple over the dogma over pure seperation of concerns: content, layout and behavior. That's my opinion.
Typed the above comment using my new iPhone in Safari. Needless to say, iPhone's auto-correction logic isn't working out for me quite yet.
"CDs" should be "CSS" and "DSL" should be "XSL".
Structure is king in my world, which is why XSL is so powerful. I move the bits about on the server before I transmit the content to the browser. That way I don't have to fix it with Javascript or complicated CSS positioning logic. It just works.
Regarding the ability to make blocks the same height / width or what have you, Internet Explorer has supported this since 5.0 (http://msdn.microsoft.com/en-us/library/ms537634.aspx) and it is really not a difficult thing to do. Ironically, they have removed it from IE8 :S
Sometimes it takes a browser maker to just do what they think is right rather than wait for the glacially paced W3C.
Hi Matt,
Can you clarify what your critics about Advanced Layout are ? To me, it seems to solve both the semantic issue and the independence to markup problem. I don't really understand. You say it is not flexible enough. What does it mean ? If not the panacea, isn't is a giant leap forward ?
Thanks!
My biggest concern isn’t so much which language the styling will be made in but more fundamentally how will the styling be displayed based on current and future security settings of the user.
Let me explain; there is a lot of movement towards overcoming CSS styling with the use of JavaScript but with security increasing (NoScript for FireFox being one of the most downloaded add-ons ever) means that many people are already see these degraded JS styled pages and those numbers will increase. Degraded is often a joke because I use NoScript and come across many sites I can’t get past the homepage because it’s all JS driven without the degrading.
All the bosses and clients I have ever worked for have not understood that a webpage isn’t a magazine static page so won’t look the same in all browsers. You make the page and sometimes you have to degrade it but then your boss starts showing off his new site to his friends but one has JS blocked and sees the degraded version. The boss then blames us saying the site is “broken” because he now thinks no-one on the planet can see the fluffy stuff he paid for.
The great thing about tables and CSS is that neither can be blocked by the user because they have no need to; there are no security risks. I am deeply, deeply concerned about putting the styling and control of pages into languages that are routinely blocked by users. Whatever way forward this route takes us the styling and control should be in a format that is not routinely blocked. CSS to me seems the obvious choice but I’m happy to go any route that gives me the ability to show the same content to the maximum amount of people without worrying about blocking scripts.
Enjoyed the read about some potent points of the standardisation of the interweb, however would love to see a real life example where you can make CSS in @ mode truncate results not within scope? Understand the grimes that you all have, however positive that your constructional comments can express future answers?
Just stumbled onto this article - absolutely fantastic, and I couldn't agree more with you about CSS being a tool for a job which has changed and evolved, and it not being 'meant' for anything.
It's frustrating to see the way in which maths and logical arguments for CSS are shot down because of percieved possible complexity, etc.
If CSS should be controlling presentation, then it needs to do so without the need to manipulate the architecture, and javascript shouldn't have to rely on injecting markup in order to achieve presentational effects.
Hear hear.
Now I'm going to really throw a wrench into the discussion. I'm not sure that "content/behavior/style" should be separated at all.
As an end user, as well as an intermediate designer, separating these elements just isn't practical in many cases.
For example, when using MS-Word I almost NEVER use styles, etc. - I just bold, underline, and indent my text on-the-fly. It gets the job done FAST, and the result is every bit as good as spending hours figuring out and applying pre-determined styles.
Matt says: This is a very old argument, and one that I’m not going to go into here. It’s my belief, and the belief of many, that they ought to be separated; separation gives more flexibility, better quality results, and is often faster - when properly planned and implemented. The benefits of doing so far outweigh the idea of ‘just bunging it in as you go’. For more on the topic you could try Zeldmans seminal “Designing with Web Standards” http://www.zeldman.com/dwws/ or, if you prefer to read online, the Opera Web Standards Curriculum covers the ideology and practical benefits too: http://dev.opera.com/articles/view/1-introduction-to-the-web-standards-cur/
As more people (including end users) use Wordpress as their primary website building platform they will demand dramatically better tools.
These people will expect (rightly so) to easily modify their own sites without a 2 year degree in "CSS". That is definitely not the case today.
Matt says: It should never be the case. CSS is not intended for the layman, nor should it be. This isn’t about allowing anyone to be able to edit presentation - you’ll just end up with MySpace and bleeding eyes. CSS is a much more low-level technology, and it is up to clever designers and developers to build higher-level systems with which an average consumer can control styles, as set by the designer. CSS is not for content consumers. It’s for designers. The “anyone should be able to do it” idea of CSS is precisely what has held it back from being anything like as useful, powerful, and flexible as it ought to be.
I've read this article and your prior article, Why CSS needs to borrow from programming languages, with much interest.
I have put together a proposal and sample Chrome implementation of a CSS layout extension described at http://blogs.eforceglobal.com/dkarisch/archive/2009/07/16/536.aspx.
I think it meets or even exceeds the requirements that you and the responders to this post are demanding. Please take a moment to review and comment.
CSS has evolved, did anyone really think it wouldn't?
Thanks for one of the best written articles I've encountered on this subject.
Keep fighting the good fight!
@Simon Day: An excellent point , sir… and one which deserves more discussion!
check out more CSS3 tutorial on www.webmasterclip.com
Huh. Nice
The biggest problem is that once again there is browser compatibility problem…almost got rid of IE6…and now with HTML5/CSS3 we are back where we started with half the people needing a separate the website just to make things look ok…at least with modern browsers most people will be updated sooner or later
Great information you got here. I’ve been reading about this topic for one week now for my papers in school and thank God I found it here in your blog. I had a great time reading this .
to me the biggest problem with CSS3 is that it doesn't go far enough. It's more of CSS2.5 than a real 3.0 release
Part of me agrees, and fragment of me doesnt.
I agree that the toolset could be upgraded to provide some better possibility for some assignment that seem trivial, but I disagree that CSS & HTML arent the benefit tools. I believe they are the right tools, and obligation to be supplemented. The same thing can and is said closely Photoshop - its become a much more print-capable willingness this rendition with preface of better vectors and on-the-fly page rotation - fundamentals in proper print output layout.
I’ve been understanding regarding this subject for one week at the moment for my identification in school and show gratitude God I originate it at this point in your blog.
I’ve been education roughly this themes for one week now for my papers in seminary and thank God I found it here in your blog. I had a great time reading this .
Regardless what everyone one says, I believe CSS3 still has too many limitations.
I got so sick of the lack of variables in css that I put up with using LESS. And grid css frameworks? They look too much like tables half the time to me for me to want to use them (that's just me though).
I think css is a little inconsistent with text styling, but is a good solution for that.
If WHATWG wants to keep css simple, then maybe they should propose making it a simple tool to do a simple task: styling text only. If they feel css having advanced layout control would make it too complex, then maybe we just need a whole new language to lay out pages. We can split presentation out into styles and layout, giving us 4 layers. It wouldn't change my workflow, I already keep all my styling LESS code in separate files from my layout LESS code. Though it doesn't really matter since they probably wouldn't listen to that craziness.
When CSS was released, using it for the layout of an entire page was barely even a concept, and it certainly wasn’t possible.
If only XPath and XSLT could apply to HTML we would be able to select all kinds of crazy things or even transform the whole document to fit our needs.
Now I think of it, both could apply to XHTML, sadly that standard has been killed by content producers because it never was properly implemented. By which I mean, sending it as text/html and pretending all is well even though browser handle it as normal tagsoup.
I got so sick of the lack of variables in css that I put up with using LESS. And grid css frameworks? They look too much like tables half the time to me for me to want to use them (that's just me though).
I think css is a little inconsistent with text styling, but is a good solution for that.
If WHATWG wants to keep css simple, then maybe they should propose making it a simple tool to do a simple task: styling text only. If they feel css having advanced layout control would make it too complex, then maybe we just need a whole new language to lay out pages. We can split presentation out into styles and layout, giving us 4 layers. It wouldn't change my workflow, I already keep all my styling LESS code in separate files from my layout LESS code. Though it doesn't really matter since they probably wouldn't listen to that craziness.