HTML and CSS Reference
In-Depth Information
tabbed containers. Using one of these libraries, you declare an element
to be a tab control like this:
<div dojoType="dijit.layout.TabContainer">
<div dojoType="dijit.layout.ContentPane" title="My first tab">
Lorem ipsum and all around...
</div>
<div dojoType="dijit.layout.ContentPane" title="My second tab">
Lorem ipsum and all around - second...
</div>
<div dojoType="dijit.layout.ContentPane" title="My last tab">
Lorem ipsum and all around - last...
</div>
</div>
A browser, as with HTML elements, will parse the attribute, even
though it doesn't recognize it, and add it to the DOM . The Dijit library
will run when the page has loaded, search for these attributes, and run
the appropriate JavaScript to enable the advanced control.
It may seem as though everyone has been getting along fine with creat-
ing their own attributes, so why add support for custom attributes to
HTML5 ? Well, for one thing, creating your own will stop your markup
from validating.
Failing validation may not bother you too much, but if you're looking
for that one unintended mistake, having to sift through many intended
ones should be unnecessary. Plus there's a risk that the attribute names
chosen by the widget libraries will be used in future versions of HTML
after all, one of the goals of the spec is to codify existing common uses.
The HTML5 solution to both the validation and potential name-clash
issues is the data-* attribute collection. The * is a wildcard—that is, it
can be whatever you want it to be. But anything starting with data- will
be allowed through the validator, and you're guaranteed that no data-*
attributes will be made part of HTML .
The data-* attributes allow you to add information to your page
for your own personal use. If your goal is to share information
with other websites, you should instead use microdata.
Search WWH ::




Custom Search