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

[Leif Halvard Silli]

Robert J Burns 2008-08-30 08.48:

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


He only spoke generally. But XML, with its extreme error handeling 
- the 100% opposite of text/html, in a way says the same thing as 
Ian: "There should have been error handeling". :-)

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

   [...]

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


I hope at least those elements you mention /are/ included in the 
<p> model, when HTML 5 is ready ...

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

Well, is microformats a way to extend or use 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. [...]


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


On the general level, OK. But the editor must be targetted at the 
spesific document. Only then can WYSIWYM work, I think.
-- 
leif halvard silli