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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla2.0b1
People
(Reporter: mounir, Assigned: mounir)
References
Details
Attachments
(1 file, 1 obsolete file)
4.41 KB,
patch
|
sicking
:
review+
|
Details | Diff | 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)
![]() |
||
Comment 1•15 years ago
|
||
Don't they need the special getter/setter so that |foo.innerHTML = foo.innerHTML;| will be a no-op?
Assignee | ||
Comment 2•15 years ago
|
||
(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.
Comment 4•15 years ago
|
||
(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.
Attachment #447775 -
Flags: review?(jonas) → review+
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.
Assignee | ||
Comment 6•15 years ago
|
||
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 ;)
Comment 7•15 years ago
|
||
(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).
Comment on attachment 447775 [details] [diff] [review]
Patch v1
Cool :)
Attachment #447775 -
Flags: review+ → review-
Assignee | ||
Updated•15 years ago
|
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
Assignee | ||
Comment 9•15 years ago
|
||
Attachment #447775 -
Attachment is obsolete: true
Attachment #450074 -
Flags: review?(jonas)
Attachment #450074 -
Flags: review?(jonas) → review+
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 10•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
![]() |
||
Comment 11•15 years ago
|
||
> 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
![]() |
||
Comment 12•15 years ago
|
||
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.
Description
•