Validation consideration for the template tag

[studdugie]

Hello,

I've run into a practical/functional problem w/ how the spec treats HTML5's new template tag. The issue started out for me as a problem w/ validation but after raising the issue on the W3C's validator mailing list I've since learned that the validator is simply doing what the spec demands it does. Therefore I'm raising the issue here. But I'm going to explain it in terms of validation because that's how the problem ultimately manifests itself.

I am a web app developer and my shop makes extensive use of HTML5's template tag. Here are some actual examples from my work that highlight the problem (assume the root element is a template) :

• img descendants whose src attributes are not set
• time descendants whose text content is empty
• Variants of the same form on a page that have a mutually exclusive relationship between themselves. The spec violation here is that some of the elements in the form are the same therefore they have the same IDs.

Technically speaking 1-3 violate the spec but functionally speaking they do not because the JavaScript process of turning an inert template into a live node in the DOM includes, in the case of 1 & 2, setting the src attribute and giving time its text content. In the case of 3, because the forms are mutually exclusive to each other only 1 of them will ever be made live.

So the crux of the issue we are having is that validation is tedious and error prone because every time we try to validate a page in our web app we are met w/ a litany of warnings and errors about all the things wrong w/ the descendants of each template element on the page, which significantly detracts from our ability to identify any legitimate issues with the page. It's so bad now that we have given up on validation entirely.

The only reason I've bothered to raise this issue is because I'm a follower of html5doctor.com on Twitter and recently reread this article, http://html5doctor.com/html5-check-it-before-you-wreck-it-with-miketm-smith/. Mike Smith's attitude struck a note w/ me. He represented the validator and the people behind it as being genuinely interested in helping and improving the lives of web developers. So I said to myself, "what the heck, the worse that could happen is nothing". But what I would actually like to see happen is that the spec be modified in such a way that allows a validator to stop complaining about the violations by children of template so that developers can focus on what is actually wrong w/ a page.

Thanks,

Dane

[UPDATE] I thought I should give a more concrete example of the form/id problem.
There is a template w/ a login form w/ user name and password fields and the associated ID attributes on both. There also exists a template w/ a create account form, which necessarily has user name and password fields w/ the same IDs as the login form. Only 1 of these forms can ever be live in the DOM so though the IDs are duplicates they never collide in the live DOM.

[zcorpan]

Thanks for reporting this!

Would you like the validator to give an error if you did this?

<template><p clas="foo"></p></template>

or

<template><input type="img"></template>

?

[studdugie]

I think it should report both of your examples as errors.

[studdugie]

@zcorpan, your question got me thinking. Maybe a good place to start would be to loosen the restrictions on the absence of mandatory attributes and elements on the descendants of template tags. Because as your example clearly shows validation on the children of template elements remains important.

[zcorpan]

OK, so then we shouldn't just say "anything goes" in template.

We need to check how people use template in the wild and then remove requirements that don't make sense in template, to compile a list of what exactly needs to be changed to fix this.

[zcorpan]

Some interesting finds in httparchive:

<template class="js_globalmessage"> <div class="globalmessage {{type}}"> <div class="messagecontainer"> {{message}} {{#if closable}} <button type="button" class="close js_close">&#x2a09;</button> {{/if}} </div> </div> </template>    

Hmm... Having {{#if foo}} etc as text makes it hard to check content models, e.g. in an ul... And this won't work inside e.g. tables. Maybe it would be better to use nested template elements?:

<template class="js_globalmessage">
 <div class="globalmessage {{type}}">
  <div class="messagecontainer">
   {{message}} 
   <template data-if="closable">
    <button type="button" class="close js_close">&#x2a09;</button>
   </template>
  </div>
 </div>
</template>

(Maybe the template element should allow any attribute, like embed, so you can do if="..." etc?)

...  <img src="{2}" width="44" height="33"> ...
... <img id="topcmm-123flashchat-common-userlist-richer-img" src=""/> ...

{2} here is probably supposed to be replaced when using the template, as well as filling in the empty src attribute. Since there's no standard syntax for this, maybe attribute values should be "anything goes".

<table width="100%" cellspacing="0" cellpadding="0" border="0" style="table-layout: fixed;" class="topcmm-123flashchat-common-list-table"> <thead> <tr> </tr> </thead> </table>

No cells should be allowed. Obsolete attributes should not.

<span class="topcmm-123flashchat-common-chat-panel-single-box-time-text-color topcmm-123flashchat-common-message-float-left" speaker_style> <div> ...

speaker_style should still be invalid; div in span should also be invalid.

Error: Duplicate ID topcmm-123flashchat-buy-credits-panel-pay-type-box-btn-{0}.

Allow this...

Error: Element marquee not allowed as child of element template in this context.

Obsolete elements should not be allowed.

Also the validator shouldn't warn about empty elements e.g. h1

[studdugie]

I agree w/ everything stated and especially w/ the bit about empty elements. That one is a personal pet peeve of mine. When I used to validate I used to scream at the validator for the long list of warnings about empty elements and errors about missing or malformed attributes that it spat out. It was during one of those scream-fests that I realized that validation wasn't worth it. So I am really quite delighted that there is a chance something will be done about it.

[zcorpan]

I should fix this before merging sources (#52).

[sideshowbarker]

Howdy. Just chiming in here for now to say I fully support making spec changes here to align better with real-world author-developer needs. Implementing changes in the HTML checker behavior for it could end up being some significant work but worth it if the end result is something that people actually keep using (and like to use) rather than something they don’t use (or don’t like to use) due to annoyance caused by excessive message about non-problems.

[sideshowbarker]

There is a template w/ a login form w/ user name and password fields and the associated ID attributes on both. There also exists a template w/ a create account form, which necessarily has user name and password fields w/ the same IDs as the login form. Only 1 of these forms can ever be live in the DOM so though the IDs are duplicates they never collide in the live DOM.

As far as the checker behavior goes, I think suppressing errors about duplicate IDs may turn out to be relatively complicated to implement, but still doable. Certainly if we agree the spec should say such duplication is not a conformance error for the template case then I’ll definitely try to find a way to support it. I may even start trying to implement some of this stuff experimentally in the mean time.

[zcorpan]

I discussed this issue with @sideshowbarker in #whatwg a bit today

http://logs.glob.uno/?c=freenode%23whatwg&s=28+Jan+2016&e=28+Jan+2016

and we're now leaning towards not validating the template subtree at all, and instead focus on providing usable tools for validating the post-transformed tree (by having a validator in browsers' devtools).

We could always revisit this later and work on catching typos in attribute names and content model violations pre-transform, but right now I think my cost/benefit analysis favors skipping validation pre-transform.

HTML parse errors would still be reported (e.g. <template><table>foo</table></template>).