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.
Related
AddThis uses a notation which seems to extend the parameters available in an HTML div tag.
The tag that contains the button array can include additional parameters such as:
<div addthis:url="someUrl"> </div>
Along with defining some css classes for the element seems to give their JavaScript code access to manipulate this element AND read the value of the additional addthis: parameter.
I'd like to implement something similar myself but am confused as to how to correctly allow additional parameters in the standard HTML tags.
I've also seen the AddThis code throw W3C validation errors sometimes so wonder if this is entirely legitimate.
Searching around I've found some discussions about extending the HTML tags via extending the prototypes in JavaScript but everything I've read seems to be about adding new events etc.
This addthis:url notation looks more 'schema'-like to me, or am I on completely the wrong track?
I've made some progress on this, at least functionally, but what I have now breaks the HTML validation quite seriously.
To explain a little further what I am trying to achieve...
In the same way that AddThis allows you to include their sharing elements by adding a simple <DIV> tag to your page and including some JavaScript, I want to provide similar functionality with <IMG> tags.
Someone wanting to use this functionality will include an <IMG> tag that has some additional name=value pairs that are outside of the standard image tags attribute and are defined by my spec.
The JavaScript that is included will then read these additional attributes and perform some actions on the image tags.
To this end I have the following:
<IMG id="first image" class="imageThatCanBeWorkedOn" src="holding.png"
my-API-name:attribute1="some data"
my-API-name:attribute2="some other data">
I then use `getAttribute('my-API-name:attribute1') to access the additional tag data from JavaScript.
(I'm selecting all of the tags with a particular class name into an array and then processing each tag in turn, in case anyone is interested.)
This all works great - I can manipulate the <IMG> tags as needed based on the additional data, BUT the markup is not valid HTML according to the W3C validator.
With the above I get:
Warning Attribute my-API-name:attribute1 is not serializable as XML 1.0.
Warning Attribute my-API-name:attribute2 is not serializable as XML 1.0.
Error: Attribute my-API-name:attribute1 not allowed on element img at this point.
Error: Attribute my-API-name:attribute2 not allowed on element img at this point.
If I remove the : from the attribute name (eg my-API-name-attribute2) the 'not serializable' warnings disappear but I still get the 'not allowed' errors.
So how would I add these additional bits of data to an <IMG> tag and not invalidate the markup but while maintaining a level of clarity/branding by including the 'my-API-name' part in the way that AddThis does?
(I note from the comments that I could use data- attributes. I haven't tried these yet, but I'd prefer to be able to do this in the 'branded' way that AddThis seems to have managed without breaking their users' markup.)
If we were talking about XML (which includes XHTML) it'd be a namespace prefix. In HTML5 it's just a regular attribute:
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 GREATER-THAN SIGN (>), U+002F SOLIDUS (/), and
U+003D EQUALS SIGN (=) characters, the control characters, and any
characters that are not defined by Unicode.
... though slightly harder to manipulate (not too much, though) and totally non-standard.
I'd like to implement something similar myself but am confused as to
how to correctly allow additional parameters in the standard HTML
tags.
Before HTML5, some web developers deployed a technique of adding custom data to an element's class attribute (or to any other attribute which will happily attach itself to any element).
This worked, but it was self-evidently a hack.
For this reason HTML5 introduced custom data-* attributes as the standard approach to extending an element's attributes - and data-* is precisely what you should be deploying.
So how would I add these additional bits of data to an tag and
not invalidate the markup but while maintaining a level of
clarity/branding by including the 'my-API-name' part in the way that
AddThis does?
<img id="first image" class="imageThatCanBeWorkedOn" src="holding.png"
data-myAPIName_attribute1="some data"
data-myAPIName_attribute2="some other data" />
Further Reading:
Time Travel back to 2010: http://html5doctor.com/html5-custom-data-attributes/
Time Travel back to 2008: http://ejohn.org/blog/html-5-data-attributes/
In HTML, all elements share a set of global attributes, like class, id, the data- specification, a common set of Javascript events and a couple of things here and there.
But how about SVG? I'm trying to build a trait in PHP able to represent the very core of a SVG element (so I can build every SVG object with this core set of attributes and add the specific attributes for that object in its own declaration).
The SVG section in the Mozilla Developer Network has a full-blown page with lots of attributes, but the only core attributes, according to their documentation, are id, xml:base, xml:lang, xml:space
I see the class attribute is on the navigation links, but not referred in the attributes category section, which confuses me a lot.
Isn't the class attribute a global one like in HTML? And what about the Javascript events?
The class attribute is not global feFuncA doesn't have it for instance, nor does that element support javascript events. There are others.
Attributes are listed here in a list that shows which elements support them.
I'm doing this mainly to store data inside tags as I echo it out of php, and then using jQuery to $(..).attr('my_att') to retrieve it.
It hasn't caused any problems so far, but are there good reasons (other than it's not valid) why we shouldn't do this?
Because you can use valid custom attributes instead:
<div data-customer-id="3" class="customer"> [...] </div>
If you prefix your attributes with data- they are valid HTML. The reason for not just writing your own attributes is that they can wind up inheriting meaning in the future. Obviously this is unlikely for some cases (like "customer-name"), but using the prefix is safter.
Another added benefit is that you are very clear about your intentions; another developer isn't going to come by and think you meant to write kind="text" rather than type="text" when you were trying to mark the model associated with a particular input field.
I prefer to do that sort of thing as HTML5 data attributes.
Then you can use jQuery.data() to get at the attributes if you're in a browser that doesn't support data attributes natively.
For example:
<a href="#" id="MyLink" data-address="1600 Pennsylvania Ave, Washington, DC">
My Address
</a>
Then I can do $('#MyLink').data('address') to get the value back.
I see mainly two reasons to avoid using custom attributes :
1° If the browser is really strict about the HTML standard, he can simply refuse to show a page which don't comply to the DTD or worse, crash trying to display your page.
2° The browser can choose to strip unknown attribute from the element.
Sure, actually, no browser do either of these things, but who can say what new implementations will do in the future ?
Standards are developed for a reason, and it's always a good idea to follow them. Especially when HTML5 let you create custom attributes so easily.
I've got some java script code that implements a kind of slide show. It uses a series of img tags as a table to control its actions. I probably used some code I found some where as a basis. Anyway, the img tags contain a data-img attribute which I can't find in any definition of the img tag. Now I find I need to add more data to the img tags. So my questions are:
1) Is the data-img actually a real attribute or something adhoc?
2) Can I invent yet more attributes?
3) What is the danger of using such attributes?
1) It's valid in HTML 5; it is an invalid attribute (that will, as far as I know, still work in all browsers, it but will break validation) in HTML 4
2) As far as I am aware, you can add arbitrary attributes and query them in Javascript, but chances are those attributes will not survive certain DOM manipulation and other operations where the browser creates markup - it's possible the invalid attributes will simply be dropped
3) Your pages will no longer validate.
Background: Custom attributes - Yay or nay?
Depends on implementation.
YES, its often quite useful to do so.
If created in #2, not really, no, they are part of the DOM at that point, i know of no browser that removes attributes.
They are a valid HTML5 attributes.
If you need to add and get that data only with javascript for client side without communicating with the server side you can implement a store and retrieve mechanism similar to the one used by Mootools.
It doesn't pollute the DOM and store also javascript objects.
Just to be sure it can be safely used with JQuery scripting.
It's part of the HTML 4.01 Specification and should only be used as an attribute of the a and link tag (see the spec). Within a and link tags, it's well supported.
According to the HTML 4.01 specification, rel is only valid on a and link elements.
As browsers don't validate documents you can get away with using it on any element you like, but it won't be valid, and it will be semantically meaningless.
You'd really need to expand on what you mean by "compatible with all browsers". All browsers will be able to render a document containing rel attributes without barfing, even if they don't explicitly understand what it means. However, if you want to know whether all major browsers would take an explicit action when they encounter a rel attribute, you'd need to specify what situation you're thinking of and what you hope the browsers would do.
As for being compatible with all tags - no, the rel attribute is only appropriate for A and LINK tags in HTML 4 (as per the spec).
If you want to store custom data, you're better off using custom attributes. If you prefix them with "data-" then they are valid html5 as well.
See: http://ajaxian.com/archives/embed-your-data-in-html-5