W3C home > Mailing lists > Public > public-html@w3.org > December 2008

Re: Void elements in HTML

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 31 Dec 2008 17:10:37 +0100
Message-ID: <495B997D.4060806@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: Philip Taylor <pjt47@cam.ac.uk>, Ian Hickson <ian@hixie.ch>, public-html@w3.org

Anne van Kesteren wrote:
> On Wed, 31 Dec 2008 16:03:51 +0100, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> I just checked some (~10) that are reported for lang:html, and it 
>> seems that a significant amount of them actually reflect empty 
>> textareas, be it by mistake, or because the content actually is XHTML 
>> (potentially served as HTML).
> I'm assuming here you had this search:
> http://www.google.com/codesearch?q=%3Ctextarea[^%3E]*%2F%3E+lang%3Ahtml


>> These cases would be *fixed*, not *broken*, by allowing the empty 
>> element notation.
> Really?
> dojo/1.0.2/dijit/tests/form/Form.html (result 1) and 
> trunk/Jmol-documentation/script_documentation/examples-11/save.htm 
> (result 2) depend on <textarea/> being treated like <textarea>.
> eformmail-2.0/doc/example_form.html (result 3) would indeed work better 
> with <textarea/> meaning <textarea></textarea>. (But then it might be 
> that it's an XML document with the wrong file extension given that it 
> uses the XHTML namespace and all.)
> trunk/database/ui/create-object.html (result 4) is the fourth result, 
> also works better with <textarea/> meaning <textarea>.
> frontend/application/demobrowser/source/demo/io/HttpRequest_1.html 
> (result 5) would indeed work better with <textarea/> meaning 
> <textarea></textarea>. (Though the difference hardly matters as far as I 
> can tell.)
> TurboGears-0.9a7/docs/docs/tutorials/wiki20/page3.html (result 6) the 
> <textarea/> here is inside a CDATA block which is inside another 
> (properly closed) <textarea>. It seems to be some kind of Python 
> templating language. (The next result is identical.)
> tapestry-4.0-alpha-3/framework/src/test-data/context20/Three.html 
> (result 8) doesn't really look like HTML (jwcid attributes?).
> increasing-form-usability-example.html (result 9) has 
> <textarea/></textarea>.
> trunk/index.html (result 10) depends on <textarea/> meaning <textarea>.
> In conclusion:
> In 4/10 <textarea/> should mean <textarea>.
> In 2/10 <textarea/> should mean <textarea></textarea>. (Though both are 
> demos and don't seem to have had much testing.)
> In 3/10 there is no HTML.
> In 1/10 it doesn't matter.

3/10 may or may not be HTML. They may be fragments that will go through 
an additional processing step before actually becoming HTML.

All of these show up for looking for this pattern in resources with the 
extension "html", though.

So what this shows is that of all the instances where we see this 
pattern, a significant amount *intentionally* uses the empty tag 
notation, and these will either be unaffected (because they aren't 
served the way we found them in practice), or will actually be fixed.

BR, Julian
Received on Wednesday, 31 December 2008 16:11:23 GMT

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