[Bug 8038] Permit closing tag for new, void elements - for legacy compatibility = XHTML alignment

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8038


Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua@xn--mlform-
                   |                            |iua.no
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




--- Comment #2 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2009-10-25 21:53:13 ---
(In reply to comment #1)
> Rationale: Making the closing tag optional would be remarkably confusing. 

Wherein lays the confusion? 

> Consider:
> 
>    <foo>x</foo>
> 
> ...in a UA where <foo> is void and where it isn't -- what does it contain?

It can be treated as <img>X</img>. UAs already handle that case. They treat 
<img>X</img> as containing nothing. The "x" gets placed outside the <img>.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/289
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/291

> It would also require additional hacks in the parser, to handle:
> 
>    <foo></foo>
> 
> ...as ok but to raise errors for:
> 
>    </foo>
>    <foo>x</foo>
>    <foo<!-- --></foo>
>    <foo><!x></foo>
>    <foo>&amp;</foo>
> 
> ...etc.

I'm not sure exactly what Maciej meant by "has to be treated like a parsing
error".  

However: </img> has never been permitted for <img> in text/HTML. And yet, all
UAs seem to have the same policy for how to handle it. 

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/290

So even if you the spec would not allow it, it seems like UAs would be destined
to handle it.

> Also, in practice, the new void elements are not a problem: we haven't
> introduced void elements that are affected by this in a major way. 

I disagree. 

And it is not the new void elements that will be affected, but the rest of the
page.

><source> is
> only useful if <video>/<audio> work anyway, and if they don't, it doesn't
> matter if the <source> contains the element's contents.

I see it like this:

(1) <video> is touted as better than than <object>
(2) <source> is one of the key reasons it has been touted as better.
(3) There are many socalled <video> demos online. None of them seems to include
<source> 
       http://www.google.no/search?hl=en&q=demo+video+html5
(4) Webkit/Opera/Firefox claims to support Video experimentally, 
      but only Webkit takes the <source> part seriously.
(5) In browsers that doesn't know about  the new, void element, the the *rest*
of the page is what will be affected as it will become part of <source>.

If we take <video> seriously, then we need to cater for support for <source>
from the start.

> <command> can trivially
> be put inside a <div> with display:none, or at the bottom of a <menu>, or in an
> <li> in a <menu>, so again, it doesn't really make much difference.

(1) HTML 5 with crutches. If something is confusing, then it is these hacks.
(2) We should separate the concerns and consider authors over web browsers.

> Thus it seems to me that overall, the language is best served by not adding
> this extra complexity at this time.

(1) On the contrary, I think we are better served by adding closing tags at
this time, as it represents simplicity rather than confusion, for authors.
While for User Agent vendors, it represents a step that they will need to take
at some time anyhow, and they better take it sooner rather than later.
(2) If it, at a later stage, we find that it is not necessary anymore, then we
can make </newvoid> disallowed. After all, this is how <embed> was introduced:
Embed was introduced with a closing tag </embed>.  Today (in HTML 5 and in HTML
as she is spoke), it isn't used anymore.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 25 October 2009 21:53:18 UTC