8372 2009-11-25 11:53:10 +0000 Restore <spacer> parsing as void element 2010-10-04 14:30:00 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC All CLOSED WORKSFORME P2 normal --- 1 hsivonen ian ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 29724 0 hsivonen 2009-11-25 11:53:10 +0000 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). 29725 1 zcorpan 2009-11-25 12:14:27 +0000 It's not a void element in Opera or WebKit. What problem is solved by making it void? 29731 2 hsivonen 2009-11-25 12:55:36 +0000 (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. 29732 3 zcorpan 2009-11-25 13:22:40 +0000 Which DOM interface do you think spacer should have? Does supporting <spacer> in the rendering gain Web compat? 29733 4 hsivonen 2009-11-25 13:45:14 +0000 (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>. 30032 5 hsivonen 2009-12-09 05:11:39 +0000 Let's try removing <spacer> from Gecko instead.