Today, I landed a patch that made the HTML5 parser in Gecko unaware of the HTML spacer element. (XUL spacer not affected!)

There had previously been a willful violation of the HTML5 specification that made the parser treat the spacer element as a void element. This willful violation used to be necessary, because the layout system in Gecko supported the spacer element as an element that had no rendered children and it would have been bad to make <spacer> hide whatever came ofter it.

Ms2ger wrote a patch that removed the spacer support from layout. This made it possible to remove the willful violation of the specification from the parser.

What was the spacer element and why remove it?

The spacer element was introduced by Netscape as a means of achieving the effect of a single-pixel layout GIF without actually having to use the GIF. That is, spacer just took some amount space in layout. If the meta elements are any indication, Adobe PageMill and perhaps even early versions of Adobe GoLive generated pages that used the spacer element.

Now, one might wonder if removing support for an element breaks the Web. It turns out that it doesn’t in this case. Even though Netscape reimplemented the spacer element in Gecko, the other major browser engines left the spacer element unsupported. Where spacer is still in use, it rarely makes any layout difference. If it made a difference, the authors of the pages would probably notice the difference between browsers and use something other than spacer.

Philip Taylor put together a list of pages that use the spacer element by analyzing a large set of pages downloaded by following links from the Open Directory Project in 2007. I flipped through these pages in 2009 in both Firefox (when it still supported the spacer element) and in Safari (which doesn’t support spacer). On the vast majority of pages, there was no visible difference. On one page, there was a very slight disadvantage from WebKit not supporting spacer. However, the difference was a missing one-pixel-thick border that no user would know was missing without comparing the page in two browsers at the same time.

But the disadvantage also went to the other way and slighly more seriously. Jeff Muizelaar found a site where the layout was worse in Gecko due to a spacer element. The spacer element made the page wider than necessary. Perhaps the element had been forgotten there and the author had recently tested the page in a browser other than Firefox.

Since supporting the spacer element most of the time carried neither an advantage nor a disadvantage and there was a data point showing a disadvantage in one case and no data showing a compelling advantage in any case, it made sense to simplify things and to remove support making Gecko behave the same as other engines on this point.

What’s so special about this?

The removal of support for an HTML element from a major browser engine is a very rare event. After all, all browsers support the plaintext and xmp elements that were already obsolete by the time the HTML 2.0 spec was written.

Netscape discontinued support for the layer, ilayer, nolayer, multicol and basefont elements with the move from Netscape 4 to Netscape 6. However, this wasn’t a removal of support from an engine. Those elements were never implemented in the new engine when the old engine was abandoned. (The Netscape hype element doesn’t count, because it was reportedly platfrom-specific.) Other than that, Wikipedia claims that IE dropped wbr support in version 5.0 (the parser in IE still recognizes wbr as a void element) and Geoffrey Sneddon says Opera has dropped support for the bq element. That seems to be about it!

Let’s celebrate the HTML5-propelled march of progress towards interoperability. The chance to remove browser war-era elements doesn’t come often. Thanks to everyone involved!