W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2009

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

From: <bugzilla@wiggum.w3.org>
Date: Sun, 25 Oct 2009 21:53:14 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1N2B1W-0002CF-BE@wiggum.w3.org>

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


> 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

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. 


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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:41 UTC