Web standards

At the time of my last redesign, I noticed something odd going on with Internet Explorer. On one page, several elements seemed to have simply disappeared. A brief rummage through the code revealed that the offending elements had both set widths and negative margins.

Unfortunately for IE visitors, things got very hectic for me not long after, and I didn’t have the time to fix it—using negative margins was an easy way to add a bit more flexibility to the layout without having to use lots of tedious floats and structural markup, so any alteration would involve a fair bit of change to both the HTML and the stylesheet.

Still, the thought percolated away for a while. Eventually, I realised that it must be to do with IE’s incorrect interpretation of the box model (Tantek’s is the clearest explication of the box model and IE’s problems with it out there).

I’ve created a test page demonstrating two problems that Internet Explorer has; there may well be more. Firstly, an element with a negative margin equal or greater in size than its size in that dimension (width or height) will simply disapper. Secondly, if you use a negative margin to take part of an element outside a parent element with a fixed width, that outside part will be guillotined off; it simply won’t show up.

So far this has been tested for me by helpful people with various versions of Firefox, Opera and Safari, all of which display the test correctly, and Internet Explorer for Windows, which does not. Internet Explorer for Mac apparently displays the test correctly, so as we knew already, Tantek and his team did a far better job on IE/Mac than the IE/Windows team has managed to date.

If you’ve noticed this before, written it up as a problem somewhere, or have any data or analysis that might shed any further light on this problem, please post in the comments. I’m sure the work I’ve done here isn’t at all original, but anything that spreads the word and lets people know things they need to avoid if they’re unfortunate enough (like me, and most frontend developers) to have to carry on supporting Internet Explorer.

Here’s that link to that test page again.

Most of the web developers I talk to who are also web standards advocates are very conscientious people. They have a code—a set of best practices—and they try to live by it as best they can.

But being an advocate, not just a user, means speaking out—spreading the gospel. We do this on blogs, in forums, in conversations with other developers and, most importantly, when we’re talking to our clients.

Quite often, I’m sitting in a café, minding my own business, and I overhear a conversation between a web designer and their client. Not intentionally, of course—cafés are always abuzz with business conversations, because they’re a “third space” that’s neither home nor work. People can go there, relax over a coffee, and get to know one another. It’s neutral ground, and it provides an atmosphere conducive to compromise, discussion, getting things done.

Unfortunately, when the discussion is about web design, it’s rare that I don’t get the urge to block up my ears with cotton wool. All too often, so-called web professionals talk in terms of outdated techniques and the worst of bad practices. Layout tables, animated images, music, marquee elements (they call them tags, of course), spacer GIFs… the works.

Hearing these litanies of Dark Ages coding practices drives me a little mad: I get the urge to storm over to their table and tell the clients they shouldn’t be paying for this, that the people they’ve hired are ignorant charlatans, interested only in taking their money—not in doing the best job they can.

I don’t, of course; I sit there, seething silently, trying to look like I’m not listening in. If nothing else, I don’t need the hassle—and I don’t have the time to take on every website job I hear talked about. All I can do is the best job I’m capable of, on the projects I do work on.

Still, it doesn’t stop me feeling irritated when people start talking about layout tables, and I’m sure I’m not the only one.

When I read large chunks of text, I tend to select portions of it—paragraphs, lines—as a reading aid. I don’t imagine I’m alone in this. So why do people, using flat colour images as a background, forget to set a background colour that reflects the image colour?

Two examples—picked because I read them, not because of their prominence or otherwise—are Snook and Binary Bonsai. These are two good-looking sites, designed by people who really know what they’re doing. And yet, when I try to select some text on either of them, this is what I see:

And here’s what I ought to see:

Bear in mind that this was done with one simple style rule; implementing it across the whole site would be more complex, but not very. Jonathan knows what he’s doing—this is just a simple mistake, very easy to make. However, it has a real impact on the site’s usability, making it harder to read even for people who are in no way visually impaired. Over at Binary Bonsai, we find the same story:

How it ought to look:

Reading and writing is what we’re all here to do, and we have to strive to make it easy. There may be plenty of people who don’t read in this fashion, but there are enough people who do to make it worth the five minutes or so it takes to fix the issue. We’re always talking about web standards and accessibility; this is a real example of something important we should all be ensuring we don’t forget.

One thing I wish for in HTML is a de-emphasis element. Maybe it could be called dem. To an extent I fake this effect with code like <span class="fade">, which with my CSS produces a whisper like this, but the semantic content of a span element with a class applied is pretty thin. That class could be anything, and span just selects a certain piece of inline content.

No, what I want is a proper de-emphasis element. After all, we have two levels of emphasis, em and strong, so why not dem?

Actually, this leads me onto a bigger issue that I have with HTML (and XHTML, for that matter): semantically, it’s weak. There just aren’t enough elements to mark up a document well. This, of course, cry the futurists, is where XML comes in: you can create your own, internally consistent markup language, with all the elements you want. But is this realistic? Will most of us actually do it? Of course not. What is needed is a brand of XML that will be strong enough to mark up the majority of documents on the web, so lazy people like me can use it. And, no doubt, one (more likely loads) is being created, or already has been.

This leads me onto my second problem: support. HTML is (mostly) a de facto standard, because most browsers support most elements. But what are the odds that the majority of the browser market will support XML properly at the point where most of us (developers) really start to want to use it for everyday document markup? Slim and none?

Perhaps I’m being overly pessimistic; perhaps I just don’t understand the current state of markup language creation and usage, or the browser market and the way it will change in the next few years as Microsoft get their act together or everyone switches to Firefox. But maybe we’re going to have another decade of frustration. I don’t think, right now, I’d lay odds on the former over the latter.

Design In-Flight’s April 2005 issue came out yesterday, whereupon I paid out $10 for their back catalogue, consisting of all four issues to date (including the latest). With a front cover by Kevin Cornell and articles by Khoi Vinh and Molly Holzschlag, it’s well worth picking up (payment is by PayPal, and they email you a username and password; you can then download the magazine as a PDF).

While we’re on the subject of design, the WaSP’s Acid2 test is out now. Like the original Acid test, it checks whether the browser viewing the page deploys all the relevant CSS properties correctly. As Safari developer Dave Hyatt notes, “every browser fails it spectacularly.” Despite the protestations of standards-compliancy from the top modern browsers, there’s clearly still a fair way to go yet.

The Web Standards Project have put out a press release about Acid2. Their public relations stuff has been smarter since the backlash over the initial flagging of Acid2 as a “public effort to encourage Microsoft to add as much CSS 2 support as possible as its developers embark on IE7″; a spin which brought criticism from some quarters, who noted that no browser complied fully with even the CSS 2.1 specification. This criticism, as we can now see from the WaSP’s press release, was well founded: they state that “Acid2 has already been found to expose flaws in all tested browsers, including Internet Explorer, Firefox, Opera, and Safari.”