W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2008

More thoughts on when <script>s get run

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 24 Jul 2008 12:33:31 +1000
To: public-svg-wg@w3.org
Message-ID: <20080724023331.GE7291@arc.mcc.id.au>

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?

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 24 July 2008 02:34:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC