I think we shouldn't use the qualified name for xlink:href and stuff. Instead we should hard-code the xlink prefix to the serializer and emit "xlink:" followed by the localName for attributes in the XLink namespace.

Likewise, I think elements should serialize using the localName even if someone has managed to inject a prefix into the DOM.

Rationale on both counts: Parseability using the HTML parsing algorithm.

Agreed wrt xlink namespace attributes.  (I guess it doesn't matter for xml and xmlns namespaces, since they're required to use the given prefixes anyway.)

For other elements and attributes with a prefix, I don't really have an opinion.

Then you have to deal with the situation where the element has used the xlink prefix for something else.

When serializing an HTML fragment, namespaces that aren't hard-wired to the HTML parsing algorithm will fail to round-trip anyway. Since they are going to break anyway, let's break them in the easiest way possible:
 1) If an attribute is in the XLink, XML or XMLNS namespace, prefix with xlink:, xml: or xmlns:
 2) Otherwise, always use the local name for both attributes and elements.

xmlns="..." (in XMLNS namespace) would turn into xmlns:xmlns="..." with your proposal, but that's easy to fix.

Also, that does not deal with <a x:test="1" y:test="2"> where x and y are bound to the "x" and "y" namespaces.

(In reply to comment #6)
> Also, that does not deal with <a x:test="1" y:test="2"> where x and y are bound
> to the "x" and "y" namespaces.

How do you propose those be dealt with? No matter what, you get a result that won't round-trip using the HTML parser.

I can see why what I proposed may not the the proper defense in depth properties, though. (Consider x:onclick with x bound to a namespace.)

I think serializing using the qualified name and implementing SVG2's way of not needing namespaced attributes -- not sure if that is drafted yet -- is the way to go.

(In reply to comment #8)
> I think serializing using the qualified name and implementing SVG2's way of not
> needing namespaced attributes -- not sure if that is drafted yet -- is the way
> to go.

Nothing like that is drafted yet.  I think we should make {http://www.w3.org/1999/xlink}href attributes be serialized as "xlink:href", and worry about XLink-less href later when the SVG spec and implementations are supporting it.

As I said, that creates theoretical problems for attributes that already have the xlink prefix. When setting SVG namespaced attributes in the HTML DOM just make sure they have the right prefix.

(In reply to comment #10)
> As I said, that creates theoretical problems for attributes that already have
> the xlink prefix. When setting SVG namespaced attributes in the HTML DOM just
> make sure they have the right prefix.

I don't think it should be required to use the right prefix when calling setAttributeNS.  I think many people do setAttribute("http://www.w3.org/1999/xlink", "href", "blah").

I don't think we should care too much about attributes set using the "xlink" prefix but not the XLink namespace; this issue is all about choosing where to break roundtripability.  My suggestion:

  * Known attributes in the XLink, XML and XMLNS namespaces get serialized
    such that they will round trip correctly when being parsed again -- i.e.,
    they will be serialized using "xlink", "xml" and "xmlns" prefixes.  (Except
    for xmlns="" of course.)

  * All other attributes in a namespace get serialized just as their qualified
    name.  If this qualified name matches one of the known attribute (regardless
    of whether it was specified on the element), then don't serialize it.
    (Optional design decision: If the qualified name had no prefix, also don't
    serialize it.  If not, then run the simply allow the possibility of
    identically named attributes when serializing an element.)

That seems simpler than defining a way for the troublesome attributes to be serialized by munging their names somehow.

(In reply to comment #11)
> I don't think it should be required to use the right prefix when calling
> setAttributeNS.  I think many people do
> setAttribute("http://www.w3.org/1999/xlink", "href", "blah").

(They do setAttributeNS, that is.  In SVG content.)

I guess we could also just drop anything that isn't in a supported namespace.

I suspect that would break stuff. Throwing data away also does not seem like a good idea.

We're going to be throwing away the namespace anyway.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale:

I ended up doing a mixture of the proposals above.

If it's an element in the HTML, SVG, or MathML namespaces, then there's no prefix, regardless of the DOM. Otherwise, I just let the qualified name through and round-tripping will break.

If it's an attribute in the XML, XMLNS, or XLink namespaces, then there's the canonical prefix (with an exception for xmlns:xmlns=""). If there's no namespace, there's no prefix. Otherwise, I just let the qualified name through and round-tripping will break.

I didn't do anything to stop duplicate attributes from being output, or to stop namespace prefixes bound to non-canonical namespaces from stomping over the canonical mapping's namespace, etc.

Checked in as WHATWG revision r5743.
Check-in comment: teach the fragment serialisation algorithm about namespaces
http://html5.org/tools/web-apps-tracker?from=5742&to=5743

mass-move component to LC1