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

[Leif Halvard Silli]

Robert J Burns 2008-08-31 11.35:

> Aug 31, 2008, at 12:47 AM, Leif Halvard Silli:


>> Ian-style handling would not have been possible from the start,
>> because so many errors have developed until now which we did not
>> have from the start!
> 
> By Ian-style handling, I'm simply referring to silent (or at least  
> pretty quiet) error-recovery. That certainly could have been there  
> from the start and in fact was there from very early on. The other  
> thing Ian brings to the table now, is an attempt at unambiguously  
> specifying the error-handling and hopefully an adoption across UAs of  
> that silent error-recovery error-handling. My sense from your iCab  
> example is you are talking about error-recovery that is not so silent.  
> So perhaps every browser by default would provide some non-modal  
> feedback whenever a page has errors. Agree that this is not Ian-style  
> nor draconian, but I couldn't tell what you were referring to until  
> you brought up iCab. My original point still remains though, that Ian- 
> Style (nearly silent error recovery error handling) would not lead to  
> less tag soup. Even without specifying the error-recovery, but  
> requiring UAs to give the user obvious feedback for errant documents  
> would have led to less tag soup, but I still don't see Ian supporting  
> something like that.


The Error Log of iCab is simply that: An error log. As such, it is 
merely a tool that every iCab is shipped with. It merely logs all 
errors of a page, and has no effect on page display. For Firefox I 
have seen similar tool(s) as add-on. (I tried one that included 
the Tidy tool once.)

>> What I said was that the fact that the UAs handle, bless, excuse
>> or don't accept tag soup/syntax errors based on a largly common
>> but undefined error handling rules, has let many more errors =
>> much more tag soup to grow and develop than we would have seen if
>> error handling had been defined from the start.
> 
> Defining error handling does not do it per se. It is the immediate  
> feedback that errors exist across all UAs that would reduce tag soup.  
> Again, Ian's contention was that defining error-handling would reduce  
> tag soup. However, if you fully define error-handling, but silently  
> render the page, then there's no way tag soup will be reduced. So  
> specifying error alerts reduces tag soup, but not error-recovery  
> (which is what I understand Ian as saying when he says well specified  
> error-handling).

The  "Yellow screen of death" in XML is a bit too much. And 
perhaps one of the reasons why XHTML pages are served as text/HTML 
anyhow, effectively killing the XML benefit.

In CSS, error handling was cared for from the start. There, unless 
you do it correctly, the CSS command simply has no effect. A 
similar error handling in HTML would have been nice. Let us say 
that wrong nesting, e.g. <b><i>bold italic</b></i>, would lead UAs 
to silently ignore the those tags - treating them as comments.

Something like that could have been possible from the start. But 
it would be difficult to start with something like that now.

>> Do you use 'Ian-style' as a synonym for [...]


> Yes, partially. I  am talking about well-defined but silent error  
> recovery. [...]


>> I don think I or anyone else see the problems clearer just because
>> you attach [the] name of Ian to it.
> 
> I'm not trying to obscure, I thought from the thread we had  
> differentiated these terms.


OK. But it was not very helpful to me.

 
>> That very thing is nothing new. The only UA I have used which
>> constantly warn about errors is iCab. And that's why I use it.
> 
> Again, so its the error feedback that reduces tag soup (which might be  
> one part of error-handling), but not error-handling itself: and  
> certainly not the type of error handling Ian advocates.


Some kind of feedback, yes.

 
>> Again, Ian spoke historically: He predicted a there would have
>> been less errors in the HTML code around the globe if error
>> handling had been defined from the start.
> 
> Which is wrong if the error handling doesn't specify obvious error  
> notification to users.


I think the CSS inspired error handling I mentioned above would 
not hurt users much, even if it would hurt the author.

 
> Even if we added such error handling to HTML1 (or 2) originally, it  
> would not do any good if it didn't annoy authors (and even other users).

It would have to annoy authors in some way, yes.

>> The crux seems to be that you think that only XML style handling
>> can reduce the number of errors. There we disagree. But I may have
>> failed to convince you about that ...
> 
> No, I agree that iCab style would also reduce tag soup. Again, my view  
> is that iCab style error handling is also not something Ian would ever  
> support. So going back to my original point, how can Ian say in that  
> interview that specifying error handling (in a way that Ian would ever  
> support) could ever reduce 'tag soup'.


Because he spoke historically, I think he can.

 
>>> [...] 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. [...]
>>
>> Ah, yes, true, some link 'tag soup' to the use of <b> and <i>
>> instead of <strong> and <em>. [...]
> 
> I'm not talking about distinguishing bold from strong emphasis or  
> italics from emphasis. The example <b><i>some bold italics</b></i> is  
> ill-formed HTML. 


Ah, sorry, was too late in the night when I answered.

> It is precisely the type of tag soup that has  
> proliferated due to silent error-recovery. Specifying that silent  
> error-recovery from the start would have done nothing to reduce such  
> errors. On the other hand, no browser had the 'genius' idea of  
> applying error-recovery by looking for attributes on closing tags (at  
> least not that I'm aware of) so today such errors do not persist,  
> because the error is immediately apparent to the author testing in any  
> major browser.

I will not comment what he has inserted into HTML 5 - the example 
you mention might indeed be a bad example. We should not mix what 
he does with what could have been done.

> To sum up then, error notification (as part of error handling) reduces  
> tag soup. However, error handling that is silent — which is what I  
> think Ian means — does nothing to reduce 'tag soup'. Instead he's  
> using the phrase as a sort of name drop. It doesn't even mean anything  
> in that sentence, its just meant for the readers to go, "yes...  
> mmmm... tag soup, bad. HTML5 must be good. This Ian, smart" On the  
> other hand, perhaps Ian thinks if done from the start, XML style  
> draconian error handling or iCab style clear notification error  
> handling should have been used. But then I wonder why if it was  
> possible then, why we can't transition to it now (hint: because  
> Microsoft want to undermine W3C recommendations so that its horrible  
> and proprietary formats continue to keep them on top).

I guess we would have had a more diverse web - with both pure 
XHTML and text/HTML, if IE had supported XML.  As such, this new 
interest for HTML as HTML - which HTML 5 represent, might be seen 
as a result of XHTML failing its promised because of IE. Is that 
what you meant?

But it might also be that this new interest for text/HTML stems 
from a lack of belief in the answer XML gives to HTML's lack of 
error handeling.

But do not for second say that once we say no to Yellow Screen Of 
Death, then the natural answer is always equal to whatever Ian 
comes up with.
-- 
leif halvar silli