Что такое product data name. Как использовать data-атрибуты HTML5

Prefixing the custom attributes with data- ensures that they will be completely ignored by the user agent. As far as the browser and indeed the website’s end user are concerned, this data does not exist.

The spec says (emphasis ours):

Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.

These attributes are not intended for use by software that is independent of the site that uses the attributes.

Every HTML element may have any number of custom data attributes specified, with any value.

As custom data attributes are valid HTML 5, they can be used in any browser that supports HTML 5 doctypes. Thankfully, this is pretty much all of them. In addition to aiding backwards compatibility, this also ensures that custom data attributes will remain a scalable, cross-platform solution well into the future.

Now that we have a broad understanding of what data attributes are, let"s take a look at how they can be used:

• To store the initial height or opacity of an element which might be required in later JavaScript animation calculations
• To store parameters for a Flash movie that’s loaded via JavaScript
• To store custom web analytics tagging data as demonstrated by Jason Karns
• To store data about the health, ammo, or lives of an element in a JavaScript game
• To power accessible JavaScript subtitles as demonstrated by Bruce Lawson

Although flexible, data attributes aren’t an appropriate solution for all problems.

• Data attributes should not be used if there is a existing attribute or element which is more appropriate for storing your data. For example, date/time data should probably be presented semantically in a time element instead rather than stored in custom data attributes.
• Custom data attributes are not intended to compete with microformats. It is clearly stated in the spec that the data is not intended to be publicly usable. External software should not interact with it. Marking up contact details or event details using custom data attributes would be wrong, unless of course it is only intended to be used by your own internal scripts.
• The presence/absence of a particular data attribute should not be used as a CSS hook for any styling. Doing so would suggest that the data you are storing is of immediate importance to the user and should be marked up in a more semantic and accessible manner.

Now that we understand what custom data- attributes are and when we can use them, we should probably take a look at how we can interact with them using JavaScript.

If we wanted to retrieve or update these attributes using existing, native JavaScript, then we can do so using the getAttribute and setAttribute methods as shown below:

// "Getting" data-attributes using getAttribute var plant = document.getElementById("strawberry-plant"); var fruitCount = plant.getAttribute("data-fruit"); // fruitCount = "12" // "Setting" data-attributes using setAttribute plant.setAttribute("data-fruit","7"); // Pesky birds

This method will work in all modern browsers, but it is not how data- attributes are intended to be used. The second (new and improved) way to achieve the same thing is by accessing an element’s dataset property. This dataset property - part of the new HTML 5 JavaScript API s - will return a DOMStringMap object of all the selected element"s data- attributes. When using this approach, rather than using the full attribute name, you can ditch the data- prefix and refer to the custom data directly using the name you have assigned to it. Data attribute names which contain hyphens will be stripped of their hyphens and converted to CamelCase .

// "Getting" data-attributes using dataset var plant = document.getElementById("sunflower"); var leaves = plant.dataset.leaves; // leaves = 47; // "Setting" data-attributes using dataset var tallness = plant.dataset.plantHeight; // "plant-height" -> "plantHeight" plant.dataset.plantHeight = "3.6m"; // Cracking fertiliser

If, at some point in your script, a specific data- attribute becomes redundant and is no longer needed, it is also possible to completely remove that attribute from the DOM element by setting it to a value of null .

Plant.dataset.leaves = null; // Caterpillars attack!

Unfortunately, the new dataset property has not yet been implemented in any browser, so in the meantime it’s best to use getAttribute and setAttribute as demonstrated earlier.

While developing your application, you may find it useful to be able to select elements based on the presence of - or indeed the specific values of - their custom data- attributes. This can be achieved quickly and easily using querySelectorAll as shown below:

// Select all elements with a "data-flowering" attribute document.querySelectorAll(""); // Select all elements with red leaves document.querySelectorAll("");

As data attributes become more widely used, the potential for clashes in naming conventions becomes much greater. If you use an unimaginative attribute name such as data-height , then it is likely you will eventually come across a library or plugin that uses the same attribute name. Multiple scripts getting and setting a common data- attribute will probably cause chaos. In order to avoid this, I encourage people to choose a standard string (perhaps the site/plugin name) to prefix all their data- attributes - e.g. data-html5doctor-height or data-my-plugin-height .

Custom data- attributes are a great way to simplify the storage of application data in your web pages. Although you can’t utilise the new JavaScript API s just yet, you can enjoy great success using getAttribute and setAttribute safe in the knowledge that they will work in all major browsers.

If you’re super keen to have a play with the new dataset property but disappointed that it hasn’t been implemented, fear not!, for there is a light at the end of the tunnel. You might be interested in looking at Dr Remy’s experimental code , which partially enables the dataset functionality in some browsers by editing the Element.prototype .

The code supports the retrieval of data- attributes in the latest versions of Firefox, Safari, Opera, and Chrome, but sadly will not work in any version of IE (since IE does not expose the Element object). This code also partially supports the setting of data attributes, but it will only store the new attribute values within the JavaScript and will not update the DOM element as a full, native implementation of the dataset property would. Although this code is mainly a proof of concept, it may be useful for mobile application or intranet development in closed environments where cross-browser (IE) compatibility is not an issue.

• Category

I firmly do not see why it is inappropriate to use custom data attributes for external applications provided that these external applications are not a requirement for viewing the page.

I don’t understand why this article quotes the part of the spec saying data-* attributes are site-specific, and then gives a warning promoting namespacing. If you follow the spec, you’re creating all of the attribute names, so there’s zero reason for namespacing. That’s exactly why that’s in the spec.

@Scott – the namespacing isn’t to create “site-specific” data attributes, but in-application namespacing.

For example (and IIRC the spec mentions this) a widget’s controls (like a tree view) may have data attributes, but the data attributes may have been created using a specific library, such as jQuery or Dojo – so to avoid data attribute collisions the application module may want to namespace it.

I can’t see where Chris referred to the data attribute being site-specific (but it’s late and I may have missed it).

There’s a lot of cases where you won’t want or need to use namespacing, but there are some cases where it makes sense. But since this just builds on existing content attributes rules – you’re free to decide how you use them.

I’m using the data-* with getAttribute and setAttribute since I saw a post about that 2 years ago by Jon Resig, so I can confirm that this way of using it works for all browsers/platforms, starting with IE6.
I just hope that any browser implementing data-* natively won’t break the getAttribute method (it shouldnt but we never know)

From a performance point of view, accessing the DOM via getAttribute() is obviously slower than accessing to a JS variable, event stored in an array, so the use case you give of a JS game using it to store values will probably never happen: developers will use it to transmit info from server to client, but once the DOM has been harvested, it’s best to keep all the values in JS for quicker access

@jpvincent – Yeah, I totally agree with you.

I guess the initial health and ammo data could be stored in a database and using a data-attribute would be a valid mechanism to transfer this information to the game’s javascript. But once this initialisation task is complete there is very little point in continuing to make costly DOM updates with the latest health/ammo stats.

Thanks for your comment.

Your article mentions that you shouldn’t use data-* for CSS hooks. What if the data-* attribute was used in the JS but you also wanted to apply styles to it. Wouldn’t it make sense to target the attribute rather than add a secondary class.

Take this form for example:

Title *is required

Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

data-field_type=”text” could be used for both validation and styling layout.

Pretty cool feature, although no browsers support it yet. This little bit of code works to add support for the dataset property to any browser that supports __defineGetter__. I wrote it before I realized you linked some code that does pretty much the same thing. My code, on the other hand, has support for actually udpating the attribute values, but it does not support adding new attributes.

Element.prototype.__defineGetter__(‘dataset’, function(){
var dataset = {};
for (var i=0, l=this.attributes.length; i