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

Looking deeper at <script>, externalResourcesRequired=""

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 23 Jun 2008 13:59:59 +1000
To: public-svg-wg@w3.org
Message-ID: <20080623035959.GB28915@arc.mcc.id.au>

While looking at ACTION-2063 again, I have a question about
externalResourcesRequired="".

The first paragraph of 5.9.1 says:

  Documents often reference and use the contents of other document and
  other web resources as part of their rendering or processing. In some
  cases, authors want to specify that particular resources are required
  for a document to be considered correct.
   — http://www.w3.org/WWW/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/publish/struct.html#ExternalResourcesRequiredAttribute

So this sounds like it is introducing a feature that can control the
rendering and/or processing of an element given an external resource.
The following paragraph says:

  Attribute 'externalResourcesRequired' is available on all container
  elements except 'defs' and on all elements which potentially can
  reference external resources. It specifies whether referenced
  resources that are not part of the current document are required for
  proper rendering of the given element.

This mentions rendering, but not processing.  <script> elements don’t
render, but they can have an eRR attribute on them.  Should eRR="true"
on <script> prevent the rest of the document from rendering?
(Probably.)  Should eRR="true" on anything with a bad external reference
cause subsequent <script> elements not to execute?  (Not sure.)


Another interesting test I just tried is mutating the document from
script:

  http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/script-modify-document.svg

This is a document whose rendering in Batik is different from
Firefox/Opera.  In the latter, the <script> appends the blue <rect> to
the <svg> before the red <rect> is parsed, so the red one is inserted
into the document after the blue one.  In Batik however, the whole
document is available before the <script> is executed, resulting in the
blue <rect> being appended after the red one.

We’ll have to specify this as well.  Currently the only language in the
spec that I could find that talks about constructing the document is in
the Progressive Rendering section:

  When loading a document following the start element event on a node,
  that node becomes part of the document tree in the unresolved state.
   — http://www.w3.org/WWW/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/publish/struct.html#ProgressiveRendering

That doesn’t say where it goes in the document.  Maybe we can just
change this to say that during loading, the node is appended as a child
of the element corresponding to the most recently parsed start tag.


Also, it is currently unclear whether a load event should be dispatched
to a <script> element with a bad external reference, when eRR="false".
The steps in 15.2.1 do not deal with the case when the external script
cannot be retrieved, and just mentions load event dispatching at the
end.  In the Interactivity chapter, under the description for the load
event, there is this:

  The event is triggered at the point at which the user agent finishes
  loading the element and any dependent resources (such as images, style
  sheets, or scripts). In the case the element references a script, the
  event will be raised only after an attempt to interpret the script has
  been made. Dependent resources that fail to load will not prevent this
  event from firing if the element that referenced them is still
  accessible via the DOM unless they are designated as
  externalResourcesRequired.
   — http://www.w3.org/www.w3.org/WWW/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/publish/interact.html#LoadEvent

I’m not sure if that means load should be fired or not for
<script xlink:href="bad-ref" externalResourcesRequired="false">.  (My
guess is it shouldn’t.)


Answers to the above questions welcomed.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 23 June 2008 04:00:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 June 2008 04:01:05 GMT