- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 24 Oct 2009 00:41:18 +0200
- To: Joe D Williams <joedwil@earthlink.net>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, HTMLWG WG <public-html@w3.org>
Joe D Williams On 09-10-24 00.20: >> [ ... ] >> >>> You misunderstood slightly. ^_^ Ian was referring to the fact >>> that >>> <source>, being a new void element, doesn't work properly in >>> current >>> browsers (they treat it as as the start tag of an unknown element). >>> <command> is another new void element with similar problems. >> So what's the workaround for <source>? XHTML syntax? >> >> <source /> is valid HTML 5 and, when created via >> document.createElement(), works perfectly in IE6: it isn't treated >> as the start tag of a unknown element. And creating workarounds for >> other legacy browsers than Internet Explorer, is not nearly as >> common ... >> >> <source></source> also works. So, to validate as XML and serve as >> text/html would work ... >> >> <source> has one "advantage" over <source/> and <source></source>: >> Support has to be hard coded into the Web browser - it doesn't rely >> on the "distributed extensibility" of using non-void elements. >> >> Perhaps that's the crux? > > I see the same situation for <param> in an <object>. > > These were treated sort of like <meta> with some situations where you > don't use the / to signal a close tag? > > I'm not sure about the difference between processing environments but > I do see now that if I expected XML rules as I know them and are > serious about it, then how can <source> without a closing signal work > as expected in an xml parser? If you serve your HTML 5 pages as XHTML, then you must either use <source /> or <source></source> - either is valid. The problem is that most pages will be served as text/html, where only "<source />" is valid. My point above was that most legacy browser installations (Internet Explorer) do not need any workaround, other than the "/>" at the end, because IE, in this situation, and unlike all other browsers, treats it as a element closing signal, like in XML. My point between the lines is that the text/html serialization of HTML 5 should permit not only "<source />" but also "<source></source>" - that would be the simplest workaround of all - should work cross browser! Why can't HTML 5 permit that? >> Support has to be hard coded into the Web browser > > I guess I can see this hard coded into a parser that does html served > as text/htnl, but actually without further study, I don't know how to > code it into an xml parser used if served as application/xhtml+xml. > The <source> with no closing should keill the xml machine at some > point? Now I see why I might always put those end / in there by > default even though not actually needed in html processor with fixit > steps. . Again, if served as XHTML, then you must close the tag properly - either "/>" or "</source>" See this posting from Karl: http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html > Also, is this about the same workaround for attributes that are not > written as a name='value' pair but freestanding as a boolean? I have no insight into how to create workarounds for that issue. -- leif halvard silli
Received on Friday, 23 October 2009 22:41:55 UTC