- From: Chris Lilley <chris@w3.org>
- Date: Fri, 1 Oct 2010 16:33:15 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: ddailey <ddailey@zoominternet.net>, Doug Schepers <schepers@w3.org>, www-svg <www-svg@w3.org>
On Friday, October 1, 2010, 1:26:21 AM, Ian wrote: IH> On Thu, 30 Sep 2010, ddailey wrote: >> Any idea of what those rare edge cases might be? IH> The main one (assuming we do the CDATA thing) would be use of entities, so IH> e.g.: IH> <script> IH> if (x < 3) IH> foo(); IH> </script> IH> ...would no longer compile. I think that particular work-around (too keep the element well formed) may be used in some xhtml content, but would be rare in deployed SVG content since users have been able to depends on CDATA maked sections. So its much more common to see <script><![CDATA[ if (x < 3) foo(); ]]> </script> Often, CDATA marked sections are used around all script elements, not just the ones that happen to contain a bare "<", 'just in case'. Note too that entity references, numeric character references and other markup are not allowed inside CDATA marked sections. So we don't find things like &myfunction; inside script elements, in practice. What Jonas proposes looks good to me; it allows existing SVG content to continue to work in mixed HTML/SVG even if script is consolidated from an SVG script element into an HTML one. And having the same parsing model for script elements in HTML and non-HTML is clearly beneficial also. -- Chris Lilley Technical Director, Interaction Domain W3C Graphics Activity Lead, Fonts Activity Lead Co-Chair, W3C Hypertext CG Member, CSS, WebFonts, SVG Working Groups
Received on Friday, 1 October 2010 14:33:23 UTC