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

Re: CDATA, Script, and Style

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 31 Mar 2009 12:34:00 +0300
Cc: Jonas Sicking <jonas@sicking.cc>, Doug Schepers <schepers@w3.org>, HTML WG <public-html@w3.org>, www-svg@w3.org
Message-Id: <CB3D58DD-98B4-4788-976A-2B64FFD50D9F@iki.fi>
To: Sam Ruby <rubys@intertwingly.net>
On Mar 19, 2009, at 14:27, Sam Ruby wrote:

> Henri Sivonen wrote:
>> On Mar 19, 2009, at 00:56, Jonas Sicking wrote:
>>> However, if the style was
>>> <style type="text/css">
>>> svg &gt; rect {
>>>   fill: red;
>>> }
>>> </style>
>>> then this would work as expected in XML-SVG, but there might  
>>> possibly
>>> be problems when the markup is copied into a text/html document. In
>>> HTML, the contents of <style> is parsed as CDATA. That means that no
>>> entities are escaped. So the above style tag would contain invalid  
>>> CSS
>>> as the "&gt;" would not be turned into a ">" and so the selector  
>>> would
>>> be invalid and not match anything.
>>> So the question is, how common do we think this is? We're looking  
>>> for
>>> how common it is that:
>>> 1) An SVG file contains inline <style>, *and*
>>> 2) That style does not use <![CDATA[]]> for the contents of the  
>>> element, *and*
>>> 3) The contents uses entities.
>> I don't know how common it is, but this situation arises easily  
>> with an XML serializer that never outputs CDATA sections either  
>> because it is connected to SAX ContentHandler but not  
>> LexicalHandler or just because writing a serializer that doesn't  
>> output CDATA sections is some much easier to do correctly.
> Depends on the serializer.  Not encoding the ">" is legal inside of  
> text regions in XML.

Unless the two previous characters are "]]". To avoid keeping track of  
semi-arbitrary rules like this, I've always programmed my serializers  
to escape '>' into '&gt;' unconditionally.

See http://hsivonen.iki.fi/test/moz/square-square-gt.xml in a YSoD- 
enabled browser.
Henri Sivonen
Received on Tuesday, 31 March 2009 09:34:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:44 UTC