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

Tue Jul 6 05:54:42 PDT 2010

Hi Simon. Thank you join the discussion!

On Tue, Jul 6, 2010 at 1:46 AM, Simon Fraser <simon.fraser at apple.com> wrote:
> 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"?

We (dhyatt and I) originally considered that on irc, but for now it
was decided to keep it as nodesFromRect, specially because text nodes
are being returned, which is interesting for hit testing matters, in
fact. Do you see other objections against the naming, apart from the
terminology discrepancy with elementFromPoint?

>> 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?

They are, yes.

>> 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).

Exactly the point. For hit test matters, stopping as soon as it gets
fully enclosed makes total sense to me. On the other hand, as you
said, I bet there might be use cases like "give me all nodes under X,
Y, with padding W, H" (where they can be '0'). I thought about making
this "stop" an optional flag for HitTestResult or HitTestRequest.
Would it be acceptable?

>
> 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.

Right, as for mozilla's implementation, this method main goal is to
provide the list of nodes. Any post-processing over the resulting list
would be responsibility of the caller site, including calculating the
shortest distance rect, or consider the more frequently visited
elements (in case of links), etc.

-- 
--Antonio Gomes