Re: Mixed bag of comments on SVG 1.2

Jim Ley wrote:
> 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.

Would you care to explain why it is unlikely?

> 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
> |intersect.
> 
> Is there a major reason for this?  I would like to have:
> 
> <Multiply xmlns="urn:pattern">
>  <svg xmlns="...svg..."><!-- some SVG --></svg>
> </Multiply>
> 
> and have:
> 
> <extensionDefs...>
>   <elementDef name="Multiply">
>     <prototype>
>       <svg ...>
>         <refContent/>
>       </svg>
>       <svg ...>
>         <refContent/>
>       </svg>
>       <svg ...>
>         <refContent/>
>       </svg>
>       <svg ...>
>         <refContent/>
>       </svg>
>     </prototype>
>     <!-- etc. -->
>   </elementDef>
> </extensionDefs>
> 
> 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.

Yes, there's excellent reason for this. <refContent> is, as you know, a 
real reference and not a clone. This means there are various things that 
would cause problems such as having different CTMs or CSS cascades 
simultaneously, even though it's the same one.

That's what <use> is for, and why we have two different elements.

Oh, and URNs make for ugly namespaces.

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

This could be useful, the downside being that some headers appear 
multiple times so you'd have to always return an Array which since there 
is no Array in the IDL, means we'd have to have an interface for 
URLHeaderList. Which in turn means you're probably happier writing your 
own wrapper :)

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

That's an excellent idea. It might perhaps in fact be extended to any 
File since it could contain metadata too. Access to it might not be 
interoperable between UAs, but it people are adequately warned of this 
we should be safe. Thoughts?

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

It's only been half-updated ;)

-- 
Robin Berjon

Received on Tuesday, 2 March 2004 09:05:51 UTC