The HTML5 spec define how to set custom attributes using data-* prefix,
like:
<div data-attr="somedata"></div>
But what would be the difference if we write just:
<div attr="somedata"></div>
And I actually prefer the second way since it's shorter.
I can access both attributes using the getAttribute() method.
So is that wrong not using data-* prefix? I tested it only on chrome and IE11, so maybe there are other browsers to worry about?
HTML5 defines the data-* attributes as valid, while other custom attributes are not. So what?
If you run your code through an HTML validator it will look for invalid attributes. Among other things, they could indicate a typo. An HTML5 validator will accept data-* attributes but it isn’t psychic. It has no way of judging which other new attributes are part of the plan.
If you create a new attribute, it may not play nicely with future changes in HTML which may coincidentally use the same attribute name for a different purpose. The data-* attributes are exempt from future implementation.
A corollary of the above is that including additional libraries which also make arbitrary changes may interfere with your own code.
JavaScript cooperates with the data-* attributes by automatically collecting them in a dataset property for each element. If you make up another attribute it won’t be included.
If none of the above points are important to you, then, by all means, use whatever attribute names you like. As regards the last point above, you can always access your own arbitrary attributes using JavaScript’s *Attribute functions which will work just well on any attribute, regardless of its validity.
Speaking of JavaScript, there is no concept of HTML validity for JavaScript, and you can use JavaScript to assign any attribute names you like without fear of the HTML validator police knocking at your door. However, you still run the risk of competing with additional libraries or future implementations.
Related
I've recently found on one of the sites opening tag like this:
<script data-ip="93.1xx.3.2x" data-backuri="something.com">
And I couldn't find any information about it. What are those tags used for?
data-* attributes are custom HTML attributes.
Basically, there are standard HTML attributes like style, src, width, height, class... and these have a special meaning to browsers and are 'reserved'.
However, custom attributes have no special meaning generally and are only special to the owner's application. They can be used to simplify an application's logic.
Using data- before your attribute name ensures that future standard attributes will not use your current attribute. For example, imagine today you are using a sound attribute but then the HTML standard adds a sound attribute meaning something other than what you meant. Had you used data-sound, you would have been fine because there would be no conflict. The specification says no future standard browser attributes will start with data-.
See jquery get HTML 5 Data Attributes with hyphens and Case Sensitivity for some useful info on why we use data-* attributes.
Also, see MDN docs for some useful information.
Okey, so, recently, i found this: https://angularjs.org/
I noticed that they use custom attribute prefix "ng-"
From articles, like:
http://html5doctor.com/html5-custom-data-attributes/
or even stackoverflow:
https://stackoverflow.com/a/17091848/2803917
And there are many more, the only VALID (im not talking about the fact, that they work anyways) prefix to use is "data-".
So, could someone explain to me, how can it be, that these, million projects and companies, uses an invalid prefix for custom html element attributes and no one seems to care?
Or am i missing something?
I would really appreciate some thoughts, or even sources of info, not just texts like "everyone does it" and "don't bother and leave it".
This is an old question, but the following may be helpful.
In principle, you can create any attributes you want, though you can’t expect the browser to know what to do with them. This is true both in HTML:
<p thing="whatever" … </p>
and in JavaScript
// p = some element
p.setAttribute('thing','whatever');
You can expect CSS to take your custom attribute seriously, as long as you use the attribute selector:
…[thing] {
…
}
Of course, if you start making up your own attributes, you run into three problems:
An HTML validator won’t know whether your new attribute is deliberate or an error, and will assume that it’s incorrect
You are competing with other code which is also making up its own attributes
At some point in the future it’s possible that your made-up attribute name becomes a real-life attribute, which would cause further problems
The data- attribute prefix has three benefits:
HTML validators will ignore the attribute for validation purposes
JavaScript will gather these attributes into a special data object for easy access
You don’t run the risk of competing with real attribute names
Effectively the data- prefix allows you to work with an otherwise invalid attribute by telling the validator to overlook it.
This will not solve the problem of competing attribute names, so you’re pretty much on your own. However it is common practice to at least include a prefix specific to a library.
Finally to the question of being valid.
If, by valid, you mean will it pass a standard (modern) HTML validator, the answer, is only the data- attributes will work this way. If, on the other hand, you mean will it work, then both CSS and JavaScript will happily work with other made up attributes, as long as you don’t expect the browser to guess what you mean.
Custom attributes must start with data- or x- or they are invalid.
This might cause problems in future browsers, and HTML validators will say they're invalid.
See: What is the difference between ng-app and data-ng-app?
And: http://www.w3.org/TR/2011/WD-html5-20110525/elements.html#embedding-custom-non-visible-data-with-the-data-attributes
Official W3C validator does not consider ng-customattr or x-customattr attributes, or customattr as valid.
Statement, that even data- prefixed custom attributes are invalid are false, check this W3C specification
However it is worth to notice projects like Laravel's Dusk encourage developers to use custom, non data- prefixed attributes.
It is worth noting, that official W3C specifications are not exclusive way how to build HTML page, but rather reccommended ones. I would dare to say, there are unspoken standards, which are widely used on web and yet tolerated by all the major browsers, even though they are not mentioned in w3c specifications. According to this article, custom named html attributes are disregarded, but yet still accessible, therefore a viable option.
I afraid there is no firm ground below our feet - By naming your parameter prefixed by data-, you are doing things by reccomended way - avoiding possible deprecation warnings, or another issues, if browsers will be in future more strict. However standards can change, and since custom-way named attributes are widespread over the web, they can became standard themselves.
So whats the solution?
If you really want to use custom, non data- prefixed attributes in HTML, it would be good to make a research about general browser support (Of find someone who already did this and published his research results in some article), and make your decision based on that - just like with any other HTML/CSS/JS feature.
According to many recent HTML specs, when we are using custom attributes (meaning any attributes not defined in the spec), we should prefix them with data-. However, I see no reason to have to do this (unless you require perfectly valid HTML, obviously). Pretty much all current browsers correctly ignore custom attributes, meaning no conflicts except with identically-named attributes from others' code, and we can ignore even this with custom prefixes or something similar (as suggested on the AngularJS directive page). What, if any, other benefits are there? This question has been asked before, at least twice, but both are pretty old.
I forget where I read it, but some guide said custom HTML tags need dashes, and single-word tags aren't valid. First of all, why? Second, should we do this, and why (besides being valid)? Would there be any problem with underscores or camelCase, etc.? Also, conflicts with existing elements shouldn't be a problem, if, like with data attributes, you prefix or suffix them, etc. See the Angular directive page again.
I'm sure all these questions have been asked before, but I'm combining them into one. Is that a good idea (quick, someone ask on Meta)?
The data-* attributes have two advantages:
It is a convention meaning other programmers will understand quickly that it is a custom attribute.
You get a DOM Javascript API for free: HTMLElement.dataset. If you use jQuery, it leverages this to populates the keys and values you find with .data().
The reason for the - in custom element names is for two basic reasons:
It is a quick way for the HTML parser to know it is a custom element instead of a standard element.
You don't run into the issue of a new standard element being added with the same name which would cause conflict if you register a custom Javascript prototype for the DOM element.
Should you use your own custom element name? Right now it is so new that don't expect it to be fully supported. Let's say it does work. You have to balance the issue of the extra complexity with the benefit. If you can get away with a classname, then use a classname. But if you need a whole new element with a custom Javascript DOM prototype for the element, then you may have a valid usage of it.
Say I wrote a custom gravatar directive in AngularJS that is bound to an email property on the scope. The directive would replace this HTML …
<gravatar email="user.email" />
by a common img tag whose src attribute is set to the correct Gravatar url:
<img src="http://gravatar.com/avatar/..." />
My question might be a little broad or even naïve, but "how bad" is it to initially have the <gravatar /> tag in my page's HTML? Are there any "real-world" consequences besides not passing W3C validation?
The W3C says
Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose, as doing so prevents software from correctly processing the page.
and
Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future.
http://www.w3.org/html/wg/drafts/html/master/dom.html#elements
Custom elements/attributes have no semantic value and should be avoided for these reasons.
There probably won't be any direct consequences that you will even notice. After all, Angular itself uses the non-confirming ng attributes (although they do support with the data- prefix as well).
The only possible problem you may face is if the element you introduce that is currently a custom element becomes part of the spec and has different behavior than what you were expecting before, but I think that is highly unlikely. Even so, I would avoid using anything custom if I could.
Eventually you will be able to register your own custom elements, but from what I can tell no browser supports this spec yet.
While the initial source of the page body (before angular processes an ng-app element) may not adhere to the W3C standards, if you use "replace: true" in directives, custom elements are replaced by a template HTML, which can be valid. So, in this case, you can think about an angular element as just a placeholder that is replaced with the terminal HTML output.
I know that data- Attributes is part of HTML 5. It seems to be a good choice to use it to serialize some data in markup. So there are people using data-bind="xxx" . But can I just use bind="xxx". It seems violate schema, of specification, but practically it works in all browser. So my question is, what is the practical reason (not in theory) like performance that I should not use customs attribute just like bind="xxx". I know bind attribute is not reserved attribute.
Thanks
Practically, some browser can implement bind with a totally different meaning.
You're using it for Knockout, but hypothetically the new meaning is different. When you change the inline CSS on one element, it should change it on another element based on a selector in the bind attribute.
There's a reason to respect standards and use private (e.g. data-) or vendor-specific prefixes.
I know this question is old but I had the same question as Fred. I found the answer and I wanted to share it. There is no practical reason not to use an arbitrary attribute name other than what was mentioned in another answer. That is a vendor or browser maker may decide to use the name for something else.
It is however not allowed in the spec, kind-of, while the spec does read that arbitrary attribute names should not be used, there is nothing preventing their use. This is like the US Code for Displaying a flag, it's a set of rules but no way to enforce it.
Contrast this to a rule that is enforced such as a single body tag within an html document, etc. and you can realize that there is nothing enforcing using arbitrary names for attributes.
So what remains is why should you not use arbitrary attribute names? Since it will not pass the W3 html validator, it can be argued that societal pressure may increase to the point that your code will not be acceptable. For example, SEO may suffer, a future employer may not like sloppy code, etc.
I certainly became embarrassed as I make liberal use of arbitrary attribute names to pass data. Something that I will stop immediately. I am now convinced that using the data-* attribute will make my code easier to read, easier to maintain and clean enough for peer review.