Robin Berjon: > interface SVGXPathEvaluator : xpath::XPathEvaluator { > void registerFunction( in DOMString NamespaceURI, > in DOMString FunctionName, > in EventListener function ); > } > > A listener taking an XPathResultList and returning an XPathResult would > cut it. Wouldn't you then have all you need to implement CSVG on top of > SVG 1.2? To be honest, I hadn't looked at the DOM 3 XPath stuff before. Looks interesting. I think a major problem though is that the CSVG extensions rely pretty heavily on analysing the expressions used for elements' attributes and properties to determine dependencies. If expressions can start calling arbitrary ECMAScript, then all bets are off (at least, I've only put effort into analysing XPath for dependencies, it *may* be possible with ECMAScript too, but there's much more scope for it to be harder). I do plan on making a CSVG to SVG 1.1 + ECMAScript compiler next to see (a) if it can all be done in SVG 1.1, and (b) what the performance is like. Cameron -- Cameron McCormack | Web: http://mcc.id.au/ | ICQ: 26955922Received on Thursday, 26 February 2004 18:40:13 UTC
This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:58 UTC