Re: More thoughts on when <script>s get run

On Jul 23, 2008, at 7:33 PM, Cameron McCormack wrote:

>
> Hello.
>
> While thinking about ACTION-2109 and ACTION-2063, I’m once again a bit
> unsure about what we should actually do with the <script> execution
> model.
>
> Batik’s JSVGCanvas can be told to load a document from a URL or it can
> be given an already-constructed Document object to display.   
> Currently,
> even if given a URL, Batik will parse the whole document and only then
> display it.  So both of these methods are incompatible with the  
> proposed
> changes to the <script> execution model, since if you had:
>
>  <svg …>
>    <script>
>      document.documentElement.appendChild(…);
>    </script>
>    <g/>
>  </svg>
>
> then the element would be appended after the <g>.  (That is what
> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/script-modify-document.svg
> demonstrated.)
>
> The method where a URL is passed could be fixed without too much  
> worry;
> initialisation of the dynamic things in the document and running  
> scripts
> would just have to be done while parsing is occurring, rather than  
> after
> parsing is finished.  The method where an already-constructed document
> is passed to the JSVGCanvas is trickier, though: after all, the whole
> document is already there.  A way around this would be to  
> incrementally
> construct a new document to display in the JSVGCanvas from the  
> elements
> in the passed-in document, but that would be both a waste of time/ 
> memory
> and would make existing code that held on to references to elements
> in the passed-in document (to mutate them) not work any more.
>
> Any thoughts on supporting this use case?  Would it be acceptable to
> have <script> processing function differently if a whole document is
> passed in to render?  Do HTML user agents have an API to do this, and
> thus come across the same problems?

In WebKit, for HTML <script> elements, we have the following behavior:

1) If the <script> element is created by the parser, it blocks further  
parsing until loading (if necessary) and execution is complete.

2) If the <script> element is not created by the parser (say, using  
DOM APIs), then it starts loading (if external) or executing (if  
inline) when the element is inserted into the document; if external,  
execution happens asynchronously when the load completes.

We don't have an API to display an already-constructed Document; the  
closest you can get is to replace the documentElement of an existing  
Document in a frame, which would be treated as case #2.

For web compatibility it is necessary to treat html:script differently  
in the above two cases, and I believe the same rules could be soundly  
applied to svg:script.

Regards,
Maciej

Received on Friday, 25 July 2008 02:26:39 UTC