This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8372 - Restore <spacer> parsing as void element
Summary: Restore <spacer> parsing as void element
Status: CLOSED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-25 11:53 UTC by Henri Sivonen
Modified: 2010-10-04 14:30 UTC (History)
4 users (show)

See Also:


Attachments

Description Henri Sivonen 2009-11-25 11:53:10 UTC
Some time during the past 9 months or so, the spec has regressed <spacer> parsing by making it no longer parse as a void element.

Since the parsing section is mandatory and the rendering section is optional, it seems that the easiest way to address the non-support of <spacer> in most browsers while avoiding poking at sunk cost too much would be making the element parse as a void element.

This also seems like the safer bet, considering that there are instances of the <spacer> element out there (particularly on pages created with Adobe GoLive 4).
Comment 1 Simon Pieters 2009-11-25 12:14:27 UTC
It's not a void element in Opera or WebKit. What problem is solved by making it void?
Comment 2 Henri Sivonen 2009-11-25 12:55:36 UTC
(In reply to comment #1)
> It's not a void element in Opera or WebKit. What problem is solved by making it
> void?

1) <spacer> has always been void when authored, so making it void avoids weirdly-shaped DOMs.
2) Making it void allows UAs to support rendering of <spacer> (since the rendering section is informative). Making it non-void in the normative parsing section effective prevents optional rendering support.
Comment 3 Simon Pieters 2009-11-25 13:22:40 UTC
Which DOM interface do you think spacer should have?

Does supporting <spacer> in the rendering gain Web compat?
Comment 4 Henri Sivonen 2009-11-25 13:45:14 UTC
(In reply to comment #3)
> Which DOM interface do you think spacer should have?

Apparently HTMLSpacerElement that is a mere marker interface that doesn't differ from HTMLElement.

> Does supporting <spacer> in the rendering gain Web compat?

I flipped through the pages from http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/tag/spacer in both Firefox and Safari. I couldn't find a single page where the lack of <spacer> support disadvantaged Safari in a noticeable way. I found one case (the same that Maciej found) where you could spot a tiny disadvantage to Safari when comparing pages side-by-side:
http://www.literaturkritik.de/public/rezension.php?rez_id=1547

I did notice that rendering the border around linked images disadvantaged Firefox in some cases. https://bugzilla.mozilla.org/show_bug.cgi?id=452915

From this data, it's hard to make the case that non-Gecko browsers should add layout-level support for <spacer>.
Comment 5 Henri Sivonen 2009-12-09 05:11:39 UTC
Let's try removing <spacer> from Gecko instead.