Web Devout tidings

For such an important attribute, it’s strange that the title attribute doesn’t have better support than it does in modern web browsers. title is used to provide secondary descriptive text about an element, often rendered as a tooltip on mouse hover. Unfortunately, all major web browsers have bugs with whitespace and/or character reference handling on this attribute, making the feature often unusable for multiple-line texts.

I have constructed a title attribute tooltip test suite which I would like all major browsers to pass. Currently, Internet Explorer, Firefox, Opera, Safari, and Konqueror all fail at least one of the tests.

Internet Explorer allows line breaks in the tooltip value, but in the incorrect manner: it will display a line break if there are newlines or carriage returns in the source HTML. Newlines in the attribute source should be ignored and carriage returns should be converted to spaces, as in other CDATA attribues. The proper way to represent a line break in the attribute value is to use a newline character reference (
), which Internet Explorer also (correctly) converts into a line break. IE also handles tab characters in the source incorrectly.

Firefox has perhaps the most disruptive bug, which limits the tooltip text to a small number of characters on a single line. Progress on fixing that bug is blocked by another bug relating to the calculation of tooltip heights. Firefox also has several problems with newlines, carriage returns, and tabs in the source HTML and doesn’t convert newline character references into line breaks. This is overall the worst implementation of the title attribute of all major browsers.

Opera fares well in the whitespace handling, but it doesn’t convert newline character references into line breaks, making multi-line values impossible.

Safari makes line breaks on newlines and carriage returns in the source and uses tab characters for wide spacing instead of ignoring the newlines and converting carriage returns and tabs into spaces.

Konqueror generally does well, but it handles newline characters in the source like Internet Explorer does. I would say this is the best implementation so far, although still not perfect.

With the growing amount of web-based applications aiming to provide the functionality and feel of traditional desktop applications, proper tooltip display of the title attribute value is becoming increasingly important. Please petition the browser developers for attention to this issue.

Edit: I’ve corrected the link to the Firefox bug report. The previously linked report was specifically for Mozilla/SeaMonkey.

Chris Wilson, group program manager for the Internet Explorer platform team at Microsoft, recently referred in his blog to an e-mail conversation we had when my standards support resource was fairly new and undeveloped. He wrote in his blog post:

Most unfortunately, there are no more details on many of the problems David encountered, or test cases that my team can test against. When I contacted David a year or so ago, he couldn’t give me any further details, so I’m not even sure how we make progress against that site. Solid test cases we can access and bug reporting would help

Back when he first contacted me, I admit that my tables were quite vague and not nearly as useful as I believe they are today. I have since done a lot of work trying to make my wording in the support descriptions accurate and informative enough to easily fashion test cases from them. But I also recognize that having such test cases readily available would definitely help.

Therefore, I have developed a (non-exhaustive) set of tests for many of the most common IE7 CSS bugs described in my support tables. The mass test case is made to be easy to read and the issues are documented in the source.

Some CSS issues, such as with the cursor property, obviously can’t fit into this format very easily, so I left them out of the tests. But overall, I think this test case covers most of the important issues of immediate concern. Once Internet Explorer supports :before and :after (in some version after IE7), there will be many more features to test.

I will send this test suite to Chris Wilson and continue to participate through the Internet Explorer feedback system.

Yesterday, this site’s standards support resource appeared on the front page of digg, an extremely popular social bookmarking site, and the resulting impact made Web Devout inaccessible to many visitors for several hours. At the peak, the server managed to serve over 7000 requests to a total of nearly 1500 unique visitors in one hour. That doesn’t include the many people whose connections timed out during the wait. The digg post has achieved almost 2000 diggs (bookmark actions, which are treated as votes in favor of the page). More initial statistics are available.

The digg post was marked by some users as “inaccurate”, possibly due to a recent blog post by Chris Wilson, group program manager on the Internet Explorer platform development team, where he criticised some aspects of the structure of the standards support resource and the resulting percentage values. I presented my counterarguments in the comments of that post and I recommend that people take a read.

Shortly after Web Devout appeared on the digg front page, I quickly set up a server-side caching system to reduce the server impact and hopefully make the site available to more people. The site is now functional again and the caching system will remain up and running.

Since this site’s standards support resource was referenced in an article linked to on Slashdot, there has been some renewed discussion critical of Microsoft’s efforts in browser development. I have seen some blogs such as Web 2.0 Explorer and Download Squad complain that Internet Explorer 7 won’t be fully CSS 2.1 compliant.

In a somewhat rare move, I must come to Microsoft’s defense on this one. As far as I know, Internet Explorer 7 isn’t adding any nonstandard features to CSS and the developers have put forth a lot of work to fix as many of the most common CSS bugs as time allowed them. After a recent update, my tables currently show that Internet Explorer 7 has 55% support for CSS 2.1, up from 51% in IE6. That’s a 4% improvement. Although that doesn’t sound like much, it should be noted that it’s about the same total difference that the latest versions of Firefox and Opera have improved over their predecessors (Firefox 1.5 showed a 5% increase and Opera 9 showed a 3% increase).

The CSS standard is very large and complex, and I’m not sure if Microsoft is structured in such a way that they can put too many more people on the Internet Explorer core development team without it becoming too disorganized. All things aside, a 4% increase isn’t too bad for a year’s worth of work considering the other more user-focused improvements. It certainly doesn’t put Internet Explorer anywhere near where we web developers would like it to be, but that simply isn’t a realistic possibility in this short amount of time. In fact, considering that they’re adding improvements at about the same speed as the other browsers, it’s doubtful that Microsoft (or any company in their position) can catch up to the competition in the foreseeable future. That’s a reality we have to face, and it isn’t really the fault of Microsoft’s current efforts, but its past efforts (or lack thereof).

I think the Internet Explorer developers are starting to get it. They’ve been opening up lately and have expressed growing care for standards. I don’t see how Trident can become a decent layout engine without a ground-up rewrite as every other major layout engine had in the CSS era, but the developers are doing what they can. In IE7, Microsoft showed a willingness to break backwards compatibility in the interest of standards, and I think that was a very important precedent to set. I don’t know if they’re likely to rewrite the engine from scratch, but they are no longer giving the finger to web standards and I don’t believe the developers deserve the disrespect many have given them for the work they are doing right now. What I believe Microsoft deserves disrespect for is the long wait they gave us and all of the proprietary junk beforehand.

Yes, Internet Explorer’s standards support is still abysmal compared to Firefox and Opera, and at this rate it looks to be so for many more versions to come. But I don’t see any reason to chastise Microsoft for what they’re currently doing. Instead, ask why they waited so long if they knew they were unable to catch up afterwards, and encourage the public to select their web browsers based on the true quality of the browsers and not simply based on the browsers’ market inertia. As alternative browsers gain a powerful market share, web developers can begin sneaking newer standards into their websites and drive the public to using only modern web browsers. If Internet Explorer can’t handle what all of the other competitors can, then it’s a simple survival of the fittest situation and the worst browser is left in the mud. If Microsoft can pull a rabbit out of their hat and make Internet Explorer a true competitor, then there should be no complaints. Internet Explorer 7 has a decent amount of improvements, and we’ll see where the developers take it from there.

But I’m still hoping for a full engine rewrite.

I have mentioned here and there that XHTML (and XML in general) wasn’t designed to support SGML null end tags. This isn’t completely true. XML supports a restricted and altered form of null end tags, and in fact they are used all the time.

Null end tags are a way to abbreviate an end tag to a single character. They are not supported by most common HTML user agents, but they do exist in HTML’s profile of SGML and there are HTML user agents that support them. In HTML and the default SGML profile, null end tags look like this:

<title/This is the title of the page/

For fully compliant HTML user agents, the above is equivalent to the following:

<title>This is the title of the page</title>

As you can see, the contents of the element are surrounded by “/” characters, which are used more or less like the quotes used for attribute values. If an SGML profile and DTD requires a certain element’s end tag to be omitted, only one slash is relevant for the element (any further slashes will be treated as character data). For example, the following tag is valid in HTML:

<img src="image.png" alt="An image"/

Although it doesn’t save any characters and isn’t widely supported, it is perfectly legal according to the standard. This is where I have discussed problems with XHTML. The above isn’t legal in XHTML, but the following is the closest equivalent:

<img src="image.png" alt="An image"/>

An XHTML user agent would see the above as a single img tag, but a fully compliant HTML user agent would see it as a shortened null end tag like the previous example but with a “>” character after it. The “>” character would be seen as regular character data and would display on the page itself. Despite common practice, a space before the “/” character wouldn’t change this.

I have said that this issue is due to XHTML/XML not supporting null end tags. However, it’s more accurate to say that XML doesn’t support null end tags in the same way as HTML. Rather than the contents being surrounded by two slashes, they are surrounded by a slash and a greater-than sign (/ ... >) with the additional constraint that they may only be used when the contents are empty. So the second img example is actually XML’s version of null end tags: the start tag ends with the “/” character and the end tag is represented by the “>” character. Because end tags may not be omitted in XML, the “>” character is always required, and because the null end tag rule in XML is defined as “IMMEDNET” (explained below), it must close immediately after it is started, so there may be no actual content.

Although the specifications don’t clearly discuss these issues, they are a result of the respective standards’ SGML declarations that define the profile of SGML used. See the HTML SGML declaration and the XML SGML declaration. These declarations are automatically assumed by the browser when they are given hint to treat the page as HTML or XML (such as via the content type). The SGML declaration defines the most basic level of how the SGML document is written. It defines which characters define tags, marked sections, character references, processing instructions, etc., what kinds of shorthand features may be used, possibly some default character entities that are available regardless of the DTD, and other lexical aspects of the document. The SGML declaration is applied on top of a default profile, called the “reference concrete syntax” that is defined in the SGML standard itself.

The HTML SGML declaration isn’t very big because it mostly uses SGML’s defaults. The defaults include “/” for syntax.delim.net, meaning that null end tag contents are delimited by “/” characters. XML uses “>” for syntax.delim.net, plus “/” for syntax.delim.nestc. Nestc is an extension to the original SGML standard that provides a different value for the null end tag delimiter that finishes the start tag. XML uses other extensions, such as more specific options in the “features” section. HTML enables features.minimize.shorttag, which allows shorthand constructs like null end tags, while XML specifically has features.minimize.shorttag.starttag.netenabl set to “IMMEDNET” which, as mentioned above, enables null end tags with the restriction that they must close immediately after opening.

The reason XML was designed to support this form of null end tags was to reduce the potential clutter caused by a large number of empty elements. The null end tag delimiters were altered so that the null end tags don’t look too alien for people who are used to the widely supported parts of the HTML standard. They were designed to look like regular start tags with a simple slash before the end, which reminds people of the function of end tags. In this way, they managed to design XML to be strict, efficient, intuitive, and compatible with modern SGML user agents that know where to find the SGML declaration.