- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 31 Dec 2008 17:10:37 +0100
- 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 Yes. >> 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 UTC