An HTML 4.0 MIA List - Internet Explorer 5.0: With Style, Finally? - Style Watch
Internet Explorer 5.0: With Style, Finally?
An HTML 4.0 MIA List
Well, once upon a time, there was this specification - as a matter of fact it was the first HTML specification - called HTML 2.0. And in this specification was mention of an element called LINK, which did all sorts of exciting things like specifying links to the next or previous documents in a series, links to the author or a copyright notice, things like that. This was several years ago now. And you know what? The all-new, feature-filled, radio-downloading, related-links searching, active-setup running Internet Explorer 5.0 hasn't a clue what to do with it. Mosaic understood it in its later incarnations, Lynx has been good friends with it for years, but Internet Explorer would be much the same browser if LINK never existed on the face of this Earth. For all of these incredible mechanisms that allow you to quickly get a list of related links, you think someone might have thought of looking at good old LINK. But no, it was not fated to be so.
Actually, this is not entirely true. As you may well know, Internet
Explorer has supported one use of the LINK element for some time
now. The LINK element is used to link style sheets to HTML
documents, and the syntax
HREF="stylesheet.css"> is recognized by Internet Explorer.
As a matter of fact, the HTML Element reference on Microsoft's Site
Builder Network describes LINK as an element that "Enables the current
document to use styles defined in an external style sheet."
This reference has not been updated to reflect changes in Internet Explorer 5.0, and some hunting on the SBN threw up one enhancement. You can use the following syntax to define a shortcut icon:
<LINK REL="shortcut icon" HREF="http://www.acme.com/icons/acmelogo.ico">
What this does is point to an image in ICO format that will be shown next to any shortcuts created to the page, such as in the favorites menu. This is a wonderfully proprietary feature that forces authors to use a proprietary image format. The idea of an icon is not entirely bad, but the phrase "shortcut icon" used as a value for the REL attribute is definitely platform-specific, and inventing new link types when so many standard ones already exist is rather pointless.
Let's look at some more complicated examples, for instance paragraph
elements with or without end-tags (see Tutorial 4). The face
of one of the most familiar browser bugs smiles back at us happily.
Multilengths are still unsupported, so you can't use them to specify
relative table column and frame sizes. Link Types are missing along with
LINK itself, so just throw meta-information down the drain.
Improper element nesting (blocks in headings, Is continued
between paragraphs etc.) is still rendered with no complaints.
ABBR is a mystery to IE 5.0. Q, a wonderful element that
can do nice things like insert quotation marks before and after quotes,
obviously baffled Microsoft's programmers so much they just gave up and
decided to implement something easier like real-time net audio. The soft
­) is now not displayed, but not used as a line break
Character alignment on table cells is still a fantasy, I guess the Microsoft programmers in the Word department are a lot smarter than the guys in the IE department since they've got it working since Word ran on DOS 3.0, but hey, what am I complaining about anyway, table cells can't even be justified. Caption alignment is still wrong, buggy, and breaks the specification.
And of course let us not forget the great white hope of HTML 4.0, the infamous OBJECT element, the first consistent way of embedding data objects in HTML, that started its life by being so hideously broken in Internet Explorer 3.0 that it crashed the browser without fail unless it was used for ActiveX controls, was fixed but unimplemented in IE 4.0, and remains unimplemented in IE 5.0. Why, I wonder, is this so? If Microsoft can give us proprietary ways to include applets, software components, video, audio, and yes, images too, why can't they fix their parser so we can use OBJECT for them instead? Maybe for the same reason that they can't implement OPTGROUP for cascading menus in form elements or LABEL (which the people at Mozilla.org somehow managed to get working in a matter of hours. Why doesn't Microsoft just use their code, it's free anyway).
So, the verdict is thumbs down on HTML. Let's take a look at the CSS support and see if Microsoft has fared any better.
Produced by Stephanos Piperoglou and
Created: April 7, 1999
Revised: Apr 30, 1999