this space intentionally left blank

April 14, 2009

Filed under: tech»web

All Relative

I have a solution for all the things that drive me crazy about HTML. At least, I think it's a decent solution. The bad news is that there's no chance whatsoever that anything like it would be implemented.

To restate the problem: HTML is a bad way of building an interface. Even discounting incompatibilities and rendering differences between browsers--and even well-behaved browsers can render differently--it's incredibly inefficient. I had another horror-show experience with it while working on another budget package for Normally, at the bottom of that page, there's a footer with CQ's information. Unfortunately, for simplicity's sake, I positioned the central content pane using "position: absolute," which is apparently a big mistake. It made the footer float up underneath the navigation menu and behind the content.

There is, no doubt, a solution for this, probably involving some combination of float, clear, and JavaScript. But it's missing the point. The fact that a footer even needs a clever solution--that there is, in fact, a 'sticky footer that just works'--is insane. Apparently they plan to solve this problem in HTML version 5 with new tags for headers and footers, which is well-intentioned but strikes me as bolting new and horrible combinations onto an already terrifying tag soup.

As is, I'm inclined to rely on either tables or Javascript for placing elements on the page. The former is crufty, and the latter is practically unmaintainable, but they do have the example of allowing me to lay out a page spatially in relation to its component elements. Javascript is particularly tempting, in fact: using tools like JQuery, I can easily find the various parts of a page and then reposition them in relation to each other. Sure, it'll probably break when the page resizes, on small screen sizes, and when confronted with non-dynamic HTML--but it's so much easier to move elements around that I almost don't care.

What we really need is a new model, one that combines the flexibility of CSS-based layout with the relational/visual model of tables and dynamic layout. Basically, when I'm putting a page together, I don't want to think about it in terms of elements floating around. I want to be able to say that this is 3em to the right of that (which is 1em below the other), containing a column of these. I want to be able to say that the footer is simply always below my content, instead of tricking the browser into setting that up for me. I want to be able to line elements up with other elements, or simply say that one should be next to another. Something like:

#container {
max-width: 50em;
margin: auto;

#header {
top: 2em;

#content {
position: relational(#header) below;
top: 1em;
left: 0em;

#sidebar {
position: relational(#content) right;
top: 0em;
left: 3em;

#footer {
position: relational(#content) below;
top: 3em;

There's even a model that I think we could use for this: Swing. For all the criticism heaped on Java's APIs (deservingly so, in many cases), Swing makes a lot of sense to me for building simple, reflowable layouts. My understanding is that XUL and XAML also implement similar container/layout strategies, which is also fine by me: anything's better than what we've got now, right?

I don't have a problem with new tags for semantic purposes. Being able to specify that something is an aside/nav/article element makes a lot of sense from an accessibility perspective, and that's important. But a single-minded focus on semantics at the expense of design and thin-client programming ignores a great deal of where the web has been going--and it imposes a top-down model on accessibility efforts that probably won't be able to keep up with innovation. I can't help think that we'd be better off with a global accessibility attribute that can be extended easily, while paying more attention to the glaring deficiencies in HTML as a presentation language.

Future - Present - Past