Closed Bug 531030 Opened 13 years ago Closed 12 years ago
Remove support for the <spacer> element
Gecko supports the <spacer> element, which is a Netscape extension to HTML. IE8, Safari 4 and Opera 10 don't support the element. HTML5 previously had parser support for this element, but Hixie removed the parser support. I noticed this today, when updating the HTML5 parser to spec. Having layout support for <spacer> is bad if the parser doesn't treat the element as a void element. I think this leaves two reasonable options: 1) Removing support for this legacy Netscapism that no one else implements from layout. 2) Trying to get it (re-)formalized in HTML5 even though other browsers have gotten away without implementing it. (I'll pursue this if this bug gets WONTFIXed.) (The third option of letting this be the only case where Gecko's HTML5 parser deviates from the spec doesn't seem like a good option--at least not without pursuing the other two first.) In July 2007, Philip Taylor analyzed dmoz-listed pages http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/index and found the element on ~1% of pages analyzed. However, following links to those pages now shows that usage is on decline (some pages no longer have <spacer>). It seems that Adobe GoLive 4 has generated <spacer> elements. Opera MAMA ranks <spacer> above <blink> in usage frequency (not clear if those are pages or instances of the tag): http://dev.opera.com/articles/view/mama-phrase-block-list/
I should mention that I'm not particularly advocating a particular course of action here, but I'm more seeking the layout module owners' opinion. (One might argue that even if <spacer> weren't supported in layout, it would still make sense to parse it as a void element just in case, because parsing it that way is a low-cost thing to do.)
(In reply to comment #1) > (One might > argue that even if <spacer> weren't supported in layout, it would still make > sense to parse it as a void element just in case, because parsing it that way > is a low-cost thing to do.) Filed a spec bug with this argument: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8372
13 years ago
(In reply to comment #0) > In July 2007, Philip Taylor analyzed dmoz-listed pages > http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/index > and found the element on ~1% of pages analyzed. However, following links to > those pages now shows that usage is on decline (some pages no longer have > <spacer>). It seems that Adobe GoLive 4 has generated <spacer> elements. Even though the frequency of usage seems high, it doesn't seem to matter for perceived Web compat: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8372#c4
Opinions, considering http://www.w3.org/Bugs/Public/show_bug.cgi?id=8372#c4 ?
Let's get rid of it.
In the words of Mortal Kombat: Finish it.
Is there really anything layout specific about spacers? As far as I can tell, they're just static positioned boxes, right? I think we should move this bug to Core::DOM.
> Is there really anything layout specific about spacers? Yes. There's nsSpacerFrame.cpp (and the bits in nsCSSFrameConstructor to create it). The DOM part is very very small compared to that.
Oh, I stand corrected then.
Still need to test.
You should probably add a bunch of reftests using an idea like this: test-1.html: <p>foo</p> <spacer height="100"> <p>bar</p> test-ref.html: <p>foo</p> <p>bar</p>
Didn't find any tests for spacers.
Still need to remove SpacerFrame_id from layout/generic/nsQueryFrame.h
Comment on attachment 462088 [details] [diff] [review] Patch v1 r=bzbarsky
Attachment #462088 - Flags: approval2.0?
Comment on attachment 462088 [details] [diff] [review] Patch v1 a2.0=dbaron
Attachment #462088 - Flags: approval2.0? → approval2.0+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b5
You need to log in before you can comment on or make changes to this bug.