spacer Element Is GoneToday, 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.
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.
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!