RE: [svg11] test suite question

I agree with Cameron. I think the SVG specification should remove any
ambiguities about DOMFocusIn/Out and state that these events only have
to do with focus in the tab-navigation and forms sense (i.e., current
field to which keyboard events are dispatched) and not with mouse
over/out.

Jon 


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Cameron McCormack
Sent: Monday, January 30, 2006 1:59 PM
To: www-svg@w3.org
Subject: Re: [svg11] test suite question


Hi Anne.

Anne van Kesteren:
> It is unclear to me how the target in
>
<http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-script-hand
le-02-b.html>
> can be reached. Activation is clear more or less. I guess DOMActivate
should be
> dispatched when the <circle> is clicked. However, how does it recieve
focus
> events?

I think by moving the mouse pointer over it.  DOM 2 Events says this
about the DOMFocusIn event:

  The DOMFocusIn event occurs when an EventTarget receives focus, for
  instance via a pointing device being moved onto an element or by
  tabbing navigation to the element. Unlike the HTML event focus,
  DOMFocusIn can be applied to any focusable EventTarget, not just FORM
  controls.

Though I like this sort of sloppy focus in my window manager, I'm not
sure of its usefulness in SVG if you've also got the mouseover/mouseout
events.  IMO greater control over focus would be useful, especially with
editable text fields in SVG 1.2.  Wouldn't it be annoying if the focus
was removed from the text field because you moved the mouse over a
different element?  sXBL widgets also will need tighter control over
whether their shadow trees capture the focus or not.

[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-UIEvent

-- 
 Cameron McCormack			ICQ: 26955922
 cam (at) mcc.id.au			MSN: cam (at) mcc.id.au
 http://mcc.id.au/			JBR: heycam (at) jabber.org

Received on Monday, 30 January 2006 22:06:47 UTC