[webkit-dev] Proposal: Rect based HitTest for a better touch experience

Mon Jul 5 22:46:15 PDT 2010

On Jul 5, 2010, at 7:35 PM, Antonio Gomes (:tonikitoo) wrote:

> * adds a Document::nodesFromRect method, exposing the functionality to
> the dom. It returns a NodeList with all nodes that intersect the given
> hit-tested area.

Is there a reason to use different terminology from the existing "elementFromPoint",
which would suggest that yours be named "elementsFromRect"?

> As-is nodesFromRect will be store all nodes whose area intersects the
> given rect hit test 'til it finds a node whose boundary encloses it
> completely. At this point hit test will stop at any node in the tree
> hierarchy. Sample outputs of nodesFromRect for an hypothetical rect X
> and a html Y are [<p> , <div>, <body>]. For another hypothetical rect
> Z and the same html Y, nodesFromRect might return [<span>,<div>]

I assume the nodes are listed in front-to-back z-order?

> In the later sample output, note that it did not reach <body> , whose
> boundary obvious intersects any possible given Z rect. That would
> happen if the <div> in case encloses the rect Z completely, and it
> would be the stop point for the hit test.
> 
> In Mozilla's implementation, nodesFromRect does not care if a node
> encloses the hit test rect completely or partially. The test will
> continue until the <body>.
> 
> What would be the preferable behavior for our implementation?

The latter behavior may actually make the method useful for things other
than hit testing, if that sways your decision at all. I can imagine page
authors finding it useful to be able to find out all the elements that are under
a given point (which in turn suggests that elementsFromRect with zero padding
should still find all the hit elements in z-order).

One thing that this functionality does not allow you to do is to find the *closest*
node to the given point that matches some set of criteria (like being clickable).
This might be a more useful thing for a mobile browser.

Simon