Pinderkent

Guido van Rossum, of Python fame, recently twittered about how using CSS instead of tables for Web page layout just isn't worth it. This was submitted to Reddit, and the discussion it generated there is somewhat predictable. Many of the comments get into the typical arguments surrounding the topics of HTML tables versus CSS for layout, and the necessity of separating content from presentation. But I think most of the comments that are currently there miss some key issues.

First of all, a number of the posters point out that once you learn the many quirks and incompatibilities of the various popular Web browsers, CSS-based layout becomes quite natural. To a great extent, this is true. There are many Web designers out there who can make very good looking sites using CSS. Unfortunately, it takes literally years of effort, learning, experimentation and failure to get to this point. And with browser technology continually evolving, it takes further effort just to keep pace.

Now, some people will argue that any inherently complex task will take much time and effort to master, and they're correct. But in this case, CSS-based layout shouldn't be such a task. Reality, however, shows that it is, mainly due to artificial difficulties created by low-quality, inconsistent and obsolete-yet-widely-used Web browsers.

Another thing to consider is that not everybody wants to make complex Web layouts. Many people who aren't Web designers want to quickly throw together a site that has a relatively simple layout, and looks decent. On one hand, they can battle with the many troubles that CSS brings to inexperienced users. On the other, they can just use HTML tables, which for many simple layout tasks end up being much more practical and efficient to work with.

CSS should be able to cater to people in both camps, namely those professionals who want to develop complex pages with a high degree of control, and those who just want to throw together a page quickly and easily. Unfortunately, it fails both groups of people a lot of the time. The trend seems to be that most professional designers struggle with it until they finally learn how to wrangle it, most of the time. By that point they've invested so much time and effort that the only way they can obtain some degree of payback is to employ their hard-earned "knowledge", which itself is more an understanding of numerous broken and poorly-implemented Web browsers than anything else. And those people who deem their time better spent on other tasks, like Guido, apparently, just resort to HTML tables.

The fact that the CSS versus HTML tables debate has raged for so long should suggest that CSS is a dead end. It doesn't do a sufficient job in fixing the huge variety of problems associated with what should otherwise be a straightforward task. Perhaps Internet Explorer 8's better support for the CSS table model will help improve the situation. Then again, it may just make things worse. Perhaps the only solution is to throw out the sub par technologies that we employ now, and find a better way to solve the problems of Webpage layout.

Lately, there has been a trend towards using the Web browser as a general application development platform. This is unfortunate in many ways, namely due to the poor nature of the browser for such a purpose. A system inherently designed for displaying documents and allowing for navigation between them has been perverted into something more. Unfortunately, it's not even a remotely decent platform. All of the efforts so far have basically been very poor reimplementations of what we've already had for years.

In terms of programmability, we're basically limited to using JavaScript. While JavaScript may be usable for minor scripting tasks, it is not the sort of programming language that should be used for developing more complex software. I've written before about some of the problems with JavaScript, as have many others. Needless to say, it's not good to be isolated just to JavaScript for browser-based Web applications, as we currently are. Compared to more traditional software development, we're handicapped significantly by the current situation.

When it comes to actually displaying stuff to the user, we've experienced nothing but problems. We're essentially limited to using CSS, along with JavaScript. Anyone who has had to write even a moderately complex cross-browser stylesheet knows that it's nothing but a huge hassle. And even today, there's still much disagreement about whether CSS is even acceptable for layout. I summarized some of the CSS versus HTML tables arguments the last time that debate flared up. Regardless of one's stance, I think it has to be agreed that the mere act of rendering text, images and other information to the screen is much more of a problem for Web applications than it probably should be. Even then, it doesn't offer the flexibility we can get from traditional software development platforms and techniques.

While it's been noticed that there are significant problems in these core areas, the remedies are less than suitable. A good example of this is the canvas element that has been implemented by several browsers. It essentially provides a drawing surface, much akin to what we've had available on so many other platforms for decades now. But unlike these non-Web-based platforms, the canvas element is primitive. A developer using the canvas element is typically forced into writing a lot of code that would already be provided as part of the more mature platforms.

We've seen an even further step backwards recently with respect to the HTML5 Web Storage specification. So not only will we have a crippled programming environment in terms of JavaScript, and a poor rendering environment in terms of HTML, CSS and the canvas element, but now we may also have a half-baked implementation of a relational database, as well as the interface to access it, available for abuse.

There's been a lot of disagreement lately about this browser-based storage. And I'm not talking about healthy disagreement such as whether it's a bad idea or not. Most of the disagreement is with the nature of the data store itself. That draft specification suggests a very SQL-oriented approach. Others suggest that a JSON-based approach would be better. Some suggest an approach akin to CouchDB, with this already being experimented with.

Based on the current draft of that spec, I think we're looking towards a world of pain. It essentially outlines a very poor reimplementation of what we've had for years in technologies like JDBC, ADO.NET and Perl's DBI module. It's looking much like a case of us getting a small fraction of what we can already do, without any real benefits, improvements or innovation.

It makes little sense to try to build a platform for the future in the Web browser. All we've managed to do so far is reproduce a lousy, stripped-down version of the existing platforms that we've had for decades. But what makes it worse is the monoculture that has developed. We're stuck using JavaScript for programmability. Any form of display must essentially be done using HTML, CSS and the canvas element. Data storage may be done in a form similar to that of the proposed HTML5 Web Storage spec, but even if different it will still likely be very lacking. And given that the platform is provided by the Web browser, it's not like we can really go back and correct all of these deficiencies at the core with ease. We instead have to try to reproduce what we've had for years outside of the browser using JavaScript, which so far has been an absolute failure. We can't make any real forward progress if we're going to be continually trying to bring ourselves up to the level we were at back in the 1990s.

Douglas Crockford's recent article suggesting the creation of a project to develop a so-called "HTML 4.2" specification makes some very good points. He is quite correct when he points out that when developing standards, "It is easy to pile features on top of features, but that ultimately produces systems that are far too complex, insecure, and unreliable." This is indeed what we have seen with HTML 5, and what we have also seen with the ES4 efforts.

It's quite good to see somebody who is so well-known and respected within the Web development community pointing out such harsh truths. But I suspect what the Web needs is more than just more sensible standards. The entire platform as a whole is badly in need of a "reset".

The Web is truly starting to show its age. After all, it has been around for nearly 20 years now. It's remarkable how well it has handled the growth and change it has experienced. But after nearly two decades, it likely is time for some serious changes.

Web browsers themselves are one area where a "reset" is needed the most. A few days back, Ian McKellar made some pointed observations about the state of the Mozilla platform. Namely, he pointed out how the current codebase is extremely complex, lacks even remotely acceptable documentation, and isn't as appealing to developers as WebKit is.

The need for browsers today to maintain so much backwards compatibility no doubt has a significant cost in terms of browser implementation complexity. Even at a very basic level, there are numerous standards of HTTP, HTML, CSS, and JavaScript that need to be supported in order to provide just an adequate browsing experience. Add into this mix the need to accept blatantly incorrect HTML markup and JavaScript code, and it's not a recipe for software that's easy to implement and test.

At some point, it will become beneficial to all to stop trying to build upon so many years of cruft, experimentation and legacy. Instead of focusing so much energy on extending what already exists, the core concepts and functionality of what makes up the Web could be consolidated and a more reasonable platform developed. In essence, the entire Web platform needs a "reset" at all levels. Trimmed-down versions of tomorrow's standards only serve to procrastinate with respect to the effort that will eventually be needed to clean this mess up.

I read through an article today that shows the struggles Web developers go through to perform basic layouts using CSS. In the article's particular example, it's simply some images and some associated textual content displayed in a grid-like manner, with the amount of text being variable.

In short, it's a practical, real-world data display that should, one would think, be very easily accomplished using CSS. As is often the case when using semantic markup and CSS, what should take only a few minutes balloons out into a battle against unexpected behavior, browser incompatibilities, browser bugs, and so on.

Whatever benefits CSS might have brought are quickly eliminated by the time and effort necessary to get the content displaying even remotely correctly. But we must also consider that the end result becomes nearly unmaintainable. Other Web developers working with the code later on will likely not appreciate or understand the struggles that went into getting everything working in the first place. Making even minor changes might not be possible, or might be extremely time consuming, with much care needed to avoid rendering incorrectly in various browsers.

I'm not suggesting that HTML tables would necessarily be a better solution. I just find it extremely bothersome that such a simple task so quickly becomes such a huge hassle when using CSS, with the end result being quite fragile. This is what we'd expect to see from an immature technology, yet CSS has been in the works for roughly 15 years, and has been implemented by a number of different groups. It's pretty pathetic, really.