Why not using HTML5 data-* attributes

[SeriousM]

Hi, is there a good reason why you don't go with the data-* attributes and invent your own standard with v-*?

From https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_data_attributes:

In addition, search crawlers do not index data attributes' values.

[etanxing]

you can use Vue.config({ prefix: 'data'}) to overwrite 'v-*'.

[yyx990803]

1. Because to avoid potential conflicts using data- attributes, you still need to prefix everything as data-v-*, that's unnecessary verbosity with no obvious benefits to me.
2. Vue.js removes all directive attributes after compiling them, so you rendered markup is clean and tidy.
3. What @etanxing said.

[SeriousM]

Vue.js removes all directive attributes after compiling them, so you rendered markup is clean and tidy.

Well, vue.js works AFTER the html was parsed by the browser which means it contains invalid attributes. But ok, I can't change it but now I know a bit more. Thank you

[Aqours]

It casue an error when I use use Vue.config({ prefix: 'data'}) to overwrite v-* (Vue 1.0.16 csp), and I found noting related to this in document.

[yyx990803]

@MinonHeart you are looking at an old issue and that config option has been deprecated long time ago. The short answer is you can no longer configure the prefix, because v- attributes are removed when rendered anyway.

[xMort]

I would welcome this feature. Any attribute that is not in HTML specification or starts with data-* prefix is not valid. Your IDE will also complain about this and I don't like warnings in my code :(

Here is simple demo in the latest IntelliJ IDEA

[alanondra]

Actually it's valid HTML but there're a lot of IDEs and editors that does not respect the spec.

No, it's not. All custom attributes not belonging to a declared XML namespace must be prefixed with data- and must be [a-z]+(-[a-z]+)*. Of course, even then, they must be defined with that character range to be valid XML. You "couldn't find the spec" because it doesn't say that.

[FibreFoX]

Am I right, that these specs are the ones talked about?
HTML-Spec, the xml-compatible part: https://www.w3.org/TR/html5/infrastructure.html#xml
HTML-Spec: https://www.w3.org/TR/html5/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes

EDIT: as far as I understood the spec, this means this will not be allowed, because this prohibits to contain U+003A: <todo-item v-for="todo in todos" v-bind:todo="todo"></todo-item>

[yyx990803]

Note the difference between valid HTML syntax vs fully-valid HTML. The former means it adheres to the syntax constraints laid out in the spec, and only the syntax; the latter entails following the spec to every extreme detail, e.g. if an element doesn't have a certain attribute then you cannot use it on that element.

At the syntax level attribute names are defined as follows:

Attributes have a name and a value. Attribute names must consist of one or more characters other than the space characters, U+0000 NULL, U+0022 QUOTATION MARK ("), U+0027 APOSTROPHE ('), ">" (U+003E), "/" (U+002F), and "=" (U+003D) characters, the control characters, and any characters that are not defined by Unicode.

So all Vue templates are valid HTML at the syntax level. We have practical reasons to do that because it enables any spec-compliant HTML parser to be able to parse Vue templates - this makes it possible to reuse excellent HTML-based tools already out there in all aspects of tooling. However, it is my opinion that striving for fully-valid HTML in a templating syntax is completely pointless, because the template is not what eventually gets rendered in the browser. The template's job is to convey the connection between your JavaScript model and the final desired output (which should be, and will be fully-valid HTML). Making your templates fully valid HTML has zero practical benefits except for maybe getting rid of the warnings from your overly-rigorous IDE.

[alanondra]

And it is my opinion that a page's first render (before any JS events fire) should be free of broken HTML in the event that the dependent Javascript fails to render or clean up its mess. Few things are uglier than seeing a JS framework fail to render and having a jumbled mess of template tag soup and half-functioning elements. Then there's the idea that adding exclusive attributes/prefixes adds an additional attack vector. Then again, I may be in a minority position these days.

[Grimy]

Note the difference between valid HTML syntax vs fully-valid HTML.

The spec makes no such distinction. There’s only one conforming class for documents (2.2.1):

Conforming documents are those that comply with all the conformance criteria for documents.

One of these conformance criteria is (3.2.1):

Authors must not use elements, attributes, or attribute values that are not permitted by this specification

This means that documents using the v-model attribute are non-conforming. Also of note (2.2.1):

Conformance checkers must check that the input document conforms when parsed without a browsing context (meaning that no scripts are run, and that the parser's scripting flag is disabled)

However, this may not matter: conforming user-agents are still required to parse the v-model attribute as intended.

[FibreFoX]

Maybe it would be a good idea to document this design-decision somewhere inside the vue-documentation. As the attributes are not "XML-attribute"-compatible (because they are containing the colon sign U+003A) this must have been decided sometime in the past.

Any relation to some specs for HTML5 would be nice, there seems a lot of confusion about this whole "data-" thing. Don't get me wrong, I used to understand HTML differently, but it seems to "just work" inside the browsers ... but fails for syntax-checker even like the w3c-markup checker. I tried some dummy website of mine, how the syntax checker sees some v-on:click and attributes, and it fails with errors like Attribute v-if not allowed on element div at this point.. When there is some evaluation about used web-frameworks, and the customer requires the website to be syntax-checker-compliant, then Vue can't be used.

Could we (developers) please have some references where the design-decision are coming from?
(and yes, it feels a bit odd to "discuss" this on some closed issue ...)