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 <[email protected]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
