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

[Robert J Burns]

Hi Leif,

On Aug 30, 2008, at 9:05 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-30 17.34:
>    [...]
>
>> You think Ian is saying there should have been XML-style error
>> handling from the beginning?
>
>
> HTML 5 is being defined taking into account history. But in the
> interview he speculated about the past. I imagine that he imagines
> that error handeling, if defined back then, could have differed
> from both XML and HTML 5.

True, it could differ. But the only error handling that would reduce  
'tag soup' as I'm using the term would be XML style draconian error  
handling. There are other benefits of defined error handling, but  
reducing 'tag soup' is not one of them unless it is draconian error  
handling (again I think you and Ian are using the phrase differently,  
but I haven't figured out how you're using it yet).

>> I think that would have been great, but that's not the Ian I know.
>
> In danger of repeating: XML and Ian agree that HTML should have
> had error handeling from the start. They also agree that this
> would have created less (with XML, theoretically close to zero)
> tag soup. Both also try to answer the challenge from the past. But
> they solve this challenge from the past differently.

Only XML style error handling reduces tag soup. Again, whatever other  
benefits it may have, Ian-style error handling does not reduce 'tag  
soup'.

>>>>> 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.
>
>>>
>
>>> Had it been taken care of from the start, then we could have had a
>>> much more logical error handeling than we have to define now, when
>>> one has to take into account what the browsers already accept.
>>> Defining error handeling is a kind of negative defining of what is
>>> correct. Hence, I agree with Ian on this.
>>
>> You (and Ian) must be using 'tag soup' to mean something completely
>> different than I defined it. Could you tell me how you're using the
>> phrase 'tag soup'?
>
> XML style errorhandling is draconian, and hence predicable.
>
> Ian's error handeling, as he dreamed it from the start, would not
> be draconian - I think.

So how could it cause a reduction in 'tag soup'?

> Still, if all browsers were required to handle errors and
> exceptions "mildly", but in the same way, then they would not have
> had to invent this handeling by themselves. This would have lead
> to fewer errors being accepted. Unlike today, when some browser
> does it that way, another that way, a third that way - and as a
> result, each browser has to support all the different ways of
> handeling errors, in order to be compatible.

So are you and Ian using the phrase 'tag soup' to describe the various  
ways browser handle errant HTML? The reason XML error handling reduces  
tag soup is that the author is made immediately aware of the errors  
(the soupiness of their tags) even without using a validator or  
conformance checker. Upon seeing their soup they fix it so that they  
can publish their documents. Ian-style error handling, masks the  
errors of the authors (and their authoring tools) from the authors.  
They do not know they are creating tag soup because they test it in  
their browser and it works. With standardized Ian-style error handling  
authors still can't see their errors upon testing in a browser. In  
fact they may test it in a dozen HTML5 browsers and still not see the  
soupiness of their tags. Perhaps you (and Ian) are saying that the  
errors are no longer tag soup because they are handled in a consistent  
manner? So then we have a new distinction (at least new to me):  
conforming documents and errant documents where errant documents can  
be broken down into those containing tag soup and those that don't.  
For example <object>fallback</object data='file.mpeg' > would be a tag  
soup errant document, but <b><i>some bold italics</b></i> would be an  
errant document, with no tag soup. I'm just honestly trying to  
understand how you're using the term tag soup here.

>>> I hope at least those elements you mention /are/ included in the
>>> <p> model, when HTML 5 is ready ...
>>
>> No, Leif. There won't be any tables, lists or block quotes in the  
>> HTML
>> paragraph element. They were in the original WG draft lats year (only
>> for the XML serialization), but they've now been removed (presumably
>> because of Ian's impeccable research and logic).
>
>
> This is of course steps in the wrong direction.

Like so many steps over the last 18 months.

>>> Well, is microformats a way to extend or use HTML?
>>
>> Yes, but not the only way. That's why I was asking you to clarify.
>
> I would call it "using HTML".

Yes, I would too. However, its also using HTML in a way that extends  
the expressiveness and semantics of HTML. If HTML (meaning here  
specifically text/html HTML) supported XML namespaces-like  
extensibility, then using those namespaces for extending HTML would  
also be using HTML. Again, I think the microformats approach is a much  
clumsier way to do extensibility because it stomps over other ways  
authors commonly use HTML.

>>> On the general level, OK. But the editor must be targetted at the
>>> spesific document. Only then can WYSIWYM work, I think.
>>
>> Again, I don't know what you're saying here. Editors do target
>> specific documents.
>
> Specific /types/ of documents.

I'm still not understanding you. Could you list some examples of the  
types of documents you are referring to. I'm thinking of an editor  
that targets specifically an HTML type document, or an XHTML type  
document. However, I can tell here you must be using type in a  
different way.

Take care,
Rob