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/.
Related
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;
}
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.
This question already has answers here:
What is the difference between ng-app and data-ng-app?
(7 answers)
Closed 8 years ago.
My case happens to be for AngularJS, but really this is a general question.
When using AngularJS, there are features that require custom attributes like ng-repeat for example. The recommendation is to prefix it with data- so "older browsers" won't remove it (where in Angular's case, some functionality would be removed). At what point is that no longer required? IE8? IE9? It doesn't make a lot of difference to add them, but it would be nice to actually know (instead of just doing it blindly) which browsers are requiring it, or better yet, when it's safe to stop adding the prefix.
There are no (at least common) browsers that have an issue with random attributes that don't use the data prefix. Technically, custom attributes are should be prefixed with data in order to be "valid" but in practice, there is no current drawback to leave off the prefix. The spec suggests using the data prefix because it is future proof. For example, if you create an angular directive called mask and use it like so: <div mask></div>, then if HTML6 introduces an attribute called mask, you have a conflict. data-mask, however, is guaranteed to never become a conflict.
While I personally don't care at all if my page validates with an HTML validation tool, the future proof offered by data is appealing.. I have been leaving it off for convenience. In most cases, it probably wouldn't be much work to refactor anything that becomes a conflict in the future - which is very unlikely anyway.
What you may have been thinking of is Angular's usage of custom elements, like if you wanted to use your mask directive as <mask></mask>. In order to make custom elements work in older IE, read here http://docs.angularjs.org/guide/ie.
This question already has answers here:
Using custom HTML Tags
(10 answers)
Closed 9 years ago.
In HTML5, is it OK to use CSS to define your own tags? I know it can generally be looked on as bad practice, but why? And why isn't there an XHTML5 that developers can use?
EDIT===========================================================EDIT
Someone asked how one would define their own tags, so here is an example. Say I wanted to move text to the right by 10 pixels. I have several options: Use a div with a class and change the CSS for that classI could add a class or id to a <li> ectOr, I could create the tag moveright, and put in my CSS: moveright {margin-left:10px;}
In most cases, I would use the div with the class, but if I have to do it many times, I may want to use the last option, to save myself the typing. So, in short laziness. And, someone who loves HTML5, XML, and CSS3!
As of today, no it is not okay to define your own HTML5 tags. The HTML5 spec explicitly forbids it. The reason is to avoid any potential clashes with official HTML5 tags that are added in the future and people's custom tags.
In practice, you can do it; pretty much every browser out there will allow you to do it, and it will work, but you'll be breaking the spec.
However there is a spec amendment going through the works at the moment which is aimed at allowing it. This spec is not finalised yet, but it's already being used by a few people.
The new spec basically says that if you want to define your own tags, it's fine; just add x- to the front of the tag name.
So you would create <x-mytag> rather than simply <mytag>.
I suggest keeping an eye on the W3C specs to see when this is finalised, and whether they make any last minute changes, but for now, I'd run with that.
However, bear in mind that the intended use for this is for creating widgets. In other words, if you're building your own combo-box or tree view control, for example. It is not really intended for just arbitrarily creating new tags in the document flow -- we have classes in HTML already; if all you're doing with the element is basic styling, just use a div with a class.
Hope that helps.
References:
Current spec: http://www.w3.org/html/wg/drafts/html/master/dom.html#elements
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.
Brand new article from HTML5Rocks
This article does a really good job of explaining how to create custom elements that comply with the new spec. Required reading if you want to do this sort of thing.
But be aware of the warning at the top of the article that echos my own in this answer:
Heads up! This article discusses APIs that are not yet fully standardized and still in flux. Be cautious when using experimental APIs in your own projects.
Related question: Are custom elements valid HTML5?
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.