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.

February 13, 2009

Filed under: tech»web

The Browser Is The New X11

Since I'm not a GMail user, I didn't know about the new button design that Google implemented until I saw a reference to this post by their designer. As an exercise in HTML and CSS trickery, it's pretty impressive. As a look into the sausage-making for serious web application design, it fills me with abject horror.

To summarize: Google apparently wanted a button that would A) use no images for its appearance, and B) allow new kinds of interaction to go with their labeling functionality. In order to do this, they ended up creating a set of custom CSS classes applied to six nested DIV tags, as well as a large chunk of JavaScript, I'm sure. It's very clever, but it also makes me wonder just how far we're pushing HTML beyond where it was meant to go--and how much it's holding us back.

I've been writing HTML code, off and on, for more than ten years now, and I have hated every minute of it. I don't claim to be very good at it, of course, so maybe that's the problem. But it's always struck me as a technology stuck awkwardly between two worlds. On the one hand, a platform- and display-agnostic representation of textual content. On the other, the desire to build attractive, well-designed presentation layouts, including application interfaces. These are not, I think, entirely compatible with each other. Google's new buttons illustrate that tension, as they torturously beat text layout elements into paintbrushes (ones that will display across all the various browser quirks, no less).

There are new options to alleviate that, of course: the Canvas element gives Flash-like drawing tools to JavaScript and HTML developers (once it's more widely available--figure another couple years, at the rate things are going). And toolkits--jQuery UI, GWT, Dojo--have proliferated. But at some point, I think we have to stop, look at this situation, and realize that we're bludgeoning these tools into doing things that they fundamentally were not meant to do. As interface design languages go, HTML is terrible. I have a hard enough time getting a decent text layout to work reliably, much less trying to build interactive custom controls for anything more complicated than a basic form.

The interesting thing about computing trends, though, is that they're cyclical. Displaying information through a clumsy "semantic" thin client/fat server relationship? We've been there, and then most of us ran away to something better as fast as we possibly could. It's only a matter of time, I suspect, before something replaces HTML for doing UI (while maintaining the lessons we've learned about REST and open communication standards), and at that point we will look back in horror, and wonder how we managed for so long.

If you want to see how this is going to go, consider Twitter. All the basic functionality is available from, but almost no-one I know uses that if they can help it. Invariably, you get a better experience from one of the clients (I use Twhirl and TinyTwitter for desktop and mobile, respectively). They're more reponsive, they take advantage of the native platform, and they don't require a browser to be open all day long. The communication with the server is still standard Web 2.0, but Twitter developers have largely abandoned the idea that they need to muck around with HTML, and everyone's better for it.

For the last few years, tech pundits have repeatedly predicted that the browser will take over the space currently occupied by the operating system: via solutions like Google Gears or Prism, or a custom shell like gOS, you'll run everything over the network via HTML/JS/CSS. It's failed to happen so far, and it'll continue to fail. The closer the browser comes to "real" applications, as with GMail, the more its shortcomings become apparent, and the more developers have to rebuild basic functionality in a system that's just not meant to handle it.

If anything, the future is in the middle ground: a heavyweight, native or bytecode platform that can be run in a distributed fashion over the web, splitting application programming back out from the browser and providing a real API for developers to leverage. Such a format addresses the weaknesses of modern binary applications, such as heavy installation and slow startup, without abandoning the advantages that a real operating system provides. AIR, Silverlight, and XUL (as well as Java, to a much lesser extent) are possibilities that could achieve this. HTML, if we're lucky, is not.

May 28, 2008

Filed under: tech»web

Twitter and the New Protest

Like every hip young person online, I've gotten myself a twitter account. My initial impressions are that I don't particularly care for the terminology: followers? Was "watchers" not creepy or sheep-like enough?

Anyway, if you are also on Twitter, I'm open to invitations. Additionally, I'm looking for suggestions of people who are interesting or innovative users of the service. I don't think I'll be broadcasting very much at the moment, but I'm interested in how other people are getting value from it.

To some extent, this is leading up to a low-priority project I'm starting: as anyone who attended college with me knows, I've been fascinated for a long time by what I call "guerrilla rhetoric"--rarely during my undergraduate career could anyone get me to shut up about Otpor, for example. But during the last few years, thanks in part to mobile phones and a much more flexible set of web standards, we've started to see examples of smarter protest and resistance movements using information and communciation technology to coordinate or publicize their work.

I've realized that I don't know as much as I'd like to about these developments, which I find fascinating. So I'm going to start reading up on the subject much more thoroughly, starting with Gene Sharp's work on nonviolent protest. Also, I've set up a linkstream where I'm going to start tagging my online research--there's not much there yet, just the Youtube videos from Anonymous and some stuff I remember from B-SPAN--but if anyone runs into anything, I'd appreciate a heads-up. Eventually this might be a subject that I'd be interested in exploring through grad school (he gazed enviously at Berkeley's doctoral program in Rhetoric), but that's probably a few years off.

April 19, 2007

Filed under: tech»web

Gollum, Gollum

Dotster just sent out an e-mail saying that .es and .cn domains are now available. I'm always tempted, when informed about new domains, to register a bunch just in case. Now I'm trying to think of clever uses of the suffix. I can't think of any for .cn, but .es is a goldmine, assuming they're not already taken (, sadly, has already been reserved).

Or maybe I just really want and its subdomain, (hence the title, my preciousssss).

Future - Present - Past