I've been using rel to store some non-html information, what other attributes are not commonly used that I can utilize to store information?
You might want to switch to HTML5 and use custom data attributes.
In HTML5 you can define your own data- attributes to store whatever you want.
You can make up your own attributes if you wish. It is probably not a good idea to put data into an attribute if by specification it should have something meaningful in there.
In the HTML 5 spec, you can use data-* attributes; they're guaranteed not to do anything with the browser and they'll work in older browsers, too.
In JavaScript, you can access it with the normal attribute properties:
var value = elem.getAttribute("data-foo")
elem.setAttribute("data-foo", "value")
elem.removeAttribute("data-foo")
With new browsers you can use elem.dataset, but you probably don't want to do that as older browsers won't support it.
var value = elem.dataset.foo;
elem.dataset.foo = "value";
elem.dataset.foo = null;
This help? Scroll down to the rel section:
http://diveintohtml5.ep.io/semantics.html
HTML5 now supports storing information in data-* attributes but thats HTML5 and everyone isn't there yet. So a real world scenario...
If you don't have to worry about persisting across post backs you could map simple data objects as a JSON collection var and pull an object out of it based on a particular key. But that is a broad approach - more information on the overall goal would improve the feedback.
Depends on what kind of information you're looking to store and how are you planning on accessing it. I successfully used both the id and the class attributes to store and access database IDs for example, and even references for some database tables, which I then retrieved with jQuery to do some AJAX requests.
If you are NOT using HTML5, I would advise against using your own custom attributes. Otherwise, like people already suggested before me, have a look at the data- prefixed attributes.
data-* is the way to go if you can use HTML5. You can easily access them in javascript too with elem.data.*
Otherwise, custom attributes are probably better than screwing up the semantics of the page.
Related
Are those data attributes part of hmtl5? Are they used by jQuery? I though data- attributes are generic. Why does one bring up a confirmation box and how does the link be converted to POST when data-method is post?
I have searched for these attributes in the web but could not find anything useful. I just saw those attributes are often mentioned with ruby stuff.
Is there any official documentation?
Update:
I found out know that they are used in Yii2. However, it seems that other (ruby) frameworks using those attributes in the same way (example). That seems to be the reason why I've got the impression that it is part of jQuery or html5.
Are those data attributes part of hmtl5?
Data attributes are. Those specific ones are not. The whole point of data attributes is that they are for custom extensions.
Are they used by jQuery?
Only in the sense that it provides an API to interact with data attributes in general.
I though data- attributes are generic.
They are.
Why does one bring up a confirmation box and how does the link be converted to POST when data-method is post?
Because JavaScript code on the page looks for them.
Is there any official documentation?
The spec.
The data-* attributes is used to store custom data private to the page or application. It's also commonly used in javascript to target certain elements like so $('li[data-confirm="popup"]')
If there is a confirmation box appearing because of an action on this element, it's likely being targeted in the javascript based on the data attribute
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.
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.
I have noticed that the "rel" attribute is not used at all by browsers, does this make it an ideal place to store additional information for javascript (eg a delete ajax request could read the id from rel)
I'm assuming you are looking for a way to store custom data you can use in javascript. I that case:
Storing custom data can be done using data- attributes (see here).
Link 5
Alternatively/additionally you could use jQuery Metadata
I have noticed that the "rel" attribute is not used at all by browsers
You noticed wrong. Browsers do make use of it (e.g. some browsers have a keyboard shortcut to go to the next page and can use the rel attribute to determine that that is). Search engines also make use of it (e.g. nofollow).
does this make it an ideal place to store additional information for javascript
No. Attributes have specified purposes. Don't assume that they aren't going to be used for that.
The problem you'll have is that search engines do make use of the rel attribute. While SEO is not my focus, we often have SEO firms telling us to stick a rel in here and a rel in there... usually rel="nofollow" to prevent giving weight to certain external links.
You could just create your own custom attributes but make sure that you name it currently as to not conflict with other js libraries that you may use.
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/.