Closed Bug 568515 Opened 15 years ago Closed 15 years ago

xmp and plaintext element should be considered as HTMLElement, not HTMLSpanElement

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b1

People

(Reporter: mounir, Assigned: mounir)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached patch Patch v1 (obsolete) — Splinter Review
"User agents must treat xmp elements in a manner equivalent to pre elements." "User agents must treat plaintext elements in a manner equivalent to pre elements." nsHTMLSpanElement had {Get,Set}InnerHTML only for this xmp and plaintext. I don't get why so I prefer to remove them and see if it breaks something in the test suite. Jonas, if you have any idea why there was this special case ? And anyway, do we want to keep this ? I mean, except for -maybe- backward compatibility.
Attachment #447775 - Flags: review?(jonas)
Don't they need the special getter/setter so that |foo.innerHTML = foo.innerHTML;| will be a no-op?
(In reply to comment #1) > Don't they need the special getter/setter so that |foo.innerHTML = > foo.innerHTML;| will be a no-op? Why would we want that especially for these elements ?
The whole jazz of special casing the innerHTML getter/setter seems pretty bogus anyhow. There is nothing in the HTML5 spec saying that that should be done. And it's never really worked anyway since it doesn't affect setting innerHTML to something that contains <xmp>/<pre>/etc. I think we should nuke all of our G/SetInnerHTML implementations and just make sure that the HTML5 fragment parsing algorithm. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#html-fragment-parsing-algorithm Unfortunately, after a quick look I couldn't figure out if we actually implement the fragment algorithm or not though :( Specifically if we set up context properly or not. However the statement "User agents must treat plaintext elements in a manner equivalent to pre elements" in the spec is very ambiguous. <pre> return "pre" for .localName, but I'd imagine that <xmp> shouldn't. So "equivalent" is pretty ambiguous. I imagine what the spec means is that they should have the same IDLs etc. But I'm not sure that that means that they should return the same thing for .toString(). Would be great if you could get that clarified in the spec. Other than that, I'm fine with removing innerHTML getter/setter as long as the HTML5 parser does fragment parsing per spec.
(In reply to comment #3) > Unfortunately, after a quick look I couldn't figure out if we actually > implement the fragment algorithm or not though :( Specifically if we set up > context properly or not. The algorithm is there and the context is set up per spec, but I wouldn't be surprised if the introduction of the 'text' mode in the tree builder had introduced spec bugs in this area.
Comment on attachment 447775 [details] [diff] [review] Patch v1 Looks good to me then. Though I still think we should check with Hixie and get "equivalent" clarified before checking in.
I've asked to Hixie: they should be treated as HTMLElement. See bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9885 Then, I will have to change the patch ;)
(In reply to comment #3) > However the statement "User agents must treat plaintext elements in a manner > equivalent to pre elements" in the spec is very ambiguous. <pre> return "pre" > for .localName, but I'd imagine that <xmp> shouldn't. So "equivalent" is pretty > ambiguous. I just meant that to refer to the semantics, which isn't very relevant for Web browsers (since that's taken care of by the rendering rules explicitly). I've filed a spec bug to make this clearer (http://www.w3.org/Bugs/Public/show_bug.cgi?id=9885).
Depends on: 562008
Summary: xmp and plaintext element should be considered as HTMLPreElement, not HTMLSpanElement → xmp and plaintext element should be considered as HTMLElement, not HTMLSpanElement
Attached patch Patch v2Splinter Review
Attachment #447775 - Attachment is obsolete: true
Attachment #450074 - Flags: review?(jonas)
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
> Why would we want that especially for these elements ? 1) Because it's true for other elements, no? 2) Because the change to not do that broke at least one site so far. See bug 573969. I believe the relevant description is "this is the biggest social network in Spain, bigger than Facebook and used mostly by young people"
Depends on: 573969
And apparently: 3) Because the HTML5 spec says so, though not quite in the way we used to do it.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: