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

On Tue, Mar 10, 2009 at 8:46 AM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Folks-
>
> Jonas Sicking wrote (on 3/9/09 8:00 PM):
>>
>> Personally I would like to see something that is even more HTMLy than
>> Hixies current proposal. I don't like at all that we have to use a
>> different tokenizer in "HTML mode" and in "foreign content mode". This
>> is both confusing to web developers and painful for end users (as
>> performance and code complexity suffers).
>
> 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.

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.

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

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

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.


So all in all I think this might be doable. The only blocker I can see
is if there is enough XML-SVG content out there that uses <script>
without <![CDATA[]]> which would prevent copying such markup into
HTML. I don't know if that is the case so other peoples experience
here would be great. As far as copying in the other direction
(SVG-in-HTML to XML-SVG), I don't think it's a bigger problem than for
things like misnested tags, wrong casing, or unquoted attributes.
Whatever solution we use to mitigate that (tools or validators),
should also address <script>s.

Best Regards
Jonas Sicking

Received on Tuesday, 10 March 2009 22:28:32 UTC