[whatwg] [html5] tags, elements and generated DOM

[Lachlan Hunt]

Ian Hickson wrote:
> Ok, it's a contrived case. Here's a less contrived one: <input> elements 
> with a "type" attribute set to "radio" are part of radio button groups 
> that consist of all those <input type="radio"> elements that are 
> associated with a particular form (either via the form="" attribute or by 
> being descendants of a <form>) and that have the same value for their 
> "name" attribute. Only one such <input> element per radio button group may 
> have the "checked" attribute set.

Yes, that probably could be checked by a program.  So, just for the fun 
of it (and to /prove my earlier comments wrong/), I quickly wrote a 
script that actually does (partially) check that.  It's not perfect, 
it's quick and dirty and doesn't work in IE, but it's a good proof of 
concept and anyone actually writing a conformance checker can steal it 
if they like. :-D

function checkRadio() {
   var radio, i;
   var radioButtons = getRadioButtons();
   for (radio in radioButtons) {
     var checked = 0, buttons = radioButtons[radio];
     for (i = 0; i < buttons.length; i++) {
       if (buttons[i].hasAttribute("checked")) {
         checked++;
       }
     }
     if (checked > 1) {
       alert("Warning: " + checked + " input elements in the radio "
           + "button group: \"" + radio + "\" have a checked attribute. "
           + "Only 1 is allowed per radio button group");
     }
   }
}

function getRadioButtons(inputs) {
   inputs = inputs || document.getElementsByTagName("input");
   var radio = new Array();
   for (i = 0; i < inputs.length; i++) {
     if (inputs.item(i).getAttribute("type").toLowerCase() == "radio"
      && inputs.item(i).hasAttribute("name")
      && (name = inputs.item(i).getAttribute("name")) != "") {
       /* Checks for radio buttons with a valid name, non-empty name */
       if (!radio[name]) radio[name] = new Array();
       radio[name].push(inputs.item(i));
     }
   }
   return radio;
}

window.onload = checkRadio;

> A conformance checker that doesn't check for all the machine-checkable 
> things is not compliant, just like a browser that doesn't support 
> everything in the spec is not compliant.

Fair enough, but is the spec going to specify exactly which conformance 
criteria fits into which of the 3 categories you've now added, or is 
expected that implementors will be able to make an educated guess to 
decide for themselves?

> Existing DTD and schema languages 
> can't express enough to be conformant conformance chckers on their own. 
> That doesn't mean they can't be used as one part of a complete conformance 
> checking solution, of course. But it does mean that as it stands now, 
> validator.w3.org [...] could not be called a conformance checker for HTML5.

I guess so, since validators don't claim document conformance anyway, 
only validity.

> (or a version suitably altered to support HTML5 elements)

It doesn't need to be altered, it only needs to be pointed to an HTML 5 
DTD, with the system identifier (the URI) in the DOCTYPE.

> This is not a bad thing. One hopes that HTML5's more detailed conformance 
> requirements will encourage the development of truly useful conformance 
> checkers that don't mislead people into thinking they have written correct 
> documents when in fact they have just fixed the small subset of errors 
> that the limited validator catches.

I hope so, cause existing conformance checkers (often called "lints" 
[1]) for HTML aren't really useful cause they're often only subjective 
and issue bogus errors or don't catch all errors.

[1] http://arealvalidator.com/real-validation.html

-- 
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/     Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox