Response to Matt Wilcox

This is a response to Matt Wilcox’s article The fundamental problems with CSS3:

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 is usually the best option 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.

What else is there to the HTML content other than semantic information? Structure. Some structure may actually convey semantic information, but much of it does not. It is only useful at a meta-layer.

For instance, when reading a novel it is not very beneficial to my understanding of the story to know that the particular paragraph I’m reading is a child of a particular chapter, which itself is a child of the particular book. When I want to discuss the novel with others, or find my place again after setting it down, then it may become important, but in these cases, I’ve already left the context of the narrative. Knowing what chapter I’m on is less semantic information than, for instance, the fact that a particular word is italicized.

In other words, the style of a document may actually convey more semantics to the reader than the structure does, which is another problem with your formulation. The semantics of a document can be a nebulous thing. For a web application reading your HTML, the semantics may solely reside in the HTML content. To a human, however, the styles and layout you apply to your content may convey very important semantic information.

With that all said, we can reexamine some of your criticisms, which still may be valid, but which I believe may call for different remedies.

First of all, I find the notion that CSS should be able to manipulate the DOM to be prima facie dangerous and unwanted. If HTML is to be responsible for the structure of a document, then CSS should not be impinging upon that structure, and neither should your CSS make undue assumptions about what the structure of a document will be. By allowing for full document traversal, this is exactly the Pandora’s box you will open. CSS will be written to be intimately coupled with the particular HTML documents to which it is applied.

Of course there are already cases where this happens. For instance, if I use overly specific CSS selectors to identify a particular Nth td of a table; as soon as the information changes to no longer be in a table, I have to update my CSS. I believe most of these situations can be avoided by a careful review of one’s CSS selectors. When writing a selector, I should ask myself “is the relationship between elements important to what I’m trying to accomplish?” or, put another way, “is the relationship of the elements part of the semantic information to which I want to apply this style?” If the answer is no, then my selector should not be written to depend on the relationship of the elements in question. If it’s not important to my style that an element is a child of a paragraph, then I should have a ‘p’ in my selector.

JavaScript of course can already traverse and alter the DOM, but in my opinion, scripts would ideally only alter document structure when the behavior expressed by the script legitimately requires an alteration to the document (e.g. the semantic information to convey has changed as a result of behavior). For instance if your script is adding a floating div in order to create an AJAX notification that pops up above the rest of the document, then your floating div should have been in the document in the first place (where custom CSS could move it so that it doesn’t try to float over the document, for accessibility or device limitations). Then the script should just add the new notification to the existing div. Then it is not needlessly altering existing document structure, but rather only inserting new content associated with the notification itself.

In the examples you give, I see no reason that DOM traversal or manipulation is necessary to achieve the effects you want. If CSS provided a grid mechanism (which is one of your examples) that also included dynamic information such as if/how individual elements in the grid resize when the grid is resized (I’m thinking of something like GridBagLayout from Java), then your tab issue would go away without the CSS itself having to descend into the DOM and/or change it. To me, such a grid system is a property of the layout, not of the document content, and so it is very reasonable to provide CSS with a mechanism for defining the grid, so that one doesn’t need to create HTML structure for a grid. I believe CSS3 has something like this, but to be honest I have no idea if it’s as extensible as either of us would want.

As for setting CSS properties of one element to match those of another regardless of where the other one is in the document, I can see the usefulness of this, but I can also see this being extremely complex to implement, based on how browsers compute the layout of elements. What if you want an image at the top of your layout to have the same height as an image at the bottom of your layout? What should the browser do when it hits your top image and needs to lay it out so it can determine the height of other elements within the same container? What if it cannot determine the height of the bottom image until it has computed the layout properties of the document proceeding it? I imagine there are all kinds of edge-cases to consider, and a page designer may find him- or herself needing to understand a lot more about browser document flow implementation than necessary (and of course, every browser will have its own flukes). What sounds great in concept may actually be a daunting implementation task. Such a task may seem simple when implementing it in JavaScript because the script runs after everything’s been placed on screen, and now you have an easier time of directly modifying one element’s properties to match those of another. Just because it seems easy post-rendering does not imply that it is easy pre-rendering. The rendering engine does not have the luxury of an already sized, and positioned element with which to work- because its job is to do that sizing and positioning.

But let’s say it’s possible. Would this require your CSS to traverse the DOM in order to specify which other element you want your property based upon? I say it would not… all you need is the ability to provide a CSS selector to identify the related element. E.g. “#footer { use-height: #header; }” or “#notificationArea { position: relative; relative-to: #shoppingCart; }”. If CSS selectors are not expressive enough for you identify the related element, then chances are the logic you want to use is too complex for a rendering engine to implement anyway.

For similar reasons, I see no reason to support variables in CSS. CSS is not a script that is executed, so where would you have the program flow that would be necessary to support variables? Now constants, on the other hand, I would be happy to see, so I can consolidate certain property values (such as colors for a color scheme) in one line without having to write tons of duplicate selectors.

You seem to be arguing that the only remedy for plugging holes in CSS is to make CSS turing-complete so that you can do anything you want with it. Then, it would be the designer’s job to plug the holes. Until CSS is turing-complete, there will no doubt always be complex layouts or styles that cannot be applied with whatever the current version of CSS is. The alternative to support those would be to expand CSS syntax to allow for those particular cases, and this seems to be your major objection- that new modules shouldn’t be used to plug these holes.

However, if we’re just going to throw up our hands and say “we’ll never come up with a declarative version of CSS that can handle every design under the sun” then we might as well just ditch CSS and use JavaScript entirely to set the presentation. Hell, let the rendering engine render the HTML off-screen, and then run special JavaScript to style it before display.

This certainly is not what I want, because it would make 90% of my presentation design tasks much more complex. I would rather plug the holes in the present CSS spec with scripting and/or superfluous HTML while waiting for an update to CSS than to ditch CSS as we know it today.

That all being said, I am disappointed with the way that the W3 has drifted from the original web development model where browsers would introduce new features in a competitive market and the standards would coalesce over those features that had valid use cases plus established prototypical implementations. The current standardization method has not solved the problem of browser incompatibility, but seems to have significantly slowed the pace of standards development.

Advertisements
This entry was posted in Web Design and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s