[Bug 28720] New: Interop: browsers already handle duplicate "fake" xmlns declarations during XML serialization

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28720

            Bug ID: 28720
           Summary: Interop: browsers already handle duplicate "fake"
                    xmlns declarations during XML serialization
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM Parsing and Serialization
          Assignee: travil@microsoft.com
          Reporter: travil@microsoft.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

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.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 28 May 2015 22:34:28 UTC