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

Fri Aug 29 14:00:37 PDT 2008

Robert J Burns 2008-08-29 17.27:

> Defining error handling from day one would not "avoid" tag soup, it  
> just would make the handling of tag soup consistent.

Allow me to disagree. For the record, the 'draconian error 
handeling' of XML is also 'error handeling'. Having such error 
handeling from day one, would  have had something to say.

However, I think that even a more "friendly" error handeling would 
have meant less tag soup. The point, in my view, is that the 
effect of errors should have be predictable.

> To me, the most damaging decisions of HTML historically were:
> 
>   • allowing P elements to be closed implicitly (we now cannot change  
> their content model to allow lists, block quotes and inline tables)

Agree. That said: In quirks-mode both IE and Firefox *do* accept 
e.g. <table> inside the <p>. So, as <!doctype html> was chosen 
because it triggers strict mode, had we chosen something which 
triggered quirks-mode, we likely could have changed content model.

Hence, it seems to me this is more an effect of lack of defined 
error handeling than of the choise of implicit closing.

>   • getting away from visual GUI editors (the first HTML editor was  
> visual, but it only ran on NextSTEP)

I would rather say that another shortcoming, from the start, was 
lack of microformats. Some WYSIWYG html editors of today are now 
trying to be socalled What-you-see-is-what-you-mean (WYSIWYM) 
editors. However, it is my view that this does not work unless you 
have defined very spesific formats. For instance, LyX, the WYSIWYM 
TeX editor, does not have a WYSIWYM mode for TeX, as such. You 
have to select very spesific document formats, such as letter, 
book, article and so on in order. Likewise I don't think WYSIWYM 
really works for HTML, unless you are spesific of the kind of 
document you are making. (I guess it is also a pity that we did 
not have CSS from the start.)

>   • UAs deciding to not support SGML DTDs since that's what prevents  
> us from changing anything about the content models
> 
> So, of the three, only the first relates to the language itself (and  
> wouldn't be a problem except for the following two items). The other  
> two are not due to the language. Also with the use of visual GUI  
> editors and SGML adherent UAs, the need for error recovery would have  
> been much less important.

Leif Halvard Silli