Joshua Napoli

I just finished the implementation of a new design for my wife’s web page. She’s an artist, so the layout took a lot of customization. It needed to be vertically centered, a surprisingly difficult detail to get working. And I’ve added a customized back-end so that she can edit the pages herself. Web work always drives me insane. It is so frustrating that the layout can be achieved in Photoshop or Word in a tiny fraction of the time it takes to get it working on a web page (unless we just make everything one big PNG file).

There is nothing wrong with HTML itself. Meaning is built from characters with a temporal ordering and cross-references. Unlike Postscript, the meaning is static; the cost of interpreting a document is easily predicted from its size. Unlike file-systems or Gopher, the cross-references mixed with the content in HTML draw context with an arbitrarily large universe. HTML is just enough to get to a some basic leverage for a person or software system to begin integrating abstract ideas beyond the individual contributions of a particular page. XHTML is (supposed to be) composable. XSLT lets you filter and recombine documents any-which way. There may be some problem in practice. While everyone implemented XSLT, XINCLUDE was only implemented on IE. This makes it was hard to actually reference the second URI from the first XML page. But if you could figure out how to reference a second page, it could be combined any-which-way. It is hard for me to understand why anyone wasted their time implementing XSLT without XINCLUDE in a browser.

The frustration arises when it comes time to map a document onto a two-dimensional screen for a person to read. CSS is supposed to define this mapping, but the expressiveness of CSS is sorely lacking. CSS has a couple of fundamental problems. First, it is not orthogonal to the semantic structure of the page. The “containing”, “before” and “after” relationships in the HTML document should be reserved for encoding the meaning of the text. CSS conscripts these relationships into layout duty. CSS cannot create a layout graph that is different from the HTML logical graph. Layout boxes A and B can only be positioned and sized relative to each other if HTML elements A and B are related by adjacency or containment. There are plenty of applications for independent layout and logical graphs. A simple example is to create newspaper-type columns (when defining the printed media style for a page). A more complicated example is defining rules for tying inline illustrations to the corresponding text. Ideally, the client would be responsible for filling web page templates. There might be little resemblance between a screen layout structure and an XML report from a database query. Ideally we would have the ability to arbitrarily map HTML sections into an independently defined hierarchy of layout “boxes” on the screen.

The second fundamental problem is that CSS is that it is highly asymmetric. Rather than building from a concise set of box position and flow principles, it is really just a hodgepodge collection of effects. Many capabilities that would seem to be spanned by its feature-set are actually impossible. CSS can format the first and second characters of the content of an element differently, but the second and third are always the same. It can prefix or postfix stuff onto an element, but cannot add anything in the middle. Boxes are positioned and sized relative to their containing and preceding boxes, except for a “float” which affects other boxes based on screen-position, rather than document structure. Since CSS does not provide a granular basis of fundamental principles from which to build the more complicated layout effects, it turns out to be nearly impossible to do things that were overlooked by the writers of the original specification. For example, it is impossible to vertically center some content using only CSS 2.1. The relationship between the formatted content and the window in which it is rendered, (a seemingly crucial aspect of any layout) is almost completely uncontrollable through CSS (at least in the vertical direction…).

CSS 3 appears to be on a course to reinforce the design flaws of its predecessors. Its development seems to be guided by the perspective of the naive web designer that complains that old-style html tables seem to be more expressive for specifying page layouts than CSS. It adds back some ability to chop the viewport into boxes containing different segments of content, but doesn’t offer any new means to define a layout structure fundamentally different from the semantic structure of the document.

Evidently Flash, Silverlight and Javascript formatting engines can expect bright futures. Luckily we’re starting to get some design leverage outside of Flash and Silverlight. Safari already generates the continuous stream of events that allows a size-sensitive layout generator to smoothly update as the browser window is resized. Safari and Opera now support embedded fonts through the “@font-face” CSS rule. Firefox seems to be the laggard in this area, supporting embedded fonts only through SVG.