Re: Finished ISSUE-2364, ACTION-2834, Regarding Pointer Events on the Root

Doug Schepers:
> To resolve this issue, as discussed on the telcon and at the F2F,
> I have changed the description of pointer event processing to be
> more precise and separate different aspects; added definitions for
> 'pointer' and 'hit-testing'; and clarified that this spec doesn't
> define root-element event processing in embedded content, but that it
> will be defined in a future spec.

Thanks.  As requested, some comments (some picky some not):

  hit-testing
    The process of determining whether a pointer intersects a given
    graphics element, whether initiated by events such as ‘onmouseover’
    or ‘onclick’, or by movement of the underlying graphics element.
    Also known as known as hit detection or picking. See hit testing and
    processing order for user interface events and pointer-events.

mouseover and click events don’t cause hit testing to happen.  It’s the
actual pointer input that does (which itself will cause DOM events to
be dispatched).  Also onmouseover and onmouseout are event handler
attributes, rather than names of events themselves.

  pointer
    A pointer is a logical representation of a user-controlled interface
    interaction (such as moving an on-screen cursor with a mouse,
    keyboard, or other positioning device, or tapping a touch-screen),
    and functions as one or more points positioned at a specific
    coordinates within the viewport. A pointer may or may not have an
    associated visual representation, such as a cursor or arrow icon (in
    contrast to the pointer value of the ‘cursor’ property, which
    refers to a particular cursor style.).

I don’t think a pointer is a representation of an interaction.  It’s
more of a representation of something that lets you perform an
interaction.

  An element’s intersection area is initially based upon its rendered
  geometry (or rendering area), as modified by the value of the
  pointer-events property.

When is the intersection area not based upon its rendered geometry as
modified by pointer-events?  (If this is always the case, remove
“initially”.)  Also, this is not the case for text elements, say.
(Bikeshed: interaction area seems a better name to me.)

It seems like “rendered geometry” is something that needs a definition.
A naive reading might think that <rect width="10" height="10"
fill="black" visibility="hiden" pointer-events="all"/> has no rendered
geometry, since it isn’t rendered, but that will catch pointer events.
In the section defining pointer-events, it talks about the ‘“painted”
area’ of an element.  (Although clearly that should just apply to
shapes, not other elements like <image>.)

It seems like we need both a clearer definition of the “interactive
area” of an element, so that it can be referenced from the
pointer-events definition, and of how you go from a point to an
element – how you determine what the event target is going to be.
The definition of hit-testing describes it as a true/false result of
whether a point is within the bounds of the element, so I think we need
something else to say “choose the element latest in document order whos
interactive area contains the point”, or so (unless I missed this; I
don’t think this was present even before your changes).

  Note that the svg element is not a graphics element, and should not be
  the target of pointer events, though events may bubble to this
  element.

I would do s/should/will/ or s/should /can/ to avoid RFC2119
terminology, even if this sentence doesn’t look like one affecting
conformance.

  An element which is the proximal event target of a user interface
  event may have particular interaction behaviors, depending upon the
  type of element and whether it has explicit associated interactions,
  such as scripted event listeners, CSS pseudo-classes matches, or
  declarative animation event-ref declarations.

Forgive me for hating on your fancy words: but is “proximal” the right
term to use here?  I guessed its meaning was “nearby”, but it seems it
means “nearer”.  Nearer in what sense?  Is it “closer” to the user, as
in the top-most element?  I’m not sure that’s the right way to define
it, because a given user interface event doesn’t have multiple event
targets, it only has one: the top-most element whose interaction area
contains the point in question.  The nearer of a set of one element is
that one element.

  If the element has an associated title or description, such as a
  ‘title’ element or a hyperlink title attribute

s/hyperlink title/xlink:title/ if that’s what it is.

  If the element and the event type are associated with the activation
  or cancelation of declarative animation, and if no CSS property
  currently applied conflicts with the animation, the effects of that
  animation must be applied to the relevant element;

I’m not sure what it means for a CSS property to be conflicting with the
animation.  Should this item in the list simply say something like: if
the (element,event type) combination are referenced by an event-value
item in an animation element’s begin or end attribute, that the
corresponding begin or end instance time list has added to it the
current time plus or minus the specific offset?  (Simply, hah!)

  If the element is a hyperlink (e.g., it is a child element of an
  ‘a’ element), and the pointer event is of a type that activates
  that hyperlink (e.g. via a mouse click), and if the hyperlink
  traversal changes the context of the content (e.g. opens a different
  document, or moves the pointer away from this element by moving to
  another part of the same document), then no further processing for
  this element is performed;

s/child/descendant/.

That list of items in 16.5.2 Event Processing definitely looks better
than what was there previously, though.

Thanks for doing the action!

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 8 February 2011 03:01:01 UTC