- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 19 Feb 2007 10:07:28 +1100
- To: public-appformats@w3.org
Hi again Ian. Cameron McCormack: > > So extend it, and implement "nearestViewportElement". XBL gives you the > > tools to do this -- you could even simply write a binding that applied to > > all elements that implemented this property. > > Ah that would avoid the problem. Something like: > > <binding element="*"> > <template> > <inherited/> > </template> > <implementation> > ({ > get nearestViewportElement() { > var bb = this.baseBinding; > if (bb && bb.nearestViewportElement) { > return bb.nearestViewportElement; > } > // normal nearestViewportElement implementation here > } > }) > </implementation> > </binding> > > Might be a bit dodgy in a CDF situation, having SVG interfaces > implemented on every element, but I guess that's unavoidable. After further discussion in the SVG WG we have resolved that this is too hacky. :) In a CDF document we do not want all of the HTML elements implementing this nearestViewportElement property too. It should also be possible for the nearestViewportElement property to be implemented without knowledge of which bindings are being used between it and the svg:svg element. Our desire for an interface to traverse up the flattened tree remains. Incidentally, a use case for full access to the flattened tree was given to me recently: namely, to be able to construct a “snapshot” of the document to serialize for non-XBL UAs. That would require an interface to peek into shadow trees as well as out of them however, and I understand that there would be more resistance to that than just going upwards. Thanks, Cameron -for the SVG WG -- Cameron McCormack, http://mcc.id.au/ xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
Received on Sunday, 18 February 2007 23:07:40 UTC