Non-Standard Attributes on HTML Tags. Good Thing? Bad Thing? Your Thoughts?

Question

HTML (or maybe just XHTML?) is relatively strict when it comes to non-standard attributes on tags. If they aren't part of the spec, then your code is considered non-compliant.

Non-standard attributes can be fairly useful for passing along meta-data to Javascript however. For instance, if a link is suppose to show a popup, you can set the name of the popup in an attribute:

<a href="#null" class="popup" title="See the Popup!" 
   popup_title="Title for My Popup">click me</a>

Alternatively, you can store the title for the popup in a hidden element, like a span:

<style>
    .popup .title { display: none; }
</style>
<a href="#null" title="See the Popup!" class="popup">
    click me
    <span class="title">Title for My Popup</span>
</a>

I am torn however as to which should be a preferred method. The first method is more concise and, I'm guessing, doesn't screw with search engines and screen readers as much. Conversely, the second option makes storing large amounts of data easier and is thus, more versatile. It is also standards compliant.

I am curious what this communities thoughts are. How do you handle a situation like this? Does the simplicity of the first method outweigh the potential downsides (if there are any)?

Macklin

These are called "expando" attributes - if you want to go learn more about them. – Aquamanile

AFAIK, expando attributes are set at runtime using javascript. They're not part of the XHTML itself – Gigantism

Answer 1

I am a big fan of the proposed HTML 5 solution (data- prefixed attributes). Edit: I'd add that there are probably better examples for the use of custom attributes. For instance, data that a custom application will use that have no analogue in standard attributes (eg. customization for event handlers based on something that can't necessarily be expressed in a className or id).

Wistrup

I tend to follow this solution now - even though it isn't standards compliant. – Trichoid

I've always avoided this, since it doesn't validate. But now that I think about it, cramming everything in a class="" attribute (like jquery metadata) isn't necessarily any better. Are there any practical, real-world disadvantages to this method in <HTML5 land? Basically - what problems will arise now? Seems like it's not ideal, but has no side effects I can think of. – Chilblain

@Rocketmonkeys I'm not sure, but I think using data inside a class attribute, may force the browser to try apply undefined css rules to a element, this can cause some issues or performance issue. Again I'm not sure. – Michellmichella

@Vitim.us, if there is such a performance hit, it would be negligible. Browsers are pretty efficient at that sort of thing; the hit for actually applying styles would be greater. And remember, classes are not something invented for the purpose of styling, they're just element data like any other attribute. Any attribute can be used in a selector, so if there's such a performance hit it would apply to literally any attribute (including data- prefixed) you add to the element. – Wistrup

@Wistrup that's a good argument, I have to agree, even I rather use properly data structure inside Javascript I found some cases that using data attribute is suitable. I avoid jquery like rocketmonkeys said. I really need to stop bothering people about micro optimizations. – Michellmichella

I use both data attributes and custom actual DOM attributes depending on the purpose and use of those attributes. For actual data, data attributes are acceptable to me. For non-data "functional effects", I use actual attributes. Example: <button icon="hamburger"> with CSS matching [icon] consuming that icon to apply in ::after. An icon does not qualify as "data". Similar: the actual HTML attribute "hidden" gets overlooked. Abuse of CSS classes (icon_hamburger or weirder examples such as offset-x-20 where values get baked into the class name) I find, well, rather horrific. ;) – Blaspheme

Answer 2

Custom attributes provide a convenient way to carry extra data to the client side. Dojo Toolkit is doing this regularly and it has been pointed (Debunking Dojo Toolkit Myths) out that:

Custom attributes have always been valid HTML, they just don’t validate when tested against a DTD. [...] The HTML specification states that any attribute not recognized is to be ignored by the HTML rendering engine in user agents, and Dojo optionally takes advantage of this to improve ease of development.

Niall

Answer 3

Another option would be to define something like this in Javascript:

<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>

Then you can use this later in your Javascript code, assuming your link has an ID that corresponds to the ID in this hashtable.

It doesn't have the disadvantages of the other two methods: no non-standard attributes nor the ugly hidden span.

The disadvantage is that it might a bit of an overkill for things as simple as your example. But for more complex scenarios, where you have more data to pass, it's a good choice. Especially considering that the data is being passed as JSON, so you can pass complex objects with ease.

Also, you keep data separate from the formatting, which is a good thing for maintainability.

You can even have something like this (which you can't really do with the other methods):

var poi_types = {1: "City", 2: "Restaurant"};
var poi = {1: {lat: X, lng: Y, name: "Beijing", type: 1}, 2: {lat: A, lng: B, name: "Hatsune", type: 2}};

...

<a id="poi-2" href="/poi/2/">Hatsune</a>

And since you most probably use some server-side programming language, this hash table should be trivial to generate dynamically (just serialize it to JSON and spit it in the header section of the page).

Dripstone

Answer 4

Well in this case, the optimal solution is

<a href="#" alt="" title="Title of My Pop-up">click</a>

and using title attribute.

Sometimes I break the spec if I really need it. But rarely, and only for good reason.

EDIT: Not sure why the -1, but I was pointing out that sometimes you think you need to break spec, when you don't.

Imprecate

Answer 5

Why not declaring the popup_title attribute in a custom DTD ? This solves the problem with validation. I do this with every non-standard elements, attributes and values and thank this validation shows me only real problems with my code. This makes also any browser errors less possible with such HTML.

Departure

Answer 6

You could nest hidden input elements INSIDE the anchor element

<a id="anchor_id">
  <input type="hidden" class="articleid" value="5">
  Link text here
</a>

Then you can easily pull the data out by

$('#anchor_id .articleid').val()

Arraign

Yes, but the best way is to use: <input type="hidden" title="article_id" value="5" />. Since the class is something for CSS, giving in fact invalid code if the class is not in the style information. Even if JS or CSS is turned off the data will stay hidden. – Scaife

@Yeti, class is not something for CSS nor invalid if it doesn't appear in the styles. It's just data on the element, like any other attribute. The association with CSS is that it's a well-supported selector. – Wistrup

Answer 7

My solution in the end was to hide additional data in the id tag separated by some sort of delimiter (one underscore is a space, two is the end of that arg), the second arg there is an id:

<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>

Ugly, and it assumes you're not already using the id tag for something else, but it is compliant across every browser.

Dugald

Answer 8

My personal feeling in your example is that the span route is more appropriate, as it meets the standards of the XHTML specification. However, i can see an argment for custom attributes, but I think they add a level of confusion that isn't needed.

Concurrent

The SPAN route is a misuse of the tag, though. It may meet the validation standards, but it does not meet the semantic standards. – Pharmacist

Answer 9

I've been racking my brain over this as well. I like the readability of non-standard attributes, but I don't like that it will break standard. The hidden span example is compliant, but it is not very readable. What about this:

<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>

Here the code is very readable, because of JSON's key/value pair notation. You can tell that this is meta data that belongs link just by looking at it. The only flaw I can see beside hijacking the "rel" attribute is that this would get messy for complex objects. I really like that idea of "data-" prefixed attributes mentioned above. Do any current browsers support this?

Here is something else to think about. How much impact does not compliant code have on SEO?

Minnesinger

The rel attribute describes the relationship between the current page and the linked resource. It isn't a generic "Store whatever data you like" attribute. So this is horrible. – Auriga

Do any current browsers support this? -- What is there to support? Browsers can already tolerate non compliant code. Considering that this is part of the new HTML5, there's nothing to be afraid about adding the data- attribute just like you would add any other custom attribute. – Redden