What are the concrete risks of using custom HTML attributes in HTML4 Strict?

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 o开发者_开发技巧ther than strict HTML 4.0?

Update:

Hilited the actual question posed.

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.

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

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.

Duplicate try this thread though: Is it alright to add custom Html attributes?

Also look at this: Non-Standard Attributes on HTML Tags. Good Thing? Bad Thing? Your Thoughts?

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.

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.

(Copying my answer from a duplicate question)

Answers which say custom attributes won't validate are incorrect.

Custom attributes will validate.

Custom tags will validate too, as long as the custom tags are lowercase and hyphenated.

Try this in any validator. It will validate.

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>Custom Test</title>
    </head>
    <body>
        <dog-cat PIANO="yellow">test</dog-cat>
    </body>
</html>

Some validators:

https://appdevtools.com/html-validator

https://www.freeformatter.com/html-validator.html

https://validator.w3.org/nu/

But is it safe? Will it break later?

Custom Tags

No hyphenated tags exist. For that reason, I believe that W3C will never add a hyphenated tag. It's very likely a custom hyphenated tag will never see a conflict. If you use a weird prefix in your custom tags, even less likely. Eg.<johny-Calendar>.

Custom Attributes

There are hyphenated HTML attributes. But the HTML spec promises never to use an attribute starting with data-. So data-myattrib is guaranteed to be safe.

I believe that W3C will never introduce any attribute that starts with johny- or piano-. As long as your prefix is weird, you'll never see a conflict.

It's worth considering that the first version of HTML was written in 1993. Now, thirty years later, all browsers still support custom tags and attributes, and validators validate them.

<jw-post jw-author="Johny Why" jw-date="12/2/2022">