Re: Script in SVG vs. HTML (was: Input on the agenda)

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("&lt;");
> </script>
>
> alert "<" or should it alert "&lt;". 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