views:

303

answers:

6

This subject turned into a heated discussion at the office, so I'm interested to learn what you think.

We are working on a web app that only targets some specific browsers. These browsers presently include different flavors Opera 9 and Mozilla 1.7.12. In the future we likely also have to support Opera 10 and different flavors of WebKit. But it's very unlikely we are ever going to have to deal with any version of IE.

Our web app declares HTML 4.0 strict in it's doctype.

Recently, I proposed as a solution to a specific problem to use custom attributes in the HTML. I proposed something that would look like this:

<span translationkey="someKey">...</span>

Since this is not valid HTML 4, it did not go down well with our HTML guys, and we got into an argument.

My question is this: What - if any - are the risks of using custom attributes? I know the page won't validate, but don't all browsers just ignore attributes they do not know? Or is it conceivable that some browsers will change to "quirks mode" and render the page as if it was something other than strict HTML 4.0?

Update:

Hilited the actual question posed.

+2  A: 

Duplicate try this thread though: http://stackoverflow.com/questions/439110/is-it-all-right-to-add-custom-html-attributes

Also look at this: http://stackoverflow.com/questions/209428/non-standard-attributes-on-html-tags-good-thing-bad-thing-your-thoughts

JonH
+1 thanks for pointing out these threads
Faisal Vali
+9  A: 

HTML 5 allows custom attributes using a 'data-' prefix, see http://ejohn.org/blog/html-5-data-attributes/

Stuart Dunkeld
I know. Alas, the browsers we need to support do support HTML 5.
KaptajnKold
Then why don't you just introduce an `data-translationkey="someKey"` attribute?
Boldewyn
+9  A: 

If its a goal to maintain valid html4.0 strict, then it doesn't matter why you want to put in custom attributes, you are breaking the goal.

I think the question you need to be asking, is why do you need to break 4.0 strict to get the functionality you want: Anything that you could use a custom attribute for you, you could use a in an existing attribute:

<span translationkey="someKey">...</span>

could be:

<span class="Translationkey@someKey">...</span>

it will be some extra cycles to parse all the class information, but so long as you don't put any css info on that class, it doesn't change display, doesn't put you in quirks mode, and doesn't get you in fights at work.

MikeEL
My view is that it shouldn't be a goal in itself to follow the standard. We are using html4.0 strict because we want to ensure a specifik browser behavior. So my question is really: Do I jeopardize this objective by using custom attributes?
KaptajnKold
great answer, MEL
Hardryv
To answer your question: Custom attribute makes it very convenient to look up the elements in the DOM in MooTools: foo.getElements("[myAttr]") finds all child nodes of foo with attribute myAttr. Using your proposed solution would be a lot more complex and potentially slower.
KaptajnKold
overloading information within the class attribute and then parsing it to extract the correct information and ignore the noise seems inefficient and lacks clarity.
Faisal Vali
+7  A: 

There are no browser limitations/risks. Only the w3 validator will bark, but barking dogs doesn't bite.

The w3 spec says the following:

  • If a user agent encounters an attribute it does not recognize, it should ignore the entire attribute specification (i.e., the attribute and its value).

IE will also not render in quirks mode or so as some may think. It will only do that on invalid/forced doctypes, not on invalid attributes.

However, keep in mind that some Javascript libraries/frameworks will "invisibly" add/use custom HTML attributes in the DOM tree, such as several jQuery plugins do. This way you may risk collisions in attributes because it "by a coincidence" uses an attribute with the same name as you do for your own purposes. Sadly this is often poorly or even not documented at all.

BalusC
I accepted this answer because it addresses the question I posed. Some kind of authoritative source would be nice, though.
KaptajnKold
I added a quote from w3.
BalusC
+1 thanks for the w3 source and specific quote :)
Faisal Vali
A: 

If the page is declared to be HTML 4 strict, then it should not add attributes that are not used in that HTML specifies. Differently, it is not clear what the browsers would behave.
As already reported, a way to add additional attributes is to add them as classes, even if that has some limitations.

kiamlaluno
+1  A: 

Or is it conceivable that some browsers will change to "quirks mode" and render the page as if it was something other than strict HTML 4.0?

No, bad attributes will not force a rendering mode change.

If you don't care about validation do what you like, but validation is a useful tool for detecting simple mistakes that can otherwise have you chasing around debugging. Given that there are many other perfectly good alternatives for passing data to JavaScript I prefer to use one of those, rather than forgo validation.

Plus, when you add an arbitrary attribute you are effectively playing in a global namespace. There's no guarantee that some future browser or standard won't decide to use the name ‘translationkey’ for some new feature that'll trip your script up. So if you must add attributes, give them a name that's obscure and likely to be unique, or just use the HTML5 data- prefix already.

bobince