HTML is for grown ups

Creating HTML professionally is an odd thing, because many people assume it’s not difficult. This isn’t, perhaps, surprising when most peoples’ oldest relatives could knock out an HTML page with a few minutes of coaching, even without a friendly WYSIWYG editor. Which is, obviously, a splendid and wondrous fact, and one of the things that makes the Web a miraculous place.

But while the lower reaches of HTML’s learning curve are far more forgiving than those of programming languages, the gradient soon picks up when you start to worry about your site looking good, working on different browsers, degrading in older browsers, being readable and usable for people with disabilities, pleasing a client’s or boss’s peculiar fetishes and whims, and producing HTML/CSS that isn’t going to confuse the mug who will have to update it when you’re on holiday or have left the company in frustration at the aforementioned client’s or boss’s fetishes and whims. Very simple or very bad HTML is child’s play. But good HTML for any slightly complex site is a time-consuming job for grown-ups.

I was thinking all this while working on an intranet for a client (whose fetishes and whims feature frames, DHTML menus and scrolling iframe tickers) and wrestling with what appear to be two Internet Explorer (v6.0, Windows) bugs that I present here in an effort to help any frustrated, Googling, grown-up HTMLers who stumble across it.

  • It’s been a while since I worked for a client dumb enough to want frames, so this has felt just like the old days. However, I came across a problem that was entirely new to me. In IE 6, whenever a vertical scrollbar appeared so did a horizontal one. There was nothing in the page wider than the frame and it always allowed the same very small amount of scrolling. The same thing happened in iframes, and even if there was nothing but a long list of (narrow) single words in the page.

    After resorting to the ever faithful Google Groups I discovered, among the people who didn’t believe such a problem existed, the solution: remove the URL from the page’s doctype, eg, from

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

    remove the ‘“http…’ bit. This causes the browser to use Quirks Mode, but why this magically removes the pointless horizontal scrollbar is beyond me. It does, and that’s all I eventually cared about.

    UPDATE: Read the comments below for why this creates a different problem.

  • Let’s say, for the sake of simplicity, you’re styling text in a div using both class and id selectors, like so:

    <div class="colour1" id="size2">Hello</div>

    In your stylesheet you’ll have code like this:

    div.colour1#size1 { color: blue; font-size: 50%; }
    div.colour1#size2 { color: blue; font-size: 300%; }

    One might think this should result in a large, blue “Hello”, and indeed it does on several respectable browsers. But IE 6 can merely rustle up a small, blue “Hello”. The browser only appears to look at the class, ignoring the ID and, apparently, any subsequent declarations.

You’re going to yawn and tell me these are old news daddio, but I’ve been spoilt for some time by working only on UpMyStreet and sites I’ve specced and designed myself, rather than pandering to those damned clients.

Comments

  • Yes! Thank you! Frames are evil! Almost as bad as those splash pages with pointless Flash animation.

    Mind you, I speak purely as a user since my own HTML is firmly at the primary level. But it’s good enough for what I want to do, which isn’t much.

  • I had a not dissimilar problem with horizontal scrollbars when trying to make a <div> stretch across the width of a page. It seemed always on IE a horiz bar would appear to offer me the delightful opportunity to scroll three or four pixels in either direction. The solution I came up with (avert your eyes) was <body style=”width: 97%”>

  • Regarding the horizontal scrollbar issue…

    I’ve realised that leaving the URL out of the Doctype is a bad idea. For one thing, IE 6’s Quirks Mode leaves the browser using the old IE box model, rather than the standards compliant one. Consequently divs and paragraphs may be narrower than expected.

    So, my current solution is to leave the URL in the Doctype, and in the stylesheet put:
    html { overflow-x: visible; }

    This seems to work although I am, of course, expecting it to create yet another problem… More on all this here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp