Closed Bug 531030 Opened 12 years ago Closed 11 years ago

Remove support for the <spacer> element

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b5
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: hsivonen, Assigned: Ms2ger)

References

()

Details

(Keywords: dev-doc-complete, html5)

Attachments

(1 file, 2 obsolete files)

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
Blocks: 531056
(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
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.
Assignee: nobody → Ms2ger
Attached patch WIP (obsolete) — Splinter Review
Still need to test.
Blocks: 379654
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>
Attached patch Patch v1 (obsolete) — Splinter Review
Didn't find any tests for spacers.
Attachment #461269 - Attachment is obsolete: true
Attachment #462088 - Flags: review?(dbaron)
Attachment #462088 - Flags: review?(bzbarsky)
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: review?(dbaron)
Attachment #462088 - Flags: review?(bzbarsky)
Attachment #462088 - Flags: review+
Attachment #462088 - Flags: approval2.0?
Comment on attachment 462088 [details] [diff] [review]
Patch v1

a2.0=dbaron
Attachment #462088 - Flags: approval2.0? → approval2.0+
blocking2.0: --- → betaN+
Attachment #462088 - Attachment is obsolete: true
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/45716b17fb82
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b5
You need to log in before you can comment on or make changes to this bug.