Bug 16496 – XMLSerializer doesn't include namespaces on nodes in HTML documents

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Christopher Schmidt]

The XMLSerializer serializeToString method does not include namespaces on bare nodes. as a workaround, it is possible to wrap the node in a document, and then serialize the document instead, but this behavior does not match the behavior of Firefox 2.0 or 3.0, nor Opera.

[David Kilzer (:ddkilzer)]

Confirmed with a local debug build of WebKit r28774 with Safari 3.0.4 (523.12) on Mac OS X 10.4.11 (8S165).

[Alexey Proskuryakov]

The issue here is that the node in question belongs to an HTML document, so we serialize it accordingly.

Firefox and Opera use XML serialization for XMLSerializer, and HTML one for innerHTML. WebKit uses the same code for both, but checks document type.

[Alexey Proskuryakov]

See also: bug 47768.

[Ryosuke Niwa]

This is a bug in markup.cpp.

[Rob Buis]

Created attachment 136035 [details]
Patch

[WebKit Review Bot]

Comment on attachment 136035 [details]
Patch

Attachment 136035 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12264985

New failing tests:
fast/innerHTML/innerHTML-custom-tag.html
editing/pasteboard/paste-noscript-svg.html

[WebKit Review Bot]

Created attachment 136045 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Rob Buis]

Created attachment 136169 [details]
Patch

[WebKit Review Bot]

Comment on attachment 136169 [details]
Patch

Attachment 136169 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12372189

New failing tests:
fast/xsl/xslt-processor.html

[WebKit Review Bot]

Created attachment 136220 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Ryosuke Niwa]

Comment on attachment 136169 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=136169&action=review

> Source/WebCore/editing/markup.cpp:762
> +String createMarkup(const Node* node, EChildrenOnly childrenOnly, Vector<Node*>* nodes, EAbsoluteURLs shouldResolveURLs, bool xmlFragmentSerialization)

Please use enum instead of bool. r- because of this.

> Source/WebCore/xml/XMLSerializer.cpp:44
> +    return createMarkup(node, IncludeNode, 0, DoNotResolveURLs, true);

With enum, the semantics of this code will be much clearer.

[Rob Buis]

Created attachment 137071 [details]
Patch

[WebKit Review Bot]

Comment on attachment 137071 [details]
Patch

Attachment 137071 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12392908

New failing tests:
fast/xsl/xslt-processor.html

[WebKit Review Bot]

Created attachment 137078 [details]
Archive of layout-test-results from ec2-cr-linux-04

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-04  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Rob Buis]

(In reply to comment #11)
> (From update of attachment 136169 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=136169&action=review
> 
> > Source/WebCore/editing/markup.cpp:762
> > +String createMarkup(const Node* node, EChildrenOnly childrenOnly, Vector<Node*>* nodes, EAbsoluteURLs shouldResolveURLs, bool xmlFragmentSerialization)
> 
> Please use enum instead of bool. r- because of this.
> 
> > Source/WebCore/xml/XMLSerializer.cpp:44
> > +    return createMarkup(node, IncludeNode, 0, DoNotResolveURLs, true);
> 
> With enum, the semantics of this code will be much clearer.

Again a good suggestion with the enum, I tried to implement this in my latest patch.
About the failing testcase, I know the <br /> part is an improvement. We serialize now in xml mode so we end up with <br /> to feed to xslt, same as in FF. The ns addition on <head> is something which I am not sure libxslt or my patch is doing, will check later.
Cheers,

Rob.

[Ryosuke Niwa]

Comment on attachment 137071 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=137071&action=review

> Source/WebCore/editing/MarkupAccumulator.cpp:491
> +    if (!m_fragmentSerialization == XMLFragmentSerialization && node->document()->isHTMLDocument())

You mean m_fragmentSerialization != XMLFragmentSerialization?

[Rob Buis]

Created attachment 138579 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 138579 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=138579&action=review

> LayoutTests/fast/dom/dom-serialize-namespace.html:1
> +<html>

You might want DOCTYPE here.

[Rob Buis]

Hi Ryosuke,

(In reply to comment #18)
> (From update of attachment 138579 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=138579&action=review
> 
> > LayoutTests/fast/dom/dom-serialize-namespace.html:1
> > +<html>
> 
> You might want DOCTYPE here.

Thanks! However, should I rebaseline fast/xsl/xslt-processor.html? I am not sure how the end result should look, also in FF and Opera the test does not seem to work so I can't compare. Should I look into the test result differences more or do you know how it should look?
Cheers,

Rob.

[WebKit Review Bot]

Comment on attachment 138579 [details]
Patch

Attachment 138579 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12518413

New failing tests:
fast/xsl/xslt-processor.html

[WebKit Review Bot]

Created attachment 138718 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Ryosuke Niwa]

Has this patch been landed?

[Eric Seidel (no email)]

I do not believe this was ever landed.

[Rob Buis]

(In reply to comment #23)
> I do not believe this was ever landed.

Sorry guys, I can't remember exactly what happened but maybe there were still DRT tests failing with the final patch. I can have another look this weekend.

[Rob Buis]

Created attachment 205259 [details]
Patch

[Build Bot]

Comment on attachment 205259 [details]
Patch

Attachment 205259 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/971324

New failing tests:
fast/xsl/xslt-processor.html
svg/custom/xlink-prefix-in-attributes.html

[Build Bot]

Created attachment 205267 [details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Rob Buis]

Created attachment 205270 [details]
Patch

[Rob Buis]

Created attachment 205301 [details]
Patch

[Build Bot]

Comment on attachment 205301 [details]
Patch

Attachment 205301 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/961768

New failing tests:
fast/xsl/xslt-processor.html

[Build Bot]

Created attachment 205308 [details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.3

[Build Bot]

Comment on attachment 205301 [details]
Patch

Attachment 205301 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/981235

New failing tests:
fast/xsl/xslt-processor.html

[Build Bot]

Created attachment 205311 [details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Rob Buis]

Created attachment 205354 [details]
Patch

[Build Bot]

Comment on attachment 205354 [details]
Patch

Attachment 205354 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/977329

New failing tests:
inspector/elements/set-outer-html-for-xhtml.xhtml

[Build Bot]

Created attachment 205361 [details]
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-10  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.3

[Build Bot]

Comment on attachment 205354 [details]
Patch

Attachment 205354 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/926539

New failing tests:
inspector/elements/set-outer-html-for-xhtml.xhtml

[Build Bot]

Created attachment 205362 [details]
Archive of layout-test-results from webkit-ews-08 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-08  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Rob Buis]

Created attachment 205402 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 205402 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=205402&action=review

> Source/WebCore/editing/MarkupAccumulator.cpp:107
> +    , m_fragmentSerialization(fragmentSerialization)

This implicit conversion to bool is bogus.

> Source/WebCore/editing/MarkupAccumulator.cpp:436
> +        if (element->namespaceURI() == XMLNames::xmlNamespaceURI)
> +            prefix = xmlAtom;
> +        if (!prefix.isEmpty()) {
> +            result.append(prefix);
> +            result.append(':');
> +        }

prefix is always empty unless we execute the assignment above: prefix = xmlAtom.

> Source/WebCore/editing/MarkupAccumulator.cpp:551
> -    if (node->document()->isHTMLDocument())
> +    if (m_fragmentSerialization != XMLFragmentSerialization && node->document()->isHTMLDocument())

It seems like we want to extract this condition as a helper function.
In fact, we might even want to add a boolean indicating this as a member variable to speed things up.

> Source/WebCore/editing/MarkupAccumulator.h:117
> +    bool m_fragmentSerialization;

Why is this a boolean?

[Rob Buis]

(In reply to comment #40)
> (From update of attachment 205402 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=205402&action=review
> 
> > Source/WebCore/editing/MarkupAccumulator.cpp:107
> > +    , m_fragmentSerialization(fragmentSerialization)
> 
> This implicit conversion to bool is bogus.

Right, see below.

> > Source/WebCore/editing/MarkupAccumulator.cpp:436
> > +        if (element->namespaceURI() == XMLNames::xmlNamespaceURI)
> > +            prefix = xmlAtom;
> > +        if (!prefix.isEmpty()) {
> > +            result.append(prefix);
> > +            result.append(':');
> > +        }
> 
> prefix is always empty unless we execute the assignment above: prefix = xmlAtom.

Right, I was thinking of adding more cases where we assign prefix for certain namespaces like we do for attributes. To fix this bug this seems to be actually the only one I need. I guess I'll eliminate prefix temp var for now.

> > Source/WebCore/editing/MarkupAccumulator.cpp:551
> > -    if (node->document()->isHTMLDocument())
> > +    if (m_fragmentSerialization != XMLFragmentSerialization && node->document()->isHTMLDocument())
> 
> It seems like we want to extract this condition as a helper function.
> In fact, we might even want to add a boolean indicating this as a member variable to speed things up.

A helper is a good idea, will do that.

> > Source/WebCore/editing/MarkupAccumulator.h:117
> > +    bool m_fragmentSerialization;
> 
> Why is this a boolean?

Seems like a mistake on my behalf, fixing.

Will have a new patch up soon.

[Rob Buis]

Created attachment 205423 [details]
Patch

[Rob Buis]

Created attachment 205487 [details]
Patch

[Rob Buis]

Uploaded one more time to see if it goes green.

[Ryosuke Niwa]

Comment on attachment 205487 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=205487&action=review

> Source/WebCore/ChangeLog:9
> +        http://html5.org/specs/dom-parsing.html#xmlserializer. In this mode

Could you refer to a specific revision of http://domparsing.spec.whatwg.org instead?
Since it's a live standard, the content at the given URL is going to change, and
I'd like to be able to identify which version of the specification is implemented in this patch in the future.

> Source/WebCore/editing/MarkupAccumulator.cpp:276
> -    if (attribute.name() == XMLNSNames::xmlnsAttr) {
> +    if (attribute.name() == XMLNSNames::xmlnsAttr || (inXMLFragmentSerialization() && attribute.localName() == XMLNSNames::xmlnsAttr.localName() && attribute.namespaceURI().isEmpty())) {

It seems like this is part of the DOM4 spec here:
http://dom.spec.whatwg.org/#locate-a-namespace
instead of it being specified in the serialization spec.

If that were the case, then we should probably add a new member function to Attribute that implements this locate-a-namespace algorithm.

> Source/WebCore/editing/MarkupAccumulator.cpp:304
> +        // Suppress xmlns: for xml namespace, it is implied
> +        if (inXMLFragmentSerialization() && namespaceURI == XMLNames::xmlNamespaceURI)
> +            return;

Where is this specified? The current specification is extremely vague about this.

> Source/WebCore/editing/MarkupAccumulator.cpp:434
> +    if (inXMLFragmentSerialization() && element->prefix().isEmpty()) {
> +        if (element->namespaceURI() == XMLNames::xmlNamespaceURI) {
> +            result.append(xmlAtom);
> +            result.append(':');
> +        }
> +    }

Ditto.

> Source/WebCore/editing/MarkupAccumulator.cpp:436
> +    if ((inXMLFragmentSerialization() || !element->document()->isHTMLDocument()) && namespaces && shouldAddNamespaceElement(element))

Ditto.

> Source/WebCore/editing/MarkupAccumulator.cpp:491
> +    if ((inXMLFragmentSerialization() || !documentIsHTML) && namespaces && shouldAddNamespaceAttribute(attribute, *namespaces))
> +        appendNamespace(result, prefixedName.prefix(), prefixedName.namespaceURI(), *namespaces);

Ditto.

[Rob Buis]

Created attachment 205641 [details]
Patch

[Build Bot]

Comment on attachment 205641 [details]
Patch

Attachment 205641 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/974242

New failing tests:
fast/xsl/xslt-processor.html

[Build Bot]

Created attachment 205645 [details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Build Bot]

Comment on attachment 205641 [details]
Patch

Attachment 205641 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/995333

New failing tests:
fast/xsl/xslt-processor.html

[Build Bot]

Created attachment 205673 [details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.3

[Rob Buis]

Created attachment 205732 [details]
Patch

[Build Bot]

Comment on attachment 205732 [details]
Patch

Attachment 205732 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/981812

New failing tests:
inspector/elements/set-outer-html-for-xhtml.xhtml

[Build Bot]

Created attachment 205742 [details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.3

[Build Bot]

Comment on attachment 205732 [details]
Patch

Attachment 205732 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/866608

New failing tests:
svg/batik/filters/feTile.svg
inspector/elements/set-outer-html-for-xhtml.xhtml

[Build Bot]

Created attachment 205743 [details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06  Port: mac-mountainlion  Platform: Mac OS X 10.8.3

[Rob Buis]

Created attachment 205744 [details]
Patch

[Rob Buis]

Hi Ryosuke,

(In reply to comment #45)
> (From update of attachment 205487 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=205487&action=review
> 
> > Source/WebCore/ChangeLog:9
> > +        http://html5.org/specs/dom-parsing.html#xmlserializer. In this mode
> 
> Could you refer to a specific revision of http://domparsing.spec.whatwg.org instead?
> Since it's a live standard, the content at the given URL is going to change, and
> I'd like to be able to identify which version of the specification is implemented in this patch in the future.

I tried to do that in my latest patch.

> > Source/WebCore/editing/MarkupAccumulator.cpp:276
> > -    if (attribute.name() == XMLNSNames::xmlnsAttr) {
> > +    if (attribute.name() == XMLNSNames::xmlnsAttr || (inXMLFragmentSerialization() && attribute.localName() == XMLNSNames::xmlnsAttr.localName() && attribute.namespaceURI().isEmpty())) {
> 
> It seems like this is part of the DOM4 spec here:
> http://dom.spec.whatwg.org/#locate-a-namespace
> instead of it being specified in the serialization spec.

It is a bit different, this one does not look at ancestors. I changed this code a bit in my latest patch.

> If that were the case, then we should probably add a new member function to Attribute that implements this locate-a-namespace algorithm.
> 
> > Source/WebCore/editing/MarkupAccumulator.cpp:304
> > +        // Suppress xmlns: for xml namespace, it is implied
> > +        if (inXMLFragmentSerialization() && namespaceURI == XMLNames::xmlNamespaceURI)
> > +            return;
> 
> Where is this specified? The current specification is extremely vague about this.

I removed this in my latest patch, but it is covered under Namespace constraint: Reserved Prefixes and Namespace Names in http://www.w3.org/TR/REC-xml-names/.

> > Source/WebCore/editing/MarkupAccumulator.cpp:434
> > +    if (inXMLFragmentSerialization() && element->prefix().isEmpty()) {
> > +        if (element->namespaceURI() == XMLNames::xmlNamespaceURI) {
> > +            result.append(xmlAtom);
> > +            result.append(':');
> > +        }
> > +    }
> 
> Ditto.

This is done in order not to loose the namespace associated with the element, I put a comment for that in my latest patch.

> > Source/WebCore/editing/MarkupAccumulator.cpp:436
> > +    if ((inXMLFragmentSerialization() || !element->document()->isHTMLDocument()) && namespaces && shouldAddNamespaceElement(element))
> 
> Ditto.

I think this actually needs no explanation, for xml serializing we simply may want to add a namespace depending on the element.
 
> > Source/WebCore/editing/MarkupAccumulator.cpp:491
> > +    if ((inXMLFragmentSerialization() || !documentIsHTML) && namespaces && shouldAddNamespaceAttribute(attribute, *namespaces))
> > +        appendNamespace(result, prefixedName.prefix(), prefixedName.namespaceURI(), *namespaces);
> 
> Ditto.

For xml serializing we simply may want to add a namespace depending on the attribute.

Note that the latest patch finally shows up all green!

[Rob Buis]

Created attachment 206684 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 206684 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=206684&action=review

> Source/WebCore/ChangeLog:9
> +        http://html5.org/specs/dom-parsing.html#xmlserializer (23 May 2013). In this mode

Could you refer to a specific hash instead?

> Source/WebCore/ChangeLog:27
> +        (WebCore::MarkupAccumulator::serializeNodesWithNamespaces): makes sure xml namespace/prefix is known so it is never used in namespace declarations.
> +        (WebCore::MarkupAccumulator::appendNamespace): Avoid adding namespace declarations that do not differ from current default namespace.
> +        (WebCore::MarkupAccumulator::appendOpenTag): Print xml prefix if the element's namespace is XML to avoid conflicts.
> +        (WebCore::MarkupAccumulator::appendAttribute): Force any calculated prefix/namespace pair into the generated namespace.
> +        (WebCore::MarkupAccumulator::shouldAddNamespaceAttribute): Also take into account xmlns attributes with no namespace.
> +        (WebCore::MarkupAccumulator::shouldSelfClose): Force self-closing to create well-formed XML elements.
> +        * editing/MarkupAccumulator.h: Use EFragmentSerialization.

It's still unclear to me which parts are referring to the spec mentioned about
and which parts are matching Firefox/IE. It's helpful have that information in the change log, not in the code.

> Source/WebCore/editing/MarkupAccumulator.cpp:144
> +        // Make sure xml prefix and namespace are always known to ensure these Namespace constraints:
> +        // The prefix xml MUST NOT be declared as the default namespace.
> +        // The prefix xml MAY, but need not, be declared (XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names)

Instead of copying & pasting the spec. text, can we refer to a specific section from which this text is copied?

> Source/WebCore/editing/MarkupAccumulator.cpp:436
> +        // According to DOM3 appendix B Namespace Normalization we now should create a default namespace declaration to make this namespace well-formed.
> +        // However, XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names says:
> +        // "The prefix xml MUST NOT be declared as the default namespace.", so use the xml prefix explicitly.

Ditto about referring to sections of the specifications.

[Rob Buis]

Thanks for the review!

(In reply to comment #59)
> (From update of attachment 206684 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=206684&action=review
> 
> > Source/WebCore/ChangeLog:9
> > +        http://html5.org/specs/dom-parsing.html#xmlserializer (23 May 2013). In this mode
> 
> Could you refer to a specific hash instead?

I added a commit hash before landing.

> > Source/WebCore/ChangeLog:27
> > +        (WebCore::MarkupAccumulator::serializeNodesWithNamespaces): makes sure xml namespace/prefix is known so it is never used in namespace declarations.
> > +        (WebCore::MarkupAccumulator::appendNamespace): Avoid adding namespace declarations that do not differ from current default namespace.
> > +        (WebCore::MarkupAccumulator::appendOpenTag): Print xml prefix if the element's namespace is XML to avoid conflicts.
> > +        (WebCore::MarkupAccumulator::appendAttribute): Force any calculated prefix/namespace pair into the generated namespace.
> > +        (WebCore::MarkupAccumulator::shouldAddNamespaceAttribute): Also take into account xmlns attributes with no namespace.
> > +        (WebCore::MarkupAccumulator::shouldSelfClose): Force self-closing to create well-formed XML elements.
> > +        * editing/MarkupAccumulator.h: Use EFragmentSerialization.
> 
> It's still unclear to me which parts are referring to the spec mentioned about
> and which parts are matching Firefox/IE. It's helpful have that information in the change log, not in the code.

I reworded the commit log, I still thing the per method explanations are useful as well.

> > Source/WebCore/editing/MarkupAccumulator.cpp:144
> > +        // Make sure xml prefix and namespace are always known to ensure these Namespace constraints:
> > +        // The prefix xml MUST NOT be declared as the default namespace.
> > +        // The prefix xml MAY, but need not, be declared (XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names)
> 
> Instead of copying & pasting the spec. text, can we refer to a specific section from which this text is copied?

Done.

> > Source/WebCore/editing/MarkupAccumulator.cpp:436
> > +        // According to DOM3 appendix B Namespace Normalization we now should create a default namespace declaration to make this namespace well-formed.
> > +        // However, XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names says:
> > +        // "The prefix xml MUST NOT be declared as the default namespace.", so use the xml prefix explicitly.
> 
> Ditto about referring to sections of the specifications.

Done.

I discovered before landing that one change in appendAttribute is not needed to fix this bug, I left it out for now but think I'll include it in a patch for bug 22958.

[Rob Buis]

Committed r152685: <http://trac.webkit.org/changeset/152685>

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.