The Browser Dereliction Report

The Worst Ways Our Web Software Lets Us Down
2.1, 2007-07-02
Brian Lalonde

Important

You are not stuck with the Internet software that came with your computer! Changing browsers is remarkably painless, and very rewarding. If you use Windows or Linux, give Firefox a try. If you are a Mac OS X user, Safari is probably the best way to go. The ecology of the entire Internet needs you!

Web browsers use a collection of technologies to surf the Internet, most developed by the W3C. However, no browser completely understands even one of these basic formats for showing pages (HTML/XHTML), styling them (CSS), downloading them from the network (HTTP/HTTPS), and more (Unicode, PNG, ECMAScript).

Though IE7 represents much progress, the people who make web sites are still so busy trying to make the web work around all of these bugs that the overall quality of the Internet suffers.

Page Issues (HTML 4.01: 1999-12-24)

date/time input (W3C)

The lack of date and/or time inputs in the HTML specification is inexcusable. Internet Explorer provides a pair of ActiveX controls (the accidentally unsafe, but otherwise excellent Date and Time Picker, and the MonthView for selecting date ranges) for this, and there are many scripted solutions, but a simple control would have provided a consistent interface, and simpler (quicker, less error-prone) development. This was originally to be included in the HTML+ specification, but was dropped before HTML+ became HTML3 (the ridiculous scribble input, for adding a drawing to a form, actually lasted longer, before also being dropped).

The WHAT-WG is working on a recommendation called Web Forms 2.0, which adds various date and time types to the input element. Opera 9 has already implemented the current draft.

The Date and Time Picker and the Month View

The Date and Time Picker (custom date format)
The Date and Time Picker (with checkbox for selecting no value)
The Date and Time Picker (long date format)
The Date and Time Picker (date only)
The Date and Time Picker (time only)
The MonthView control (showing Today button)
The MonthView control (showing week numbers)
link bars (top, up, next, prev, first, last, contents, index, glossary, etc.)

Mozilla, Netscape 6+, Opera, and iCab support site navigation via the rel attribute of the link tag (and it is disabled by default in Mozilla). Plugins exist to add a linkbar to Internet Explorer and Firefox. Any rel attribute of a tags (hyperlinks) or rev attributes are ignored.

Link Bars

Firefox Site Navigation Bar Extension
Mozilla's Link Bar
Opera's Link Bar (Windows)
Opera's Link Bar (Macintosh)
iCab's Standard Links toolbar (enlarged)
The <LINK>-Bar extension for Internet Explorer
rich textarea input (W3C)

Another noticeable omission in HTML is a way to input formatted or structured text. There have been some ActiveX implementations, but now both Internet Explorer and Mozilla offer HTML editing (though not simply as a form input). A lightweight Rich Text Format or simplified HTML (inline formatting or semantic tags only) input would also be better than just plain text.

The WHAT-WG is working on a recommendation called Web Forms 2.0, which adds an accept attribute to the textarea element to specify a MIME type.

option groups and labels

Most browsers now support option groups (although only MacIE breaks down the list and displays each group as a submenu, rather than simply adding headers to what is likely an already long list), but they have completely bungled the W3C's attempt to provide backward compatibility by not supporting the label attribute of the option tag correctly (if at all). WinIE (starting with 6, the first version to support optgroups), Mozilla, and Opera do not use option labels when supplied. Labels allow more terse option text when grouped under headings, while allowing legacy browsers to see the complete option text.

Option Groups
MacIE got it right: A select box with option groups. The submenu approach can make a long list much easier to navigate.
MacIE got it right: A list box with option groups. However, the group labels do not seem to influnce the width of the list.
Safari comes close; ungrouped options (e.g. Opera, iCab, Lynx, Other) should not be indented.
Safari comes close; ungrouped options (e.g. Opera, iCab, …) should not be indented
Mozilla and Internet Explorer for Windows use the full option values in a group, rather than the context-shortened labels.
Mozilla and Internet Explorer for Windows use the full option values in a group, rather than the context-shortened labels.
hover tips (Safari)

Safari completely ignores the title attribute; other browsers provide this info in tooltips or balloon help, which is particularly helpful for explaining abbreviations, adding annotations, and more.

Hover Tips

table columns (Mozilla and Opera)

Mozilla and Opera do not allow styles to be set for an entire column as they do for rows. Opera honors only CSS background color and HTML alignment of columns, while Mozilla ignores even those. Some conflict and abiguity in the HTML and CSS standards have led to a great deal of esoteric debate about nesting and inheritance, and I can understand trying to keep behavior consistent, but this is a very practical feature, and it is time to implement it now.

table header and footer printing (all but Mozilla)

Most browsers know to put the table footer at the bottom of the table, but do not print the header and footer on each page for very long tables.

Missing Table Headers

Missing headers for multi-page tables: Which column was which?
Missing headers for multi-page tables: What were those numbers, again? Oh, and the top row got split across a page break. Nice. Thanks Internet Explorer!
link prefetch (only supported by Mozilla)

Mozilla is the only browser that allows page authors to designate resources that should be cached before they are actually used. This can be very useful for dynamic pages that add images or sounds based on usage. Resources marked as next for link bars are also prefetched, allowing for faster linear site navigation.

link accesskey in IE (focus only)

All browsers now support the accesskey attribute, which assigns a hotkey to a link (or a form field). In Internet Explorer, however, the hotkey only moves the focus to the link, requiring the user to press Enter after the hotkey.

default style linking (W3C)

According to the HTML4 standard, stylesheets are intended for "screen" by default, instead of the more inclusive and intuitive setting of "all", which is what all existing browsers use as a default.

embedded movies, animation, and more (IE)

The proprietary use of the codebase and classid attributes in the object tag is incompatible with non-IE browsers (though there are workarounds, such as Flash Satay).

Style Issues (CSS 2.0: 1998-05-12)

connecting print (and other) stylesheets from a primary stylesheet (Windows IE, Safari)

Pointing to stylesheets using the @import rule with a media type (all, aural, braille, embossed, handheld, print, projection, screen, tty, or tv) confuses Internet Explorer for Windows and Safari. If you see 404 (file not found) errors in a server log for requests like /include/url(/include/style.css)+print, it is because an @import rule has confounded IE.

display: list-item, run-in, table-* (IE)

Using (X)HTML as a markup languge, as it was intended, to describe content, can frequently require using tags that browsers incorrectly assume they know how to format. A full set of tools to override browser display assumptions is critical to this kind of development, making the web more flexible.

system colors (Safari)

CSS color value based on user preferences are not only incompletely supported, but default to white for both foreground and background colors such as menutext and menu. This means that if you want to provide menus that look native to the user's system, Safari users will not be able to see them.

System Colors

System Colors: Firefox on Windows
System Colors: Internet Explorer 6 on Windows
System Colors: Opera 7 on Windows
System Colors: Firefox on Macintosh
System Colors: Internet Explorer 5 on Macintosh is broken (black text on a black background)
System Colors: Safari on Macintosh is broken (black text on a black background, white text on a white background)
page breaks: @page, page-break-inside, page-break-before, page-break-after

The ability to specify page size, margins, orientation, and breaks is still lacking. Internet Explorer only allows specificying page breaks before and after page items.

custom counters

Automatic and nested counters, making list or section numbering a choice of a website's style developer are still unavailable.

custom bullets (display: marker; marker-offset)

No browser yet supports the ability to fully customize bullets in a stylesheet; only an existing list-style-type may be used.

automatic quotes

Internet Explorer does not support style quotes at all, and both Mozilla and Safari fail to support nested quotes.

radically inconsistent font sizes

Font sizes given with absolute size keywords (e.g. large, x-small) differ unacceptably between browsers (Internet Explorer and Netscape in particular).

outline (only supported by Opera)

This variant of a border does not affect the size of an item, and need not be rectangular.

display: run-in, inline-table, compact (Mozilla)

Mozilla simply does not know what to do with these.

content: attr(attribute) function (Safari)

Safari does not support the attr(attribute) function in a content property.

dynamic pseudo-classes: :active, :hover, :focus (IE)

Internet Explorer supports these (with some odd limitations) for link elements, but nothing else. So, if you want the cursor to change to a help indicator while hovering over abbreviations, or to change the , your IE audience will be left out.

:first-child pseudo-class (IE)

Maybe you want the first item in a bulleted list to look a little different? Perhaps the first paragraph should use a different font size? Need to add a bottom border to the header in the center column of your page, but only if it is the first thing in the column? Tough.

:before/:after and content (IE)

If you were thinking about adding a visual indicator (an icon, or a small [popup] text) after links that will open in a popup window, you can forget it if you need to coddle IE users.

Network Issues (HTTP 1.1/rfc2068: 1997-01-02)

True XHTML Support (XHTML 1.0: 2000-01-26) (IE)

Correctly labelled XHTML documents (using the application/xhtml+xml MIME type) confounds Internet Explorer.

Reset Content

The 205 Reset Content code, meant primarily for data-entry applications, simply means that the page should be reset. For the user, this typically would just clear the form, so the next record could be quickly submitted without waiting for the same page to be sent from the server again. A handy feature, and implementation is simple: just reload the page from cache. Simple, but completely and absolutely unsupported by any browser.

Moved Permanently and Gone

The 301 Moved Permanently code indicates that the page has a new location. Just as with the postal service, this is meant as a way to leave a temporary forwarding address during a transition period. Browsers are supposed to update the bookmark to the page. They do not. The 410 Gone code indicates that the page has been deleted. The browser should offer to delete the bookmark.

External linking to page resources (WinIE, Opera, Safari)

Links for associating stylesheets, scripts, and other resources to pages can be done for an entire website by configuring the server software, rather than requiring each of the pages to be modified. Sadly, only Internet Explorer for the Macintosh and Mozilla-based browsers honor these Link: headers.

Indication of Secure Links and Forms

A lock icon is shown by browsers if the current page was downloaded securely, but there is no security indication for links and forms. This means that users are unable to make an informed decision about clicking a link or submitting a form based on whether they are encrypted. As a consequence, a page that contains a blank form that sends its information securely cannot be delivered over a non-secure connection without looking insecure.

text data label (text MIME supertype) (W3C)

For some reason, only plain text is currently considered text data. Originally, any data that was text-based was marked as such, so that it could be translated as it is moved from system to system. This included programming language code, rich text (RTF), formatted text (LaTeX), HTML, XML, contact directories, tab-separated text data, etc. If you used a Linux box, and transferred any text data to an IBM mainframe, the text designation could tell the system to convert the data from ASCII to EBCDIC, so that it would be usable on the new machine. This was also critical because nearly every system seems to use a different code to mark the end of a line; data marked as text could be automatically updated to the system in use whereever it was being copied to. At some point, the text type stopped being a practical way to allow translation, and became a useless semantic indicator of readability to certain (non-technical) people.

Other Issues

Unicode support (Unicode 1.0: 1991-10-01; Unicode 2.0: 1996-07-01; Unicode 3.0: 2000-01-01; Unicode 4.0: 2003-08-01; Unicode 5.0: 2006-07-14)

Current support for Unicode is terrible. The only font for the Windows platform that implements a significant portion of the standard in Arial Unicode MS, which is only available as a part of Microsoft Office ($$$), and only when specifically selected during the install. MacOSX provides a decent font, but the larger audience still using OS 9 languishes. Unicode characters, like arrows, danger and warning symbol, informational symbols, dingbats, etc. work much better as characters than images: they require no download time, and since they are typically vector-based, they can be scaled to any size and still look clear and smooth.

embedded images (and more); the data URI scheme (rfc2397: 1998-08-01) (IE and Safari)

The ability to include (usually small) images in a page increases speed and flexibility, while reducing complexity. Consider: browsers are only allowed to download four files at a time, small files can take nearly as long to request from the server as to download, and removing the need to queue up and process a download simplifies a page.

User-Agent identifiers

What a mess. Nearly all browsers lie about their identity, claiming to be "Mozilla". On top of that, they add several useful pieces of potentially useful information like operating system and platform, but in no particular order or consistent format. There is no standard for this data (it would certainly be too much to ask for a simple "Opera 7.11; Windows 2000" or "Safari 1.0; Mac OS X"), and so it becomes virtually impossible to "read" it. Instead, a giant list of these identifiers must be maintained, and used to match against; whenever a new browser is released, it must be added to the list. There is a great deal of history that has lead to this situation, and good web development does not rely on this information to determine how to present information (it is best to simply present standards-based documents, so all programs should be able to read them), but knowing this information is critical to understanding what weaknesses exist in the browsers of large portions of an audience. This cycle must end now.