Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

The Way Forward

June 13, 2003

Questioning the W3C’s intentions, and coming up pleasantly surprised.

Come and theorize with me for a moment.

You’ve no doubt seen Owen Briggs’ Design Rant. Keeping in mind that it was written in 2001, the concepts are more relevant today than ever.

The World Wide Web Consortium, he says, is taking the long view. Rather than duplicate past experiences like NASA’s Viking mission, the data for which is no longer readable by machines, the W3C is planning for the future now. Each new spec coming out is considered in a historical context, as new features added extend existing capabilities, instead of replacing them. An evolving language, each baby step along the way has to set the stage for the giant leaps to come in future revisions. So as not to break stuff.

So what’s up with XHTML 2.0? No more <img> tag? That little doozy alone wipes out almost every single page on the existing internet. XHTML–based browsers can “process new markup languages without being updated”, oh sure, but that doesn’t really do much for existing sites, now does it? It strikes me that in their quest for semantic purity, they’re casting off the primary goal of future compatibility.

But then… then the sound of a flick of a switch as the light turns on.

They’re doing this once so that it never has to be done again. The goal of XHTML is to transition people from HTML, a non–extensible (and if you’d like to argue this, I present the case of IE4 vs. NN4) subset of SGML to the prior–mentioned XML which, again, can “process new markup languages without being updated.”

HTML will die. Today’s internet is obsolete, and anyone still coding in HTML 4 is planning the obsolescence of their own code. The big picture says that if, and this is a big if, but if we can move to an XML–based internet, then revisions to markup languages, existing and new, don’t require browser updates. Once we have user agents that fully support an eXtensible Markup Language, and the style sheets used to format it, then it doesn’t matter anymore if we lose the <cite> tag, or if <img> gets dropped. We create our own damn subsets that include them, and everyone else can use our subsets without downloading a new agent! Wouldn’t that have been convenient 5 years ago…

I’m late to the game. Or early, depending on where you’re coming from. This is a big thing, and it’s taken me a while to see it for what it is. If you approach recent announcements from the Consortium keeping this in mind, it all begins to mesh.

However. It’s an ideal, and years and years down the road. Coding for today’s web means you can’t afford not to create sites that will be obsolete when the dream takes off. Browser and developer support for even the next transitional technologies like XHTML and the absolutely critical CSS is not nearly enough to start coding these future–friendly sites today.

As we’ve moved from presentational HTML to semantic XHTML separated from style, some have come along for the ride but most haven’t. The next few phases are going to be even more difficult to get to, since at least today’s transition is still very backwards–compatible. The big leap is going to be far tougher, since killing HTML for good simply cannot happen in today’s climate, or tomorrow’s, or any time in the next 5 or 10 years.

Will it ever happen? Hopefully. I’m excited about the prospect. I realize this is something to look forward to, and not something to even think about using in the near future. But they’ve giving us our training wheels in XHTML, and that’s a good start.

Reader Comments

Gary Campbell says:
June 13, 01h

I think that some of the biggest challenges of today that’s not being addressed is that art directors at ad agencies (and their clients) are still driving the creative process and designing huge numbers of corporate web sites… and these individuals are often not well-versed (or even speak the language) of web standards. Further these sites are then often created by a designer who is more versed in Quark XPress or InDesign than HTML and therefore muddles together a site in Dreamweaver or GoLive. However, there is light at the end of the tunnel when, in the future:

–When the advertising community becomes more fluent in the need for web standards
–When they are provided tools that automatically create ONLY standards-compliant web sites rather than WSIWYG editors that are very”loose” in their code (to put it mildly)
–When this generation grows old, retires, and is replaced by a younger, more web-savvy group of designers

Thanks for the column. It was a thought-provoking read.

Keith says:
June 13, 02h

Dave - Great post. Very good points.

Another point about HTML > XHTML > XML.

XHTML IS XML. So, just by taking that one (fairly easy) step you make a huge jump in the right direction. You might have implied that, but hey, I’ll reiterate.

Tom - I hear you and feel your pain, although I will say, having been working on mainly table-less layouts of late, I find IE rather easy to code for once you learn the quirks. It does get easier as you keep working at it. Although I still have problems with setting height, can we get that fixed at some point? ;)

I cannot stress enough all of the added benefits of ditching old coding habits and moving forward with clean semantic XHTML styled with CSS. Even with the buggy browser implementation and occasional compromises that have to happen. It’ll make life easier.

Tom says:
June 13, 12h

Just stumbled on your site today from a comment left on my site. I’d consider myself an above-average signer with very basic CSS knowledge. I’m slowly moving my entire website over to an entirely CSS-based implementation, but it’s hard to move away from tables and the to-the-pixel layouts that I can achieve with them, yet can’t with CSS thus far. I’m sure most of that is based upon my lack of knowledge as far as CSS goes, but some of it is due to the fact that IE blows.

As long as IE’s CSS support remains limited and buggy (at best), people are going to have to continue to code in normal html with limited CSS if they want 98% percent of the internet population to see what you want them to see. Because “everyone” uses IE, the general computer user sees any errors with it as an error on the web designer’s part, not with IE itself. I too look forward to the day when I can use CSS as it should be used, nix all my tables, and make XHTML code that is both compliant AND functional on an IE browser, but I don’t think that day is coming any time soon.

Dave S. says:
June 13, 12h

Tom — please do check out the Zen Garden. It might surprise you.

Tom says:
June 14, 02h

I have checked out Zen Garden, and it amazes me. It actually was the first thing that I checked out when I got to your page. My problem with css and therefore xhtml though is that there are all these IE quirks all over the place. I don’t use IE myself, I’m a Mac man that uses Safari and Camino, but I have to develope for it and I’m just not familiar enough with CSS and XHTML and their crappy implementation in IE to work around the display problems.

I don’t know if I’m old school or what, but I still find myself sketching out on a piece of paper in class what I want my re-design to look like, more or less, and then I try to turn that into a digital projection of my image. I know that’s not the best way to look at web design, but it is what works for me, and thus far I think it has worked pretty well. I guess I’m hoping for some sort of W3C stamp of approval on web browsers and other web-based programs, and I hope it seems important to the consumer, much like the Dolby logo on any DVD you may buy.

In conclusion, I hate IE and the tables that it has forced me to implement due to the fact that I have 16+ hours of class a week, 20 hours of work, lots of homework, social activities, and little time to figure out EXACTLY why IE blows. Good work on the site though, I love the layout, and love the beach layout of Zen even more.

MikeyC says:
June 14, 04h

In the eternal words of Mark Pilgrim:
“Standards are bullsh!t. XHTML is a crock. The W3C is irrelevant.”

Personally, I don’t think standards are bullsh!t or that the the W3C is irrelevant but XHTML *is* a crock. The timeframe we are talking about before XHTML can really take off enough that dropping HTML support could even be considered places it no earlier than sometime in the next decade. If we are still accessing the web primarily from desktop devices I am sure most would agree that there would be absolutely no reason to drop HTML support as the overhead is completely trivial. If we are increasingly accessing the web from handheld devices, in 10 years time, the overhead is still trivial thanks to Moore’s law or whatever. Where exactly are the real-world benefits of XHTML?

Sure, if the Semantic Web ever takes off then having pages in a machine-readable format would be useful so that you could send your little SearchBot 9000 out on the web to retrieve the best deal on a weekend trip to the moon, but realistically the vast majority of companies are *not* interested in making their content more accessible. They *want* your eyeballs on their home page so that you can be assaulted by pop-up ads. Look at the the whole “deep-linking” issue that’s sparked lawsuits over the last couple of years. Webloggers and Accessibility gurus aside, most companies have no interest in XHTML (in terms of its often cited benefits–easier maintenance aside). Tagsoup suits them just fine, in fact, tagsoup suits them better than XHTML because it helps ensure that humans are viewing their site instead of a bot–which they undoubtedly see as wasted bandwidth.

Having clean HTML 4.01 mark-up with CSS for presentation is the way to go IMHO.

Sander says:
June 14, 06h

Keith: “Although I still have problems with setting height, can we get that fixed at some point? ;)”

What exactly do you mean? Perhaps you already know, but just for educational purposes, you can set the height of div elements by setting the height of body and html to 100% as well.

and tom, making a storyboard of your site by paper and pencil is probably the best way of laying out a site, perhaps if you experiment more with relative settings and resizing your text/browser window you can convert this gained understanding better into your paper sketches.

June 14, 08h

Very nice piece, Dave. The possibilities presented by a full migration to XML are endless, and the notion that designers and developers need not be concerned with browser updates in the future is an exciting one.

The web designer/developer blogsphere is in a state of mourning at the moment. The passing of standalone IE/Win, and the loss of IE/Mac, has effectively frozen us in place for the next few years. But as the fabulous Zen Garden shows us, what can be achieved right now is pretty damn good.

What is needed, therefore, is a concerted effort to lobby Microsoft to provide the world with a browser component that will fully handle XML and CSS3 upon the release of its next operating system. MS seems to like XML. One would hope that this fact bodes well for the future.

Dave S. says:
June 14, 08h

Simon, I’d say Microsoft seems to like their version of XML, given the recent flap about forthcoming Office data formats.

I’m well aware of the current stasis of browsers, and what I think it means, keeping in mind the big picture, is that we’re going to take that much longer to get there. As web developers/designers, we’ve enjoyed a relatively short product cycle to get to today’s rather mature products. Compare and contrast to everyone else working on software today — they get stuck waiting for everyone to upgrade their OS, a far more onerous task than downloading a new browser.

But we’re joining them now. The free ride is over. Development will continue, just at a pace more in tune with the development cycles of the rest of the industry. Everything will still continue forward, of that I have no doubt. But slower.

Keith says:
June 14, 09h

Sander, the solution you are talking about only works across the board in certain situations. The last time I had this issue (and this solution didn’t help that particular problem) I was able to get it to work (using min-height and hacks) in all browsers with the exception of Safari (beta) and IE/Mac (now dead) so you’d think it wouldn’t be that big a deal.

BUT - Safari is my browser of choice so I was motivated there, and a rather large group of the particular audience for this site uses IE/Mac and I imagine will continue to do so for the foreseeable future. After all, they aren’t Web folks and have no clue that MS has abandoned it.

As far as IE/Win goes. If it’s true that MS is going to pull IE into the OS and stop making (pushing) browser updates we are stuck with it. For a long time. I mean forget about the users trying to upgrade their OS. Even if MS puts out a new version of IE with the new version of Windows in 2005, we won’t see many folks using that until well after that.

Many people don’t upgrade their OS until they BUY A NEW COMPUTER. I still have WIN 98 on my PC here at home and when I left Boeing (which at one point had the largest Intranet in the world) in 2001 many groups were still running WIN 95.

I don’t think we can expect the average user to switch browsers as long as IE works well for them, and why would they?

Oh well, like Simon says (bet he gets that all the time) as the Zen Garden shows us, what can be done right now is pretty darn good. It’s just too bad – it could be so much better.

June 14, 11h

Why on earth is HTML support going to vanish? What possible reason is there for removing support for a widely-used standard in a product? You could very slightly decrease the size of the download, but what other advantages would there be?

There are always going to be pages on the Web written in HTML. There are pages now that will never be updated to XHTML, as they’ve been forgotten about. And also there are pages in archives. Support isn’t going away.

The only products that might benefit from only-XHTML browsers are mobile devices with limit memory and processing power, but as far as I can see that’s it.

Dave S. says:
June 14, 11h

Tom - Similarly, why would Mozilla drop MNG/JNG support if the component already exists, and works? Decisions get made for a variety of reasons. No one says HTML is going anywhere, but it’s feasible that in 10 or 15 years from now, the added overhead of supporting legacy HTML pages will be dropped for the sake of a compact, quick rendering engine.

June 14, 12h

I wrote my comment thinking of Mozilla dropping support for that. MNG/JNG support has been hardly used (can you say that of HTML?), I think will still ship as part of the app suite, and I believe there’s a campign trying to get it re-added.

I can’t see the resonably slight overhead of having an SGML parser outweights the benefits of having one - namely, web pages keep working.

Breaking backwards-compatibility with older HTML standards is just as bad as not supporting new ones, really.

Dave S. says:
June 14, 12h

Ack. I thought that would happen. I wasn’t comparing the loss of MNG with HTML in any way, I was more pointing out that these things happen when there are reasons; good or otherwise.

I don’t know Tom, you’re probably right. HTML support may be with us forever, in one capacity or another. But technology does evolve, and when all new sites are written in XML, a myriad of reasons will pop up why someone would want to release a non-legacy browser, most of which I doubt we can anticipate right now.

Basically, future-proofing involves XML. If you write valid HTML 4 today, it won’t be hard to retro-fit your work in 1,2, or 5 years for XHTML Strict 1.0. But the longer the leave it, the more work you’ll have to retro-fit. I’d rather make the leap today, futz around with XHTML, and hope that in a few years time I’ll start seeing the payoff.

June 15, 08h

After developing a site with xml with xslt methods it is apparent that people who code browsers just don’t get it. Will Shakespere said ” The plays the thing”. He was right. I developed AdventCode against Pheonix 0.5 and IE 6 the site was consistant. When I installed the new versions of Mozilla and Firebird I was shocked to find that because the site uses a ‘xsl:for-each’ method the Mozilla people have decidied to introduce a space similar to a ‘br’ into the rendering process without any ability to escape it. This type of programming puts behaviors into the XHTML mix. That folks is just scarry. First we need browser programmers from both camps to understand what their job is.

Sander says:
June 15, 08h

“Tagsoup suits them just fine, in fact, tagsoup suits them better than XHTML because it helps ensure that humans are viewing their site instead of a bot–which they undoubtedly see as wasted bandwidth.”

I’m sure the tagsoup will come in handy when the browsers of pda’s, disabled people or mobile devices try to view the page, which won’t make any sense to them. On a world wide web, setting aside a few percent of the visitors means millions of people that won’t understand your side.

June 17, 07h

I have fixed the issue at Adventcode I was having with XSLT and CSS in Mozilla. Mozilla is making CSS more explicit. A display: block; was used along with removing the br tags from the xslt transform. I have noticed other CSS selectors are now even more explicit. This is a bold stroke in defining content and style and the differences between them.