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.
Related
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.
Given current HTML5 specs that allows creating custom HTML elements (as long as their name contains a dash), and the fact that Web Components seem to be a feature that's here to stay, I'd like to know why is creating your own custom HTML elements frowned upon?
Note, that I'm not asking whether to use Web Components - which are still a moving target, and even with great polyfills like Polymer might not be ready for production yet. I'm asking about creating your own custom HTML tags and styling them, without attaching any JS APIs to them.
Short answer: I haven't heard any very compelling reasons to avoid them.
However, here are some recurring arguments I've heard made:
Doesn't work in old IE (just document.createElement("my-tag"); should fix that).
Global namespace clashes (same applies to class names, and custom elements in general).
CSS selector performance (doh, this is just about the last thing you should worry about).
Separation of functionality, meaning and presentation. This is actually the only argument I've heard that IMHO has any valid basis to it. You're of course better off with semantic HTML (search engines and all that), but if you were going to use a div for it otherwise, I don't see why you couldn't use a custom tag instead.
One of the arguments against custom tags is their implied incompatibility with screen readers. This issue can be resolved with WAI-ARIA attributes.
There exists an issue in IE11, which breaks table layout if a custom element without display property is inserted inside a table cell. Check the plunker code. Therefore, it's the safest to declare all new elements explicitly, for example like so:
new-element {
display: block;
}
I am seeing some attribute I have never seen before in a div tag. I haven't touch html for a while but googling the attribute didn't return much useful info.
<div dataquery="#item_1306" comp="box.components.Flashplayer" id="box_Flashplayer_2" propertyquery="#box_Flashplaye_2" class="box_Flashplaye_style2"...
My question is, do you know what are these "dataquery" "comp" and "propertyquery" attributes?
Thanks alot folks.
HTML is often enhanced with custom attributes these days, and HTML5 explicitly allows for that. Normally these attributes should be prefixed with "data-", but obviously this is not the case here.
The meaning depends most probably on a script included in the page.
For example, in twitter bootstrap it is common to see attributes like <body data-spy='scroll'> which is than interpreted by a script and allows for monitoring the amount a user scrolls.
When including Facebook like buttons you may have attributes like data-style which controls whether a box, or a button, or hwatever is used.
You can add you own attributes to elements. I don't think theese atributes are standard attributes lika class and name but an attribute that the programmer has added self for some purpose.
Those are not W3C attributes, they have used to perform some task, may be to the lagulage it used and may performance some special tags, But its not best practice because it gives HTML validation errors, better thing is use data-xxxx tag for extra attributes.
More readings.
http://www.javascriptkit.com/dhtmltutors/customattributes.shtml
http://ejohn.org/blog/html-5-data-attributes/
http://html5doctor.com/html5-custom-data-attributes/
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.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Custom attributes - Yay or nay?
Is it appropriate to create custom attributes for HTML elements as so:
<input type='text' value='name' custom_attribute='value'>
This seems a little hacky and I'm not sure if it is supported largely or exactly how it would be accessed via DOM.
Check out html5 data atrributes.
Mr Resig explains more
A new feature being introduced in HTML
5 is the addition of custom data
attributes. This is a, seemingly,
bizarre addition to the specification
- but actually provides a number of useful benefits.
It's formally supported by HTML5: http://www.javascriptkit.com/dhtmltutors/customattributes.shtml
Your code will not be valid if the attribute is not in the spec. I suggest looking into storing data on elements using jquery's data storage: http://ejohn.org/apps/workshop/adv-talk/#8
thats DIRRRRRRTY!
it will work, but there is a lot of better and different ways you can achieve the same thing.
you can create a hidden input next to it that holds the desired value.
It does not follow strict guidlines, but you can do it. The Dojo Library uses that technique all over the place.
Good question. I've thought of it as a little hacky. It depends on how it's used. In many cases a hidden field will work instead.
In all cases where I have seen custom attributes use the internals of the system have bled into the html.
The answer to this one might be a bit subjective, but I'll share from my experience. Every browser I've ever used appropriately ignores any extra attributes that aren't part of an HTML spec - even very early versions of IE did this correctly. I've found it a handy technique for DOM manipulation, and recently as a helper for jQuery selectors. However, it's got some drawbacks and should be used sparingly. One of the drawbacks would be if you're using XHTML. In that case, you can't just make up your own stuff - you'd have to have a DTD or XSD that defines the attributes and then reference the schema definition as an XML namespace.
Just as an alternative suggestion... if it feels a little off to you to fake your own attributes, perhaps you might consider assigning a unique ID to your HTML elements using the ID attribute, which is valid on most if not every tag. Then, you can use a javascript dictionary to associate your element IDs with the variables you're trying to embed. The only reason you're using this is for javascript, right? I can't imagine any other reason this technique would be useful.
One more alternative would be to use a hidden tag as another poster suggested and then use jQuery's .next() selector http://api.jquery.com/next/.