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

[Robert J Burns]

Hi Leif,

I'm afraid I'm understanding very little of your responses.

On Aug 30, 2008, at 2:07 PM, Leif Halvard Silli wrote:

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

You think Ian is saying there should have been XML-style error  
handling from the beginning? I think that would have been great, but  
that's not the Ian I know.

>>> 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'?

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

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

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

Yes, but not the only way. That's why I was asking you to clarify.

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



Again, I don't know what you're saying here. Editors do target  
specific documents.

Take care,
Rob