This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec currently dodges the problem of setAttribute's lack of validation for potential XHTML namespace conflicts. I was OK with this, but recently have been shown interoperability problems where browsers apparently already handle this case. :-| Example, parse the following into the DOM: <svg></svg> The node is in the SVG namespace. Using DOM do the following: document.getElementsByTagName('svg')[0].setAttribute('xmlns', 'anotherNS'); (or define a prefix) The resulting attribute will be in the null namespace, since setAttribute is not namespace aware. According to the spec in "record the namespace information", step 2, this attribute would not be considered as a legitimate default namespace declaration. As a result, the spec would currently serialize this element as: <svg xmlns="http://www.w3.org/2000/svg" xmlns="anotherNS" /> (Not well formed.) However, some browsers seem to already handle this case (IE11 didn't though this is being fixed for the Interop problem we found). Both Chrome and Firefox avoid emitting duplicate xmlns default namespace declarations, but do it differently. - Chrome: <svg xmlns="anotherNS" /> - Firefox: <a0:svg xmlns:a0="http://www.w3.org/2000/svg" xmlns="anotherNS" /> The spec should have something to say about how this duplication can be avoided, because the serialization result really should be well-formed if possible. There are two primary approaches to fixing this, such that existing spec algorithms will handle this case: 1. Make setAttribute and HTML parsing (partially) namespace aware. 2. Add more special case handling to the "record the namespace information" algorithm in this spec. Rather than address the problem in the DOM spec (make setAttribute and HTML parsing semi-namespace aware, and all the downstream updates that would require), I'm proposing taking the 2nd approach of updating the serialization algorithm. Proposed changes: In the "record the namespace information" section, instead of limiting the search for XMLNS namespaced attributes only, expand the search to include attributes in the null namespace (e.g., added via HTML parsing or setAttribute) that "look like" default or namespace prefix definitions. A similar change is required in the attributes processing algorithm. If fixed in this manner, the previous example would be serialized as: Spec: <svg xmlns="http://www.w3.org/2000/svg" /> (The spec opts to drop the as-yet-unused extra default namespace declaration under the assumption that if it is needed it will be re-generated in a child element. This is done in two parts, identified first in the "XML Serialization Algorithm" Step 13.5.1, and then applied later in 3.5.1 when processing the element's attributes, assuming the above change is made.)
I am confused. As far as I can tell the given situation has several possible outcomes: 1. <svg xmlns="http://www.w3.org/2000/svg" xmlns="anotherNS" /> (IE11) 2. <svg xmlns="anotherNS" /> (Chrome) 3. <a0:svg xmlns:a0="http://www.w3.org/2000/svg" xmlns="anotherNS" /> (Firefox) 4. <svg xmlns="http://www.w3.org/2000/svg" /> (no current browsers) You said that 1 caused an interop problem, which I take to mean a compatibility problem with an existing site. Why do you think introducing a completely new way, 4, would help? Wouldn't it be better to converge on either 2 or 3? (Or, ideally, 1, but if you've found content that breaks under that, then I guess that's no good.)
(In reply to Domenic Denicola from comment #1) > I am confused. As far as I can tell the given situation has several possible > outcomes: > > 1. <svg xmlns="http://www.w3.org/2000/svg" xmlns="anotherNS" /> (IE11) > 2. <svg xmlns="anotherNS" /> (Chrome) > 3. <a0:svg xmlns:a0="http://www.w3.org/2000/svg" xmlns="anotherNS" /> > (Firefox) > 4. <svg xmlns="http://www.w3.org/2000/svg" /> (no current browsers) > > You said that 1 caused an interop problem, which I take to mean a > compatibility problem with an existing site. Why do you think introducing a > completely new way, 4, would help? Wouldn't it be better to converge on > either 2 or 3? (Or, ideally, 1, but if you've found content that breaks > under that, then I guess that's no good.) In many places (speaking of the spec algorithms generically) it made sense not to follow any browsers due to weird edge cases that they all had. In other words, this spec blazes new ground rather than just paving the cow paths. In this specific case, I could re-write the spec algorithm to follow 3 which is one possible "correct" solution, but 4 is also a "correct" solution and what Edge is planning to implement given other namespace serialization fixes we've made since IE11 to more closely follow this spec.
Sure. But why do you think 4 will be any more compatible than 1?
(In reply to Domenic Denicola from comment #3) > Sure. But why do you think 4 will be any more compatible than 1? Good question. In the broken site that prompted this bug, the issue was caused by having duplicate "xmlns" attributes in the same element. The site works in Chrome and Firefox, so any option _except_ for 1 (IE11) and the current spec are more compatible. :)
Great, thanks! My confusion is now ameliorated. I'll leave it to others to comment on whether 2, 3, or 4 is a better solution for implementations to try to converge on.
> under the assumption that if it is needed it will be re-generated in a child > element For what it's worth, the Gecko behavior is premised on the assumption that if you have a default namespace declaration (or indeed any namespace declaration) then it should stay in place (since chances are descendants use it, and getting rid of it will lead to a huge proliferation of xmlns attributes down the tree. So we do the minimal possible fixup within that constraint of just generating a prefix and namespace declaration for the one element in question.... Maybe this doesn't matter too much if there are no practical cases in which an element has a default namespace different from its own.
(In reply to Boris Zbarsky from comment #6) > > under the assumption that if it is needed it will be re-generated in a child > > element > > For what it's worth, the Gecko behavior is premised on the assumption that > if you have a default namespace declaration (or indeed any namespace > declaration) then it should stay in place (since chances are descendants use > it, and getting rid of it will lead to a huge proliferation of xmlns > attributes down the tree. So we do the minimal possible fixup within that > constraint of just generating a prefix and namespace declaration for the one > element in question.... > > Maybe this doesn't matter too much if there are no practical cases in which > an element has a default namespace different from its own. Yes, I suspect that in cases where this might happen, the element in question has already been moved around in the DOM from its original parsed-position. Thus assumptions about which namespaces would more naturally apply to the element or its children are hard to predict.