Re: SVG in text/html

On Thu, 26 Mar 2009 03:41:35 +0100, Jonas Sicking <jonas@sicking.cc> wrote:

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

The SVG WG has raised the issue of alignment with the HTML script processing model as ISSUE-2239 [1].

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

Yes, that seems desirable.

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

Right.

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

Yep, scripts will without question break in some cases. That's inevitable, and happens for SVG+XHTML too.

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

True, but those are features we want, and again the same gotchas apply to SVG+XHTML.

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

That sounds like a nice way of helping script authors.

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

Yes, that'd be fine with me too.

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

Sounds fine, also see

  http://lists.w3.org/Archives/Public/public-html/2009Mar/0599.html

Cheers
/Erik

[1] http://www.w3.org/Graphics/SVG/WG/track/issues/2239

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 26 March 2009 09:53:28 UTC