Re: SVG in text/html

On Tue, Mar 24, 2009 at 5:34 PM, Ian Hickson <ian@hixie.ch> wrote:
>  * Defined <script> processing for SVG <script> in text/html by
>   deferring to the SVG Tiny 1.2 spec and blocking synchronous
>   document.write(). The alternative to this is to integrate the SVG
>   script processing model with the (pretty complicated) HTML script
>   processing model, which would require changes to SVG and might
>   result in a dependency from SVG to HTML5. Anne would like to do
>   this, but I'm not convinced it's wise, and it certainly would be
>   more complex than what we have now. If we ever want to add async=""
>   or defer="" to SVG scripts, then this would probably be a necessary
>   part of that process, though.

So if I understand this correctly, this means that the only difference
in processing HTML scripts and SVG scripts is that document.write does
not work in SVG scripts (apart from that different attributes are
supported on the two types). Is this correct?

If so, I don't see what the benefits are with this approach. From an
author point of view, this seems strictly like a bad thing. If a
script is moved from HTML into SVG, all of a sudden document.write no
longer works. I can't think of any case when this would be something
that the author desires.

>From an implementation point of view this would only add code since we
would have to treat the two differently. Granted, the difference in
handling would be very small, so it's not a big problem. However it is
definitely not a benefit.

It also seems like this introduces additional uncertainty since I
don't see why we in the future wouldn't want to add support for async
and defer to SVG scripts. For the exact same reason we have them on
HTML scripts today.

> On the issue of the <![CDATA[ ]]> syntax, I have left the spec as it was
> before for MathML, which means <script> blocks in SVG are not parsed quite
> the same as <script> blocks in HTML. I don't think this is a huge deal,
> and it wasn't really clear what else to do. There doesn't seem to be a
> strong reason to support <![CDATA[ ]]> in regular HTML, and not supporting
> it in SVG seems likely to make it hard to achieve the goal of having SVG
> in XML be directly copiable into text/html, and would cause all kinds of
> weird troubles (e.g. with scripts that use ">" but have it escaped). If we
> think it's worth it, though, I guess we could just drop <![CDATA[]]>
> support altogether and be done with it, and make <script> and <style> in
> SVG in text/html be treated as CDATA blocks. However, if we do this, we
> have to realise that we aren't going to achieve some of the original goals
> that were put forward (like supporting all SVG-as-XML in text/html).

Based on the discussions in the previous threads on this topic, it
does not seem like it would be a problem to not support <![CDATA[]]>
in SVG-in-HTML. As far as I saw, no one thought it would be common to
use escaped characters inside scripts.

I do definitely think that it happens, and it would mean that such
scripts would stop working when copied into HTML. However I don't see
any reason to believe that this would be a bigger problem than the
number of other ways that scripts can break when moved between SVG
documents and HTML documents. For example the fact that
document.documentElement no longer refers to the <svg> in which the
script is running seems like at least as big of a problem. Or the fact
that document.getElementById might return a node outside the SVG
fragment.

There just is no way that we can ensure that all scripts keep working
when copied from one document into a wholly different one. I don't
think that the escaped entities problem is going to be more common
than any other problem and since trying to solve it comes at a
significant cost, I don't think we should try. The cost here is
confusion as

Instead, I propose the following behavior:

Parsing of an SVG script tag works the same as processing of a HTML script tag.

When processing either, if the contents of the script element starts
with "<![CDATA[", optionally preceded by any number of whitespace
characters, and ends with "]]>", optionally followed by any number of
whitespace characters, only pass the text between these to the
scripting engine. (preferably written more clearly :) )

I also think we should do the same for <style>

>  * Added a paragraph suggesting:
>
>   | To enable authors to use SVG tools that only accept SVG in its XML
>   | form, interactive HTML user agents are encouraged to provide a way to
>   | export any SVG fragment as a namespace-well-formed XML fragment.

I'm fine with making this wording stronger (as Jeff Schiller
suggested). We could also add wording like "This is especially
encouraged in places where UAs already expose the source of the
document".


> On the issue of allowing <svg> to act as a root element, or even
> disallowing it but having requirements exclusively intended to handle
> this error, I have not added those requirements, for the reasons laid
> out in detail in this e-mail:
>
>   http://lists.w3.org/Archives/Public/public-html/2009Mar/0219.html

I think this is something we should keep looking at, but I think it is
orthogonal to the rest of this discussion so it's something that we
IMHO should do in a separate thread.

/ Jonas

Received on Thursday, 26 March 2009 02:42:26 UTC