Comments (7)
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.
from svgwg.
I was just told by Ian Hickson on [email protected] 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.
from svgwg.
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.
from svgwg.
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>
.
from svgwg.
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.
from svgwg.
@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).
from svgwg.
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.
from svgwg.
Related Issues (20)
- Sizing properties section should link to a more recent references
- Should SVG's `<script>` element support the `fetchpriority` attribute analogous to HTML's `<script>` element? HOT 2
- Should support async and defer attributes on script elements
- Specification of the behaviour of `inline-size: 0`
- No way to construct a TimeEvent, so its initTimeEvent method is fully useless
- The IDL of SVGSVGElement.getElementById does not allow null
- Should SVG's `<image>` element support the `fetchpriority` attribute analogous to HTML's `<img>` element? HOT 1
- Decimal point not allowed according to Path Data ENBF HOT 3
- Enable lazy loading for URLs on use href HOT 1
- Does SVG support Custom elements? HOT 1
- Error about drawto_command in SVG 2.0 path EBNF HOT 2
- What should happen when trying to insert empty strings or separators into SVGStringList
- SVGAElement.prototype.text should be removed HOT 6
- Serialization of transform functions and transform attribute.
- Update UA stylesheet rules to use :any-link instead of :visited or :link HOT 2
- Incorrect description of path horizontal and vertical movement HOT 7
- Publish current status of SVG
- Is the `path()` function allowed for the `d` property? HOT 2
- Can we fix arc interpolation? HOT 4
- Implementing CSS Text Wrapping in SVG HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from svgwg.