Re: CDATA, Script, and Style

Some members of the HTML working group have proposed changing how <script> 
and <style> in SVG in text/html get parsed.

Currently they are parsed like in XML, e.g. <![CDATA[ ]]> blocks are 
supported, entities work, they can contain elements and comments, etc. To 
be consistent with the rest of text/html, they could be parsed as elements 
that can't contain child elements or comments and have no entity support.

Doing this, however, would mean we didn't achieve the one goal of the SVG 
working group, namely "content authors should be able to take a valid SVG 
document, paste its markup into an HTML document, and have it render as 
expected and have the SVG fragment's DOM be identical to the DOM of the 
standalone SVG document when served as image/svg+xml". [1]

[1] http://lists.w3.org/Archives/Public/public-html/2009Mar/0216.html

On Tue, 31 Mar 2009, Henri Sivonen wrote:
> 
> I think the biggest problem with this entire issue is that the 
> difference between HTML <script> and <script> in XML is surprising and 
> unintuitive, so we will have a surprise boundary somewhere no matter 
> what. It seems on the general level we have the following options:
> 
> 1) Have the surprise boundary between text/html and XML. (The situation 
> before SVG-in-text/html)
> 
> 2) Have the surprise boundary between HTML <script> in text/html and 
> everything else. (The situation with SVG-in-text/html as drafted)
> 
> 3) Have graded surprises with two boundaries:
>   a) Have a surprise boundary between HTML <script> and SVG-in-text/html
>   <script> and another between SVG-in-text/html <script> and XML.
>   b) Have a surprise boundary between pre-HTML5 <script> and HTML5 text/html
>   <script>s and another between text/html and XML.

I think #3 would be the worst of both worlds.

I don't think we can get rid of #2 -- or rather, the text/html language is 
always going to have some weird inconsistencies between the HTML parts and 
the "foreign" parts, such as />-support, <![CDATA[]]>-support, weird 
behaviour with casing, etc.

Given the desire expressed by the SVG working group (which, in the terms 
described above, is basically to minimise #1 as much as possible), it 
seems like sticking with the current dichotomy is the least bad solution.


If we do want to make a change here, I think it would be helpful if the 
SVGWG could outline what it is they would be willing to accept.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 April 2009 02:52:27 UTC