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

Re: Short-term workarounds - - <source> in <video>

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 24 Oct 2009 00:41:18 +0200
Message-ID: <4AE2310E.8020404@xn--mlform-iua.no>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:50 GMT