- From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- Date: Wed, 2 Jul 2008 12:02:56 +0100
- To: Erik Dahlström <ed@opera.com>
- Cc: www-svg <www-svg@w3.org>
- Message-Id: <1530827D-FB39-44D6-AFEE-B2EEF67C8BAB@btinternet.com>
Erik, please could you expand a little further as I'm currently confused as to the meaning of exposed? It had been my understanding that the DOM tree of the 'use' element was not exposed eg: the SVG Document Object Model (DOM) only contains the 'use' element and its attributes.* as you know I struggle conceptually, and it would imho be excellent if cross-WG-domain examples demonstrated intentions.** regards Jonathan Chetwynd j.chetwynd@btinternet.com http://www.openicon.org/ +44 (0) 20 7978 1764 **hence my request for a SVG microformat to demonstrate cross-WG- domain examples and allow easier creation of and experimentation with authoring tools. A simple and easy to use SVG GUI for authoring is not currently available. An authoring tool that includes other W3 technologies will be a considerable hurdle. * http://www.w3.org/TR/SVGMobile12/struct.html#UseElement The effect of a 'use' element is as if the SVG Element contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the 'use' element as its parent and all of the 'use' element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the 'use' element and its attributes. The SVG DOM does not show the referenced element's contents as children of the 'use' element. The deeply-cloned tree, also referred to as the shadow tree, is then kept in synchronization with the contents of the referenced element, so that any animation, DOM manipulation, or non-DOM interactive state occurring on the referenced element are also applied to the 'use' element's deeply-cloned tree. On 2 Jul 2008, at 10:59, Erik Dahlström wrote: > > On Tue, 17 Jun 2008 16:51:54 +0200, Jonathan Chetwynd <j.chetwynd@btinternet.com > > wrote: > >> Erik, >> >> thanks for the rapid response, >> my concern is that when navigating with the keyboard the >> focusHighlight surrounds the element with focus in each case. >> however when using the mouse, the focusHighlight surrounds the >> descendent clicked, when this has not been set to be focusable >> directly, rather than the element which was set to monitor focus >> events. >> there is an additional issue that 7 alert dialogues are raised on the >> middle element, why might this might be? > > I think that it is because the SVGElementInstances share the event > listener list with the use element they belong to[1]. Essentially > this means that because you register an event listener (with the > onfocusin attribute) on the 'use' element, you "register" event > listeners on each of the elements in the conceptually cloned tree > (the elements referenced by the 'use'). The event handler will > therefore be called 7 times in the example (since there are 6 levels > of nesting, and the use element listener will be invoked once), and > they will have different currentTarget:s. If you are only interested > in the events on the 'use' element, then adding for example > "if(e.currentTarget instanceof SVGUseElement)" will ensure that. > Note that event.target will be the element to which the event was > first sent, and it should stay the same during the event bubbling > and should always be an SVGElementInstance if the event originated > from a conceptually cloned tree. > >> on a related issue, is it the case that title content is always that >> of the child, where there is a choice? > > The innermost hit element with a title is the one you will see as a > tooltip yes. > >> eg the fruit all have title fruit but this isn't displayed in the >> tooltip. >> >> evidently one workaround for these issues is to include a transparent >> top layer, possibly shaped where necessary to the underlying parts. >> however this solution lacks elegance. > > The use of "event shields" (made of invisible rects for example) is > not uncommon in interactive svg content I've seen so far. > > Cheers > /Erik > > [1] http://www.w3.org/TR/SVG11/struct.html#UseElement > > -- > Erik Dahlstrom, Core Technology Developer, Opera Software > Co-Chair, W3C SVG Working Group > Personal blog: http://my.opera.com/macdev_ed >
Received on Wednesday, 2 July 2008 11:03:39 UTC