Re: CDATA, Script, and Style

Jonas Sicking:
> 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 think this will be very rare.

> For markup that uses <![CDATA[]]> I believe we can ensure that the
> markup will work correctly even in text/html, as detailed in my
> proposal at [1].

If this is what we do, then I think the tokenizer should do something
like

  s/^(\s*)<!\[CDATA\[(.*)\]\]>(\s*)$/\1\2\3/

since I’ve seeen content that is indented something like this:

  <script>
    <![CDATA[
      blah();
    ]]>
  </script>

> This is the exact same issue as we have talked about regarding
> <script>. It did seem like the majority thought that the above three
> conditions were not common enough to be a cause for concern for
> <script>.

I think there would be more <script>s with entities than <style>s, and
that I don’t mind making

  <script>for (i = 0; i &lt; 10; i++) f();</script>

not work in SVG-in-text/html.

Given the desire in the SVG WG to have parse errors for things which
create difficulty when copying content out to SVG/XML, would consistency
dictate that the following SVG-in-text/html fragment be a parse error
too?:

  <script>for (i = 0; i < 10; i++) f();</script>


Also, I wonder whether we can unify the DOM, too, for <script> and
<style>.  Would the above <script> element in foreign content be an
HTMLScriptElement or an SVGScriptElement?  Could we have the DOM node
for <script> implement both HTMLScriptElement and SVGScriptElement?
Does it make sense to do this?

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 18 March 2009 23:15:09 UTC