Clarify how user agents should implement vendor-specific extensions

[jarek-foksa]

I'm building an SVG editor that allows users to save SVG documents using either XML or HTML 5 serialization.

In order to preserve editing capabilities I need to store app-specific data as content attributes. For example, when user draws a star path, I want to preserve the information about the number of arms, the inner radius and the outer radius of the star.

When using XML serialization, the obvious solution is to use custom namespace:

 <svg viewBox="0 0 500 500" xmlns="http://www.w3.org/2000/svg" xmlns:bx="http://www.boxy-svg.com/bx">
   <path bx:shape="star" bx:arms="6" bx:r1="10" bx:r2="20" d="...">
 </svg>

However, I'm not sure how the corresponding markup should look like when using HTML 5 serialization. Should I use data-* attributes?

 <svg viewBox="0 0 500 500">
   <path data-shape="star" data-arms="6" data-r1="10" data-r2="20" d="...">
 </svg>

... or data-vendor-* attributes?

 <svg viewBox="0 0 500 500">
   <path data-bx-shape="star" data-bx-arms="6" data-bx-r1="10" data-bx-r2="20" d="...">
 </svg>

... or x-vendor-* attributes?

 <svg viewBox="0 0 500 500">
   <path x-bx-shape="star" x-bx-arms="6" x-bx-r1="10" x-bx-r2="20" d="...">
 </svg>

The data-* approach is very likely going to cause clashes when the file is opened with another editor.

The data-vendor-* approach does not seem to be mentioned in either HTML 5 or SVG 2 spec.

The x-vendor-* approach seems to be what the HTML 5 spec recommends, but it's not mentioned by the SVG 2 spec.

I would propose to update the SVG 2 spec to explicitly state what is the preferred approach here, so that various SVG editors could generate files with consistent sytnax. Ideally, just reference the corresponding section in the HTML 5 spec.

[AmeliaBR]

I would be ok adding a recommendation that if authoring tools use data-* attributes, they should informally namespace them with a data-vendor-* syntax.

I'm also okay linking to the HTML text on an x-vendor-* approach to extensions while emphasizing the warning that "Pages that use such attributes are by definition non-conforming."

You could also simply use the vendor:attribute approach, which isn't any more or less invalid than the x- option in an HTML document. But it is problematic if you or your users want to write scripts for accessing these custom attributes in-browser, since the XML and HTML parser will create different DOM representations (a namespaced attribute vs an attribute in default namespace with a : character in it).

Mostly this just makes me sad that HTML gave up on custom XML namespaces when all that was needed was for the default namespace to apply automatically based on doctype.

[jarek-foksa]

I was just told by Ian Hickson on implementors@lists.whatwg.org that data-* attributes would be inappropriate for this purpose because they are meant for authors.

The HTML 5 spec says that "User agents must not derive any implementation behaviour from these (data-) attributes or values." I think recommending data-vendor- attributes here would be against the HTML 5 spec.

While using vendor:* attributes would make the document non-conforming just like x-vendor-* attributes, the former feel a lot more inconsistent and confusing (is this XML or HTML? Should I use getAttribute() or getAttributeNS()?).

I think the x-vendor-* approach is the best one because it is consistent with HTML 5 and it makes it easy to strip the vendor data from the document and make it fully conformant if user prefers so. Authoring tools could implement two separate export options, one for stripping vendor data which would remove all x-* attributes and one for stripping user data which would remove all data-* attributes.

[tabatkins]

That gloss of the reasoning behind data-* attributes is not quite right.

What's not supposed to be allowed is using data-* attributes as a generic metadata inclusion mechanism that unrelated tools are meant to scrape. They're not well-designed for that use-case; it's better to use microdata or rdfa.

It's fine to use them to store information that your tool generates and uses for its own purposes. The only downside is that the names can potentially clash with ones the author is using, but that's true of literally every usage except code that the author hand-writes. Just vendor-prefix your names and you'll be fine.

[AmeliaBR]

The important thing is that a user agent displaying content does not do anything with a data-* attribute, so that if there is a name clash with the author's data you don't get weird behavior. So it would be very inappropriate for a browser-specific feature to be implemented that way.

Authoring tools are somewhat different. You could even argue that they count as "author" too. But I don't want to get into an argument with HTML editors on that point.

Perhaps we could point to the section on x-vendor-* attributes in HTML as a note in the foreign namespaces and private data section, while still recommending XML namespaces where possible. It basically amounts to a promise that we will never introduce native SVG attributes that match that syntax. I think we can make that promise.

---

Aside: should the section on foreign namespaces & private data be moved to the Structure chapter, next to the data-* attributes section? It's kind of out of place in the Embedded content chapter, since foreign metadata is really something quite different from <foreignObject>.

[jarek-foksa]

From my understanding of the spec there are two types of data that can be attached to an element:

• Author data, which is used by a specific website or web app and is defined by data-* attributes.
• Vendor data, which is used by a specific browser or authoring tool (i.e. user agent) and that might alter how the element renders and behaves when loaded by that user agent.

I'm going to read the related spec sections again as I'm still not sure whether I understand things correctly.

[nikosandronikos]

@jarek-foksa From the examples you've given, data-bx-* (though I think something more unique than 'bx' would be better) seems the most appropriate (as others have said).
I'd prefer the HTML spec warned of the risk of collisions and suggested strategies for avoiding them. (e.g. data-vendor-*), but if that's not going to happen we could.

@AmeliaBR That chapter is about more than just foreignObject though.
The definition for embedded content is:

content that imports another resource into the document, or content from another vocabulary that is inserted into the document.

Most of what is in the 'Foreign namespaces and private data' section seems to fit that definition. But I do agree that there should be some connection between that section and data attributes. Maybe it should be the data attribute section that is moved? (We should make a new issue if this is going to result in lots of discussion).

[dstorey]

data attributes are now defined via the HTMLOrSVGElement mixin in HTML rather than in SVG, so any advice or requirements should be in that spec (also tools can also author HTML like Macromedia Dreamweaver so advice should probably be consistent between the two markup languages). As such I don't think this requires an edit on our side.

Feel free to reopen if you disagree.