- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 18 Mar 2009 16:30:51 -0700
- 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 < 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:27 UTC