- From: Jim Ley <jim@jibbering.com>
- Date: Tue, 2 Mar 2004 12:07:38 +0000 (UTC)
- To: www-svg@w3.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 |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. 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. 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 :-) Cheers, Jim.
Received on Tuesday, 2 March 2004 07:07:40 UTC