[html4all] Interview: HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more

[Robert J Burns]

HI Jason,

On Aug 31, 2008, at 1:02 PM, Jason White wrote:

> My main difficulty with "silent" error recovery, combined with  
> specifying how
> the recovery is to be performed, is that it will create a great  
> incentive for
> content authors to design errant documents which fail to conform to  
> the spec,
> but which are nonetheless processed predictably by conforming  
> implementations.
>
> This is why I have been largely silent, with occasional exceptions  
> on this
> list, about the ALT attribute controversy: even if ALT is a required  
> attribute
> of IMG and AREA as in HTML 4.01, if HTML 5 then defines error recovery
> requirements applicable to a missing ALT attribute, this is  
> tantamount, for
> many practical purposes excluding validation, to not requiring ALT  
> altogether.
> Yet, one of the driving ideas of the HTML 5 effort has been  
> precisely to
> define and codify error recovery, with which doing so in this kind  
> of case
> would be entirely consistent. One can even imagine "validators"  
> designed to
> test for documents that won't be parsed or rendered predictably (by  
> graphical
> UAs) if the HTML 5 error handling requirements are implemented.  
> Obviously,
> this is distinct from testing for conformance to the spec, but I can  
> foresee
> my hypothesized lower standard of evaluation as becoming the norm,  
> given the
> incentive to write erroneous document instances referred to above.  
> In effect,
> the error handling becomes the de facto substitute for whatever the  
> "real"
> conformance requirements stated in the spec turn out to be.

This is also my concern. It also could explain how Ian could make the  
statement he made since for him too, perhaps he's redefining 'tag  
soup' to mean errors not handled by the error recovery. So many well- 
formedness errors are no longer 'tag soup' because they're processed  
with consistent error recovery. Hence we have reduced 'tag soup'  
because 'tag soup' now means only documents with errors that defy even  
the specified error recovery mechanisms (like my <object>fallback</ 
object data='amovie.mpeg' > example). That makes me think that the  
HTML5 recommendation should make it clear that not only should  
implementations follow the parsing algorithm we specify (assuming its  
not the abysmal one in the current draft), but that also  
implementations must not perform any other error recovery not  
specified by HTML5 (otherwise the 'tag soup' drifts onward).

>
>
> "Draconian" is merely a pejorative term brought out by those for  
> whom even XML
> well-formedness constraints are too much to swallow.

Yeah, I guess I should be more careful about using the term draconian.  
I do see it as a pejorative, but I'm also trying to own the term as  
they say. I guess 'strict' or 'fatal' error-handling would be the more  
neutral terms.

> Conversely, of course, if the treatment of non-conforming documents is
> "unspecified" or "implementation-defined", there is more of an  
> advantage to be
> won by actually caring about conformance, again for many practical  
> purposes of
> interest to content authors; and of course, accessibility, among other
> considerations, is likely to loose out even more in this retreat.

Indeed. So to me you've just explained how unspecified error recovery  
led to less 'tag soup' (as I use the phrase) than if error-recovery  
had been originally specified in the way Ian wants to do for HTML5.  
Since the lack of consistent error recovery across browsers led  
authors to turn to validation and the elimination of 'tag soup' to  
ensure consistent processing across browsers.

Take care,
Rob