Re: Introducing the W3C HTML/XML Task Force

On 29.12.2010 19:22, Leif Halvard Silli wrote:
> Julian Reschke, Wed, 29 Dec 2010 08:56:35 +0100:
>> On 28.12.2010 22:39, Ian Hickson wrote:
>>> ...
>>> In what sense is there a _growing_ chasm between HTML and XML? HTML today
>>> is significantly closer to XML than HTML4 was, for example it supports the
>>> "/" syntax on void elements, it allows xmlns="" talismans, etc. Surely the
>>> two are in fact closer than ever. Indeed even before the HTMLWG was
>>> restarted at the W3C, the WHATWG had spent significant efforts in getting
>>> them as close as possible while maintaining backwards compatibility.
>>> ...
>>
>> One factor here certainly is perception. HTML5 documents a chasm that
>> was already there. It makes it more clear what the chasm is.
>>
>> That being said, it *is* growing partly. For instance, HTML5 didn't
>> need to add new void elements, and it could have ruled them out for
>> the future.
>
> Regarding<void>: 'chasm' or respect for the HTML system/identy? If you
> have parsing in mind, how can one say no to void elements in HTML
> without saying no to<void/>  in XHTML as well? Which option would you

I don't think I understand the question.

> suggest:
> 1) Parse<newVoid>  as non-void.
>     Parse<newVoid/>  and<img>  as void.
>     Require authors to use XHTML syntax - '/>'.
> 2) Parse<newVoid>  like<img>  is parsed.
>     Require authors to use XHTML syntax:
>     <img/>  +<img></img>,<newVoid/>  +<newVoid></newVoid>
>
> I think HTML5 is currently following the second option, with the
> exception that<newVoid></newVoid>  and<img></img>  is not permitted.
> The reason for not permitting<newVoid></newVoid>  and<img></img>  is
> probably the problem related to '</br>'.

My proposal is to not allow any new void elements, and thus make parsing 
and serialization predictable in the future. Also, I think that the new 
void elements in HTML5 should have been non-void as well.

Best regards, Julian

Received on Wednesday, 29 December 2010 18:40:14 UTC