[webkit-gtk] hovering-over-link signal and HitTestResult in WebKit2 API

[Martin Robinson]

On Thu, Feb 2, 2012 at 8:37 AM, Carlos Garcia Campos <cgarcia at igalia.com> wrote:
> El jue, 02-02-2012 a las 08:21 -0800, Martin Robinson escribió:
>> On Thu, Feb 2, 2012 at 5:56 AM, Carlos Garcia Campos <cgarcia at igalia.com> wrote:
>> > WebKitWebView::element-hovered: signal that receives the mouse modifiers
>> > and a WebKitWebElement object.
>> >
>> > WebKitWebElement could be similar to HitTestResult in wk1 API:
>> This seems like a nice API, but I would still suggest using
>> WebKitHItTestResult for accuracy sake.
> And the signal name?

This is trickier in my mind. Perhaps mouse-hovered or something like
that? I don't have a strong opinion here.

>> This object is actually
>> something other than an element.
>
> The problem I see with HitTestResult (which is not exposed by other
> ports AFAIK) is that it makes me think there's a way to request a hit
> test, which is not possible (at least in this moment) in WebKit2.
> HitTestResult is the result of a Hit test, but here we are emitting a
> signal when the mouse mover over something (called element everywhere).

I also don't see how using a different name matters here, but you
raise an interesting point. The WebKitHitTestResult is exposed by the
WebKit2 C API and in WebKit1 by the GTK+, Qt and Wx ports. I don't
believe that not having the ability to conjure one from scratch is a
problem, but if it is, we can add this ability.

>> Notice here that it can be a selection. In WebKit a selection may
>> contains many elements. I believe this is also the case with Document.
>> An Element is a subclass of Node and a Document is a subclass of Node,
>> but Document isn't a subclass of Element.
>
> That's true because you are still thinking in WebKitWebElement as
> WebKitDOMElement, but it's not. A WebKitWebElement might contain a
> WebKitDOMNode if we manage to have DOM bindings in WebKit2 some day, as
> I suggested in my first email.

The name "Element" has a very loaded meaning in the context of the
Web. Especially when combined with Web into WebElement. I think it's
tremendously confusing.

>> We had the WebKitHitTestResult in WebKit1 as well.
> Because there's a method to request a hit test, so it makes sense to
> have a result.

It seems unusual that the only reason to have a HitTestResult in the
API is so that you can create one from scratch. Consider that it's
used both for context menus and detecting hover changes. Perhaps some
of the WebKit1 API designers can chime in here.

>>  Later, if we manage
>> to get the DOM bindings into the WebKit2 API, I think we can do what
>> we did in WebKit1 and make the actual element a property of the
>> WebKitHitTestResult.
> That's exactly what I said in my first email.

I'm glad we agree. :)

> WebCore uses mouseDidMoveOverElement. If the signal is called
> element-hovered, it sounds natural that it receives a WebitWebElement.
> But I agree it could be confused with a DOM element, even though all DOM
> API is WebKitDOMFoo, but still.

I have no answer for why the WebCore name is mouseDidMoveOverElement.
Perhaps we could ask. Note that I'm not saying that we must absolutely
use the name HitTest. I think we should just avoid names like Element,
Node, and Document.

--Martin