Re: Introducing the W3C HTML/XML Task Force

On 29.12.2010 20:44, Leif Halvard Silli wrote:
> ...
>>> 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.
>
> HTML has void elements. That they work different from void elements in
> XHTML is just how HTML is. I see, below, that you suggest stop creating

XML doesn't have void elements in the sense of HTML; it has a notation 
for empty elements, but that works consistently for all elements.

> more void elements. That could perhaps be described as stranglinG HTML
> syntax - not respecting how it works in HTML. Though, OTOH, to say that
> no more void elements should be created is, I admit, another way to
> accept how things work, in HTML.

The problem with void elements in HTML is that you need to know the 
vocabulary to parse them. With SGML (as far as I understand) that wasn't 
a problem, because you always had a DTD. With HTML as of today, this is 
not the case.

You can't introduce new void elements in the future without changing the 
parser (again, that's my understanding). That's why I think it shouldn't 
be done, and that doing so in HTML5 already was a mistake.

Note it also affects serializers; the main reason why the XSLT HTML 
output method needs to be updated are the new void elements.

>>> 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.
>
> I actually think we would have come a long way if only
> <newVoid></newVoid>  was permitted. It would be logical to allow old
> void elements to be writen as, for example<img></img>, as well -
> perhaps with the exception  of</br>. The fact that this is not
> permitted, makes it more difficult to, legally, extend HTML5 with new
> elements.

Exactly.

Best regards, Julian

Received on Wednesday, 29 December 2010 20:25:01 UTC