W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

'exposed' was: event bubbling and focusHighlight

From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
Date: Wed, 2 Jul 2008 12:02:56 +0100
Cc: www-svg <www-svg@w3.org>
Message-Id: <1530827D-FB39-44D6-AFEE-B2EEF67C8BAB@btinternet.com>
To: Erik Dahlström <ed@opera.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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:39 GMT