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

[Leif Halvard Silli]

Robert J Burns 2008-08-31 13.20:

> 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.


That it creats a "great incentive" to create non-conforming 
documents sounds like a stretch. For whom such incentive?

>> 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 errorrecovery requirements
>> applicable to a missing ALT attribute, this is tantamount,
>> for many practical purposes excluding validation, to not
>> requiring ALT altogether.


I don't get this. Firstly, does HTML 5 define error recovery for 
IMG-s lacking @alt? And what does that recovery look like?

 >> 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.


One must pretty geeky in order to be wanting to make such documents.

> 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).


You said that <p> will *not* be allowed to contain <table> etc. 
Yet that seems like a modest wish compared with a wish to remove 
what Jason described as a driving idea behind HTML 5.

>> "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.

Not sure what is wors from "Ian-style" versus "draconian". And I 
don't think well-formedness is hard to swallow. It is *yellow 
screen of death* which is hard to swallow.

>> 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.


Here you are touching something: I do feel that "the HTML 5 way" 
is taking away incentive to "be good". (To be explained at a later 
point.) But when it comes to accessibility, it doesn't do anything 
good if a nesting error makes the entire document inaccessible. 
Also, even if I in my previous reply suggested that nesting errors 
should make the tags in question be treated as HTML comments, one 
could also say that "making sense" of pretty harmless nesting 
errors such as <strong><span>text</strong></span> would help 
accessiblity.

> 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.  


We can neither know what Ian would have specified from the start 
nor what error handeling had looked like had it been specified 
from the start by those that specified HTML 1.

Do you and Jason think that either there must be no error handling 
or there must be todays XML-style error handling?

> 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.

This works as a pressure in as much that those browsers which do 
not support the standard will be punished for it and/or standards 
adherence attracts users to conforming User Agents.

I see an irony here: At least Firefox and Opera have used "better 
support for standards" as one of the main reasons to choose them. 
But now they are suddenly sawing the branch they sat on by trying 
to specify HTML to look more or less like IE has seen it.

But perhaps that picture was always too simple.
-- 
leif halvard silli