This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Void elements needs workaround in legacy browsers (which means all current browsers, except Webkit - see below). However, the competition isn't fair: In Internet Explorer, if you enable support for elements via <script>document.createElement("element")</script>, ending the element with "/>" will close the element as if it was XML, even if we operate in the text/html serialisation. In other legacy browsers without support for the new void elements, adding the "/>" doesn't help. And thus the new void elements will need workarounds, such as a wrapper element and so on. Example with <source>: Per today, Safari is probaly the only released web browser with support for <source> as a void element. Neither Opera 10 nor Firefox support it as void element, despite that they support <video>. There is a very simple "workaround" which woudl solve the issue in most user agents: Make it permitted in the text/html serialisation of HTML 5 to add a closing tag for all, new, void elements. Maciej outlined some requirements for closing tags for void elements: http://lists.w3.org/Archives/Public/public-html/2009Oct/0887
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Making the closing tag optional would be remarkably confusing. Consider: <foo>x</foo> ...in a UA where <foo> is void and where it isn't -- what does it contain? 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>&</foo> ...etc. 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. <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. <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. Thus it seems to me that overall, the language is best served by not adding this extra complexity at this time.
(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>&</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.
Another option: make closing tags for void elements "obsolete but conforming".
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Wait, now I'm confused. What exactly are you asking for? Do you want to make <source> work exactly like <img>? Do you want to make <source> work exactly like <span>? Do you want something else?
(In reply to comment #4) FIRSTLY: I doubt that you are using "NEEDSINFO" as intended here. But anyway, I cannot help you react to what I have written unless you point to the exact line that causes you confusion. If you think there are several confusing lines, you must point to all of them, or to some examples of them and describe why they cause the confusion that you describe - that's the only possible way I can give you the info you say that you need. SECONDLY: I my reply (comment #3) I questioned your decision through claims and questions that are delivered inline in your own reply (comment #2), thus should be very clear. I don't see that you have commented or answered any of it. Hence I reopen.
(In reply to comment #5) > (In reply to comment #4) > SECONDLY: I my reply (comment #3) Should be comment #2 > questions that are delivered inline in your own reply (comment #2) Should be comment #1
(In reply to comment #4) Since you ask me to repeat myself: Regarding <span>, <img> and "work exactly like". <span>: In legacy text/html user agents <source> should have worked exactly like <span>. In reality, <source /> will unlike <span /> and unlike common belief [*] get closed in Internet Explorer. Whereas </source> works as expected all over. <img>: <img> is a void element, like <source>. "work exactly like" - AUTHORS: Authors should be able to take advantage of the common knowledge that, in legacy user agents, <unknownelement> gets closed by </unknownelement>. Thus they should be permitted to use </source>, so as to avoid additional hacks just to close the element and to avoid that authors avoid using <source> (or even <video> itself) due to lack of support for <source> as a void element. "work exactly like" - SYNTAX: for new void elements, the syntax should work exactly like in XML/XHTML. Meaning: <source></source> should be a permitted syntax. "work exactly like" - LEGACY USER AGENTS: No one govern how legacy user agents react to the void <source> or <source />. Some legacy user agents vendors claims to support <video> and have offered demos of the support. Most of these demos never seem to include <source>. September 2008 you demoed support for <video> in a Firefox nightly. http://www.whatwg.org/demos/2008-sept/ You emphasized in your speech that you did not want to talk in future tense. Still there were no support for <source> in that demo. You spoke as if you tested a user agent that supported <video> (despite that you, in this bug report, try to make support for <source> and <video> synonymous things). (There are, btw, several instances of "<video />" on the web, and the do not everytime appear in a XHTML serialization ...) "work exactly like" - for NEW USER AGENTS: New user agents should support <source> as a void element. They should react the same whether the code is written <source>, <source /> or <source></source>. And current Safari release as well as the latest betas of Firefox 3.6 already do behave like that. (Opera 10.10 beta introduces support for <source> but doesn't yet treat <source>xyz</source> like <source />xyz.) [*] Your own comment about the effect of document.createElement() in IE was: "This piece of information makes building an HTML5 compatibility shim for IE7 far easier than had previously been assumed." http://ln.hixie.ch/?count=1&start=1201080691 However, the effect of "/>" in that context, was not discussed then, AFAIK. The effect will be that authors can handle IE6, IE7 and IE8 even more simply. While the rest of the flock will be left to hacks - or simply be forgottten.
I really don't understand what you're asking for here. Could you describe what DOMs you expect to see in conforming HTML5 user agents, assuming we adopt your proposal, for the following fragments? (For example, by translating them into the equivalent well-formed XML.) <video><source></video>A <video><source>A</video>B <video><source>A</source>B</video>C <video><source></source>A</video>C <video><source><source>A</video>B Similarly, could you state which of the above you think should be conforming, and which should be non-conforming, and how to detect the difference?
(In reply to comment #8) > Could you describe what DOMs you expect to see in conforming HTML5 user agents, > assuming we adopt your proposal, for the following fragments? (For example, by > translating them into the equivalent well-formed XML.) In order of appearance (I did not mark up text nodes): <video><source /></video>A <video><source />A</video>B <video><source />AB</video>C <video><source />A</video>C <video><source /><source />A</video>B The above describes the DOM already implemented in Safari and Firefox 3.6beta, as can be verified in this live DOM viewer demo: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/294 > Similarly, could you state which of the above you think should be conforming, > and which should be non-conforming, These 4 should be conforming. <video><source></video>A <video><source>A</video>B <video><source></source>A</video>C <video><source><source>A</video>B This 1 example should NOT be conforming. <video><source>A</source>B</video>C > and how to detect the difference? Is this a validation detection question? Or is it a user agent parsing question?
I think this would be confusing because of <br></br> being the equivalent of <br/><br/>.
(In reply to comment #10) I would say that this is only confusing to those who try to infer the rules of HTML without reading specs. They should also probably have a hang-up on <br></br>. Whether <br></br> is equivalent of <br/><br/> or not, currently depends on the user agent. In Opera plus the other 60% of desktop user agents, <br></br> is interpreted as you say. In ther rest it is interpreted as one <br>. Also, for </br> it is simple to say that </br> means <br>. As illogical as that is, it is also mostly pretty harmless. But to say that </img> means <img> is kind of pointless. The same goes for </source> - to say that it means <source> is pointless. Also, despite the <br></br> case, IE and Opera still agree to treat <hr></hr> as <hr/>, despite that it programmatically could have been interpreted as two <hr/><hr/>. And all the big 4 (or big 6, if include Chrome and KHTML) agree to ignore </img>. </br> thus seems like a clear exception.
I know it is an exception. I think it will be confusing.
(In reply to comment #12) > I know it is an exception. I think it will be confusing. I know that you think it will be confusing. I do not know why you think it will be confusing.
One way to minimize possible confusion/increase possible understanding - could be to operate with a legacy user agent profile. To live up to that profile, a document MUST use closing tags for all new void elements, in the way I outlined above.
I believe I have provided enough info for this bug. Hereby adding TrackerRequest. Suggested text for the issue tracker - borrowing a bit from Maciej's formulations: [[ It is hereby suggested * to permit a close tag for new void elements * to require that the close tag of such eleements would have to immediately follow the open tag meaning that a close tag separated by content would have to be treated as just a stray close tag and a parse error. Otherwise, if content were permitted and the HTML5-parsers were required to look for the close tag that didn immediately follow, then a an open tag alone wouldn't work , since the parser then would have to parse to the end of the document to know if there is a close tag. This proposal is motivated by two factors: FIRSTLY, to be compatible with HTML-parsers that haven't been updated to support a new void, element (and thereby ease the introduction of new, void, elements) and SECONDLY, by a wish to align the HTML syntax as much as possible with the XML syntax. [[
Raised as <http://www.w3.org/html/wg/tracker/issues/156>.
Changed the URL field from the old URL (http://software.hixie.ch/utilities/js/live-dom-viewer/saved/288) to the specific section in the HTML5 draft which this blocks - the syntax description of void elements, http://dev.w3.org/html5/spec/syntax.html#void-elements The contested spec text is these two sentences: FIRST: ]] Void elements only have a start tag; end tags must not be specified for void elements. [[ SECOND: ]] Void elements can't have any contents (since there's no end tag, no content can be put between the start tag and the end tag). [[ Suggested change to 'FIRST' sentence: The first sentence above must be changed to say that something like this: 'Void elements only have a start tag; but end tags can be specified provided that there is no content between the start tag and the end tag. Suggested change to 'SECOND' sentence: The sentences is correct, except for the "since there's noe end tag" string, which would could be rephrased into "since iti s a void element".)