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

[Leif Halvard Silli]

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.

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

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

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.

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

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

 
>> 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.
-- 
leif halvard silli