W3C home > Mailing lists > Public > www-svg@w3.org > March 2009

Re: CDATA, Script, and Style

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 18 Mar 2009 16:30:51 -0700
Message-ID: <63df84f0903181630s79bd37a2jd745488fe62d31cb@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>, Doug Schepers <schepers@w3.org>, HTML WG <public-html@w3.org>, www-svg@w3.org
On Wed, Mar 18, 2009 at 4:14 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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>

Agreed, we need to support that pattern. That should be trivial in
either of my proposals.

>> 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>

In general I think treating your example above the same way as an
unquoted attribute would be treated is a good idea. Still not sure if
that treatment should be a parse error or not, but I think that's an
orthogonal issue. There's separate threads regarding if we can use
view-source tricks instead for example.

> 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?

One thing that would definitely be different between the two is that
one would be in the SVG namespace, and one in the HTML namespace, so I
don't think we can make the DOMs be exactly the same.

In general I do think that we should make it such that the two behave
as similar as possible though. If that means implementing both
interfaces on both nodes, or if it means making the two interfaces
more similar I'm not sure.

I have seen code that checks for HTML-ness by doing
if (node instanceof HTMLElement) {
  ...
}

though, which would be true if an element implements HTMLScriptElement.

/ Jonas
Received on Wednesday, 18 March 2009 23:31:33 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:41 GMT