- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 01 Jan 2009 15:03:53 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Philip Taylor" <pjt47@cam.ac.uk>, "Ian Hickson" <ian@hixie.ch>, public-html@w3.org
On Wed, 31 Dec 2008 17:10:37 +0100, Julian Reschke <julian.reschke@gmx.de> wrote: > 3/10 may or may not be HTML. They may be fragments that will go through > an additional processing step before actually becoming HTML. Yes, and of those the TurboGears URLs would be unaffected because the <textarea/> there is inside a <textarea>. > All of these show up for looking for this pattern in resources with the > extension "html", though. Yes, but did you take a look at the actual resources? I did. As I mentioned above, for 2 out of those 3, the <textarea/> is itself inside a CDATA section nested inside another <textarea>. There's also a Python instruction at the top and TurboGears is a Python framework. Even if it outputs the same in the end, simplified that would look like <textarea> <textarea/> </textarea> which would cause no problem whatsoever. The third one uses non-HTML attributes. > 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. No, 4 out of 10 will be broken. Only 2 out of 10 will be fixed and those are demos... Also, as Philip already demonstrated there is more content out that relies on <textarea/> being an opening tag. And it makes sense, given that all browsers treat it that way it is highly unlikely that authors would intentionally make pages that don't work in browsers. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Thursday, 1 January 2009 14:04:41 UTC