6

I have a friend who has the specific problem of building a case against the use of a custom HTML <wrapper> tag in some site's markup. Now, intuitively we can answer that use of such a tag is risky, as future HTML specs may define a wrapper tag with semantics that conflict with its use on the site. We can also appeal to a particular section of the HTML5 spec which also recommends against the use of custom tags for this reason.

And while I agree with the conclusion, I find these arguments a little on the weak side, on their own. Is there some well grounded and proven theory in computer science from which we can derive this conclusion? Have programming language theorists created proofs about the properties of vocabulary versioning, or some such thing?

Improve this question
7
  • 3
    I don't know your answer but why is it weak if a specification says 'Don't do this'?
    – Uwe Plonus
    Dec 12, 2012 at 7:13
  • 5
    No well founded theory, but something which might be of interest in your case: joelonsoftware.com/items/2008/03/17.html
    – Doc Brown
    Dec 12, 2012 at 7:16
  • 1
    i could point out that the legitimacy of the HTML5 spec is not universally accepted. but, setting that aside, the problem with the argument is it's a circular appeal to authority. this is bad because it is bad, and this authority says it is bad. the underlying reasoning and evidence is not thoroughly presented. there may not be something akin to a mathematical proof, but there seems to be some core set of compatibility principles that many smart engineers and language designers agree on. i wonder if they are codified anywhere
    – Breton
    Dec 12, 2012 at 7:47
  • 2
    "the legitimacy of the HTML5 spec is not universally accepted" ?!
    – AakashM
    Dec 12, 2012 at 9:06
  • You sound overly stubborn, just admit your defeat. Can you disprove that someone with authority towards the spec will at some moment in the future introduce a <wrapper> element? No you can't, how much more science do you need?
    – Joppe
    Dec 12, 2012 at 19:53

1 Answer 1

Reset to default
4

There is a mechanism in XML that allows for the kind of extension that you are doing, and avoids the conflict by allocating tags in specific namespaces. To use this, you need to use the XHTML syntax encoding of the HTML5 vocabulary. (See HTML vs. XHTML.)

What it allows you to do is to declare a namespace (which looks like a URL) and a token (e.g. "mx" for "my extension"). You need a namespace declaration at the top that associates the namespace with the token. (See Declaring Namespaces.)

 <html ...  xmlns:mx="http://mycompany/myextension" ... >

Then, instead of defining a <wrapper> tag, you define a tag <mx:wrapper>

Because of the token, and colon, you can never conflict with an official HTML tag, because those tags are in a different namespace. (See Namespaces of HTML5.)

What about conflicts on the token? Remember that the "mx" is just a local identifier associated with the longer, and globally unique, namespace URL. In another document the token "yob" might be associated with the namespace, and the tag would be <yob:wrapper> in the body of the document.

I don't know if this is the answer that you wanted, but the namespace mechanism is a well proven (if cumbersome) way to mix together tag sets from different standards bodies which necessarily work independently, but need to mix their results together into a single document.

It does require that you use XHTML, instead of HTML syntax, which actually works in most of the browsers I have experience with, in fact I generate exclusively XHTML syntax and have not had problems, but you will need to investigate whether that is suitable in your environment

Improve this answer
1
  • I am not that green around the ears. I know all about XML namespaces already. I appreciate the thoroughness and thoughtfulness of your answer. I thank you for taking the time to answer. But you kind of missed the point of my question by a mile.
    – Breton
    Jan 19, 2013 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.