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

Re: Void elements in HTML

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
Message-ID: <op.um2z0rtg64w2qv@annevk-t60.oslo.opera.com>

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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:00 UTC