W3C home > Mailing lists > Public > www-svg@w3.org > March 2004

Mixed bag of comments on SVG 1.2

From: Jim Ley <jim@jibbering.com>
Date: Tue, 2 Mar 2004 12:07:38 +0000 (UTC)
To: www-svg@w3.org
Message-ID: <loom.20040302T130725-266@post.gmane.org>

In XML Events:
| In ECMAScript, the contents of the handler element behave as if they
| are the contents of a new function object, created as shown:
|function(evt) {
|  // contents of handler

This suggests that Arguments[0] will be an evt object, is that really
likely?  It might be best just to avoid this method and state that
"evt" will be available locally as the event object of the event.

In RCC 4.1.7
| It is legal to have multiple refContent elements in the shadow
|subtree, but the subsets of the children that they select must not

Is there a major reason for this?  I would like to have:

<Multiply xmlns="urn:pattern">
 <svg xmlns="...svg..."><!-- some SVG --></svg>

and have:

  <elementDef name="Multiply">
      <svg ...>
      <svg ...>
      <svg ...>
      <svg ...>
    <!-- etc. -->

as a simple mechanism to create repeating SVG content (yes we could
put the refContent in a USE and then use that, but with overlapping
refContents it could get complicated), if it doesn't harm
implementations it might be nice to see this restriction removed.

In 17.8.1 URLRequest Interface:
|NameValuePair getResponseHeader( in unsigned long index ); 

I'd like an interface which accessed it by Response Header name,
rather than just by index, having to iterate over them all querying
the name is almost certainly silly.  (I've not checked but I believe
the header name is case insensitive - certainly most server
convenience apis treat it as such - so this shouldn't be hard to

In 17.10.5 Interface File 

Would it be possible that Files which are ones that would be handled as 
SVGMedia, also expose the getMetadata method from the SVGMedia interface - this 
will allow us to extract metadata from these files before uploading them.

Thanks for the draft, and as I expected there wasn't much for me to moan 
about... better luck next time :-)


Received on Tuesday, 2 March 2004 07:07:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:00 UTC