Non-Standard Attributes on HTML Tags. Good Thing?

问题:

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)?

回答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).

回答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.

回答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).

回答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.

回答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.

回答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()

回答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.

回答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.

回答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?