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

Fri Aug 29 23:48:32 PDT 2008

HI Leif,

On Aug 30, 2008, at 12:00 AM, Leif Halvard Silli wrote:

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

Agree, Certainly draconian error handling for the original HTML would  
have reduced tag soup. However, considering the what Ian and the  
others in WhatWG have to say about XML and its draconian error  
handling, I don't really think that's what Ian meant.

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

Certainly having predicable error handling results is a good thing.  
However, if by tag soup we mean syntax errors (including ill- 
formedness and invalid which is how I understand it), then I can't see  
how providing predictable results for errors would reduce errors. If  
anything, it reduces the incentive to produce valid and error-free  
code, because at least one incentive now is consistent handling by  
browsers.

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

The use of table inside P in qurksmode is merely due to the Table  
element not causing the implicit close of P. Certainly if the original  
UL, DL, OL and TABLE elements didn't lead to an implicit P close tag  
(which would be the same as including them in the P element content  
model from the start), then we could add these to the P content model  
(or they would already be there). My point is that the original  
designers were too 'certain' that the P element could be implicitly  
closed: in other words, that they understood the proper content model  
for the element. Unlike the other implicit close tags (TR closes TR,  
LI closes LI, etc), the structure of a paragraph is not as clear cut.  
Even, if they understood the possibility of including Tables, lists,  
and block quotations within a paragraph, there are still other things  
that might be suitable in a paragraph that we cannot predict. And  
considering the close P tag is as short as a close tag gets, it hardly  
seems worth the subsequent trouble (even considering 1990 bandwidth  
constraints).

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

Microformats specifically or semantic extensibility in general? I find  
the microformats methods to be particularly clumsy ways to extend HTML.

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

+1 on the lack of CSS.

It wasn't easy to envision the difference between semantics and  
presentation until we had a functional pure presentation mechanism. On  
the issue of WYSIWYM, I feel quite the opposite. Many of the editing  
tool problems today arise from trying to produce 1980s style WYSIWYG  
editors with an underlying structure that separates presentation from  
semantics (where we see implementors mistakenly trying to defend this  
separation by mapping bold to strong). Authors want to take advantage  
of this separation of concerns and the editing tools need to  
accommodate that.

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

Take care,
Rob