So what if custom HTML attributes aren't valid XHTML?

Question

I know that is the reason some people don't approve of them, but does it really matter? I think that the power that they provide, in interacting with JavaScript and storing and sending information from and to the server, outweighs the validation concern. Am I missing something? What are the ramifications of "invalid" HTML? And wouldn't a custom DTD resolve them anyway?

Linalool

I really wish so many programmers weren't obsessed with validation. This is one of those situations were my first thought is precisely "so what?". Most people consider that blasphemy, unfortunately... – Ph

I agree with you, but I wanted to hear the counter-arguments. – Linalool

Pretty much a duplicate of https://mcmap.net/q/87270/-custom-attributes-yea-or-nay – Gipon

I like to know I validate... It makes me feel warm and fuzzy – Easting

Validating is nice. Putting your project's best interests at stake in order to validate is another thing. Proper closing tags, proper syntax, these are things I can get behind. Throwing away a solution because it doesn't validate is another story. There's a reason why only like 2 of the top 1000 websites in the internet validate. I prefer to Get Things Done. – Ph

Validation assists with accessibility does it not? For example the bind, I believe (may be wrong), that some of the meaning or content could be lost when custom tags are used. – Willaims

+1 To Paolo. Business dictates whether or not validation is necessary -- not the other way around. – Royer

Answer 1

The ramification is that w3c comes along in 2, 5, 10 years and creates an attribute with the same name. Now your page is broken.

HTML5 is going to provide a data attribute type for legal custom attributes (like data-myattr="foo") so maybe you could start using that now and be reasonably safe from future name collisions.

Finally, you may be overlooking that custom logic is the rational behind the class attribute. Although it is generally thought of as a style attribute it is in reality a legal way to set custom meta-properties on an element. Unfortunately you are basically limited to boolean properties which is why HTML5 is adding the data prefix.

BTW, by "basically boolean" I mean in principle. In reality there is nothing to stop you using a seperator in your class name to define custom values as well as attributes.

class="document docId.56 permissions.RW"

Electronic

Can be solved by prefixing them. Not to mention that real XHTML can benefit from namespaces, but real XHTML is rare anyway. – Putrescine

+1 for using the class attribute - providing that the data is boolean. – Nanny

I do think this is a good objection, though it is not a danger in many of the examples I'm thinking up in recent projects. (Is "disbursementId" likely to become a w3c attribute?) Still, knowing why something should be avoided also tells you when it doesn't have to be avoided. – Linalool

Even if something doesn't become a W3C standard, it might be used in a proprietry browser extension, or browser plugin extension, or a third party JavaScript you wish to use. You can reduce the chance of having a collision, but not using non-standard attributes in the first place avoids it entirely. – Geest

isnt it also plausible that a proprietry browser extension will also use the data- naming convention? – Anticline

Browser extensions rarely modify page markup. The ones that do tend to break pages as a matter of course (Symantec AV and Skype are notorious for this). Still not a reason to not use data- prefixes. – Electronic

As a fellow dev comment on the dot separator - it might break class selectors: class="thingType.image" -> think about targeting .thingType.image{} or $('.thingType.image'). – Diagnosis

Answer 2

Yes you can legally add custom attributes by using "data".

For example:

<div id="testDiv" data-myData="just testing"></div>

After that, just use the latest version of jquery to do something like:

alert($('#testDiv').data('myData'))

or to set a data attribute:

$('#testDiv').data('myData', 'new custom data')

And since jQuery works in almost all browsers, you shouldn't have any problems ;)

update

• data-myData may be converted to data-mydata in some browsers, as far as the javascript engine is concerned. Best to keep it lowercase all the way.

Sapp

Thanks for mentioning jQuery.data() - makes it not only cool but elegant solution as well! – Northern

Note: according to the standard, hyphen-separated data- attributes are converted to camelCase in Javascript. So you could use data-my-data and it would be myData in Javascript. – Curve

Answer 3

Validation is not an end in itself, but a tool to be used to help catch mistakes early, and reduce the number of mysterious rendering and behavioural issues that your web pages may face when used on multiple browser types.

Adding custom attributes will not affect either of these issues now, and unlikely to do so in the future, but because they don't validate, it means that when you come to assess the output of a validation of your page, you will need to carefully pick between the validation issues that matter, and the ones that don't. Each time you change your page and revalidate, you have to repeat this operation. If your page validates entirely then you get a nice green PASS message, and you can move on the next stage of testing, or to the next change that needs to be made.

Petitioner

Answer 4

I've seen people obsessed with validation doing far worse/weird things than using a simple custom attribute:

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

In my opinion, custom attributes really don't matter. As other say, it may be good to watch out for future additions of attributes in the standards. But now we have data-* attributes in HTML5, so we're saved.

What really matters is that you have properly nested tags, and properly quoted attribute values.

I even use custom tag names (those introduced by HTML5, like header, footer, etc), but these ones have problems in IE.

By the way, I often find ironically how all those validation zealots bow in front of Google's clever tricks, like iframe uploads.

Hereunder

Answer 5

Instead of using custom attributes, you can associate your HTML elements with the attributes using JSON:

var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };

And as for the ramifications, see SpliFF's answer.

Foretooth

Neat and succinct solution - only let down by the fact that the element and the attributes are not stored together. – Nanny

I'm not sure this is better than just storing the data as (JavaScript) properties of the DOM element object (object.attribute = "value"). I know Safari has recommendations for doing this. – Putrescine

@Ionut, that too can be done; but then we'll have to create the DOM objects and store them in memory. – Foretooth

Answer 6

Storing multiple values in the class attribute is not correct code encapsulation and just a convoluted hack way of doing things. Take a custom ad rotator for instance that uses jquery. It is much cleaner on the page to do

<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />

and let some simple jquery code do the work from here. Any developer or web designer now can work on the ad rotator and change values to this when asked without much ado.

Coming back to project a year later or coming into a new one where the previous developer split and went to an island somewhere in the pacific can be hell trying to figure out intentions when code is written in an unclear encrypted manner like this:

<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes"  />

When we write code in c# and other languages we don't write code putting all custom properties in one property as a space delimited string and end up having to parse that string every time we need to access or write to it. Think about the next person that will work on your code.

Serpentiform

Your claim that one is more confusing than the other isn't supported by anything but your own opinion. In either case you'd need to document the attributes somewhere so the next person should be able to work with either format. The fact that you deliberately changed the identifiers to vague abbreviations in your second example just to make a point shows you never really had one in the first place. – Electronic

Answer 7

The thing with validation is that TODAY it may not matter, but you cannot know if it's going to matter tomorrow (and, by Murphy's law, it WILL matter tomorrow).

It's just better to choose a future-proof alternative. If they don't exist (they do in this particular case), the way to go is to invent a future proof alternative.

Using custom attributes is probably harmless, but still, why choose a potentially harmful solution just because you think (you can never be sure) it will cause no harm?. It might be worth to discuss this further if the future proof alternative was too costly or unwieldy, but this is certainly not the case.

Lexie

Which one do you propose to use in the question you linked to? The top voted answer will not validate as XHTML – Ph

The top voted answer is not constant, so I cannot know what are you referring to. In any case I had missed the XHTML tags in the question. – Lexie

Additionally, the comments approach would be a seems future proof enough, as is using JavaScript to store the data instead of custom attributes. I also like the HTML5 approach, betting on a future standard. – Lexie

Answer 8

Old discussion but nevertheless; in my opinion since html is a mark-up and not a progamming language, it should always be interpreted with leniency for mark-up 'errors'. A browser is perfectly able to do so. I don't think this will and should change ever. Therefore, the only important practical criteria is that your html will be displayed correctly by most browsers and will continue to do so in, say a few years. After that time, your html will probalbly be redesigned anyway.

Jessjessa

Answer 9

Just to add my ingredient to the mix, validation is also important when you need to create content that can/could be post-processed using automated tools. If your content is valid you can much more easily convert markup from one format to another. For example, doing valid XHTML to XML with a specific schema is Much easier when parsing data that you know and can verify to follow a predictable format.

I, for example NEED my content to be valid XHTML because very often it is converted into XML for various jobs and then converted back without data loss or unexpected rendering results.

Diagnosis

Answer 10

Well it depends on your client/boss/etc .. do they require it be validating XHTML?

Some people say there are a lot of workarounds - and depending on the sceneraio, they can work great. This includes adding classes, leveraging the rel attribute, and someone that has even written their own parser to extract JSON from HTML comments.

HTML5 provides a standard way to do this, prefix your custom attributes with "data-". I would recommend doing this now anyway, as there is a chance you may use an attribute that will be used down the track in standard XHTML.

Easting

Answer 11

Using non-standard HTML could make the browser render the page in "quirks mode", in which case some other parts of the page may render differently, and other things like positioning may be slightly different. Using a custom DTD may get around this, though.

Untimely

A custom DTD, usually, makes things worse than having custom attributes. And solves no other problem than validation warnings, as browsers ignore doctypes. – Putrescine

Can you give an example of a browser that will be thrown into quirks mode by custom attributes if you have a valid DOCTYPE? This sounds unlikely to me... – Ph

AFAIK most browsers are supposed to be fine as long as there's a <!DOCTYPE html>, which is why HTML 5 only suggests using exactly that (i.e. no PUBLIC identifier or SYSTEM path). Browsers don't read DTDs anyway, because browsers don't validate. Generally speaking they shouldn't even break if confronted with custom elements (this is why HTML 5 elements work at all). – Cacuminal

browsers will try different DTDs anyways, when trying to render a page – Bowsprit

Answer 12

Because they're not standard you have no idea what might happen, neither now, nor in the future. As others have said W3C might start using those same names in the future. But what's even more dangerous is that you don't know what the developers of "browser xxx" have done when they encounter they.

Maybe the page is rendered in quirks mode, maybe the page doesn't render at all on some obscure mobile browser, maybe the browser will leak memory, maybe a virus killer will choke on your page, etc, etc, etc.

I know that following the standards religiously might seem like snobbery. However once you have experienced problems due to not following them, you tend to stop thinking like that. However, then it's mostly too late, and you need to start your application from scratch with a different framework...

Apollinaire

This sounds more like fear mongering than any legitimate reason to avoid custom attributes. page doesn't render at all because of a custom attribute? really? leak memory? really? – Ph

Do you know what "undefined behavior" means, Paolo? If you've coded C for a while, you'll develop a very healthy, very justified fear of it. Most browsers treat most pages with kiddie gloves, but look at all the pages "broken" by IE 7/8 to see where the policy of relying on nonstandard behavior leads. – Roentgen

...@Paolo... This is not one of those cases, this is more like the case where you're wrong and Chuck is right ... ;) – Apollinaire

Answer 13

I think developers validate just to validate, but there is something to be said for the fact that it keeps markup clean. However, because every (exaggeration warning!) browser displays everything differently there really is no standard. We try to follow standards because it makes us feel like we at least have some direction. Some people argue that keeping code standard will prevent issues and conflicts in the future. My opinion: Screw that nobody implements standards correctly and fully today anyway, might as well assume all your code will fail eventually. If it works it works, use it, unless its messy or your just trying to ignore standards to stick it to W3C or something. I think its important to remember that standards are implemented very slowly, has the web changed all that much in 5 years. I'm sure anyone will have years of notice when they need to fix a potential conflict. No reason to plan for compatibility of standards in the future when you can't even rely on today's standards.

Oh I almost forgot, if your code doesn't validate 10 baby kittens will die. Are you a kitten killer?

Reseta

Answer 14

Jquery .html(markup) doesn't work if markup is invalid.

Dufour

It would be more accurate to say it doesn't work if the browser can't parse it. Even though custom attributes are "invalid", all browsers can parse them so .html() will work fine. – Curve

Answer 15

Validation

You shouldn't need custom attributes to provide validation. A better approach would be to add validation based on fields actual task.

Assign meaning by using classes. I have classnames like:

• date (Dates)
• zip (Zip code)
• area (Areas)
• ssn (Social security number)

Example markup:

<input class="date" name="date" value="2011-08-09" />

Example javascript (with jQuery):

$('.date').validate(); // use your custom function/framework etc here.

If you need special validators for a certain or scenario you just invent new classes (or use selectors) for your special case:

Example for checking if two passwords match:

<input id="password" />
<input id="password-confirm" />

if($('#password').val() != $('#password-confirm').val())
{
 // do something if the passwords don't match
}

(This approach works quite seamless with both jQuery validation and the mvc .net framework and probably others too)

Bonus: You can assign multiple classes separated with a space class="ssn custom-one custom-two"

Sending information "from and to the server"

If you need to pass data back, use <input type="hidden" />. They work out of the box.

(Make sure you don't pass any sensitive data with hidden inputs since they can be modified by the user with almost no effort at all)

Duckweed