- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 11 Mar 2009 10:20:44 +1100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Doug Schepers <schepers@w3.org>, public-html@w3.org, www-svg <www-svg@w3.org>
Doug Schepers: > > Along not-entirely-unrelated lines, the SVG WG is currently looking at > > aligning SVG script handling with that of HTML. Feedback on this topic is > > most welcome. Jonas Sicking: > This is amazing news. It would be great if authors didn't have to use > different rules for composing <script>s inside the SVG parts vs. the > HTML parts of a single document. > > The issues I can see are: > > 1. > xlink:href vs. src. SVG-script uses xlink:href to link to an external > stylesheet, vs HTML-script uses null:src. I think the best solution > here would be to allow SVG-script to allow either xlink:href *or* src. > We'd have to specify what to do if both are defined, I suggest we > choose one to take priority, probably xlink:href. One difference between <script xlink:href> in SVG and <script src> in HTML is that the xlink:href="" is exposed as an SVGAnimatedString in the SVG DOM, e.g.: alert(scriptElt.href.baseVal); Not that it really makes sense to be able to animate that attribute, but that is how it is currently exposed in the SVG DOM. I don’t know if (m)any people are relying on this particular interface to <script xlink:href> though. Having a plain string exposed through a ‘src’ property would be easier to deal with. > 2. > Parsing as PCDATA or CDATA. This one is trickier. Should content > looking like: > > <script> > alert("<"); > </script> > > alert "<" or should it alert "<". In HTML it's the latter, in > XML it's the former. I think it would be ideal if we could treat > SVG-script as CDATA. The question is how much trouble this would cause > for people that copy XML-SVG into HTML. It would seem to me that the > *most* common pattern is to use <![CDATA[]]> to escape content inside > XML-SVG, but I'm not sure if this is the case. As long as we make that > case work I think we should be fine most of the time (see below). Some people do write <svg:script>s without a CDATA section, and escape the necessary characters. (I’ve done that, if I knew that the script was going to be short.) This is likely to be a minority case, though. I wonder if the MAMA survey could tell us information about this? > A bigger problem is likely to be people copying from HTML to XML-SVG. > However I suspect doing so would in the far most common case result in > a parse error that is easy to find and correct, but it is certainly > conceivable that there scripts that will parse, but run incorrectly. > I am also not sure how often copying fragments that include scripts > is going to work. Copying a dynamic part of a page is many times not > going to work due to the scripts failing to work properly when not > evaluated in a context that they were written for. I don't think > this is specific to SVG, but happens equally much if you copy a HTML > fragment out of a HTML page. I’d agree with that. If you’re copying around scripted content, it’s quite likely it relies on a particular document structure. > I think the best thing we can do for this is to ensure that developers > have access to tools that provide proper XML serialization of an SVG > fragment. This would take care of casing things properly, nesting > tags correctly, quoting attributes and wrapping the contents of > <script>s in <!CDATA[]]>. We already have code in gecko to do this, > I would imagine most other UAs do to as it is required to implement > XMLHttpRequest. How about being able to right click on an SVG fragment in a text/html document (or even an XHTML document) and choosing “Save image as…” to save it out as XML? > Of course, we can't require that UAs implement authoring tools. But > most UAs these days have developer tools, and it should be easy to > integrate into those, so I think it's likely that it will happen. > > 3. > What to do with <![CDATA[]]>. If we do parse as <script> as CDATA > (rather than PCDATA) that means that existing XML-SVG like > > <script> > <![CDATA[ > alert('hello world'); > ]]> > </script> > > would lead to the "<![CDATA[" and "]]>" being treated as part of the > javascript, and result in a JS parse error. I think we can solve this > by allowing the element to strip a heading "<![CDATA[" and trailing > "]]>", if they exist, before sending anything to the JS > implementation. I don't have a strong opinion on if this should be > allowed for both SVG-script and HTML-script, or just the former. > Consistency is always nice of course. The commented-out proposal in HTML 5 at the moment does handle CDATA sections explicitly, and turns them into Text nodes in the DOM. This handling works for CDATA sections appearing anywhere in foreign content. I think this is useful, and not problematic. I agree about the consistency: I wonder if there would be any problems in allowing CDATA sections in HTML content? Should <svg:script> also support the async and defer attributes? -- Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 10 March 2009 23:21:35 UTC