Moving element from XHTML document to HTML document breaks .setAttribute in some cases

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
9 years ago
8 years ago

People

(Reporter: smaug, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Created attachment 385978 [details]
testcase, all alerts should be the same.

If an XHTML element has attributes FOO="BAR" and foo="bar", 
moving the element to a HTML document doesn't allow one to get FOO attribute using
.getAttribute. The problem doesn't happen if one has normal XML element which is
moved to HTML document.

In 1.9.1 we do still separate XHTML elements from HTML elements. XHTML elements
don't lose their XML behavior when moved to HTML document.
You can still use getAttributeNS to get both attributes, right?

I'm not really sure what we can do here, other than trying to collapse the two attributes. However that both seems dangerous (since we don't know which attribute to keep), as well as a big perf problem.
(Reporter)

Comment 2

9 years ago
We can have a flag in the (X)HTML element which tells whether it should
behave like XML or HTML. The flag would be set based on the original
ownerDocument, I guess.
(Reporter)

Comment 3

9 years ago
I know that sucks a bit too. Then when elements are moved from XHTML to
HTML, there are elements which otherwise look like HTML elements, but
behave like XML.
(Before the namespace change, elements didn't look similar.)
I think we should follow the spec, so if that is the behavior you want you should argue on the whatwg/htmlwg list. Personally I like the current design more, but lets debate in a standards forum instead.
You need to log in before you can comment on or make changes to this bug.