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

Tue Jul 6 09:52:41 PDT 2010

On Jul 6, 2010, at 5:54 AM, Antonio Gomes (:tonikitoo) wrote:

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

If it's a considered decision, I'm OK with it.
> 
>>> 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?

I'd resist adding this until we have a use case for it.

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

Got it. What you have sounds fine.

Simon