Re: position: pointer

On Fri, Oct 12, 2012 at 8:04 PM, Garrett Smith <dhtmlkitchen@gmail.com>wrote:

> On 10/11/12, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:
> > I won't go into how bad accessibility/UX I think those are, but it's a
> > valid use case.
> >
> > That said, stationary tooltips (especially ones that contain interactive
> UI
> > elements) are better placed relative to the element they are tooltips of
> > (rather than relative to mouse position), and can already be achieved in
> > pure markup, I made a small jsfiddle to demonstrate this [1].
> >
> That's a different positioning scheme. It's a perfectly fine scheme
> for some cases (a small actuator). But it's not what was asked for:
> Positioning the object by the pointer (imagine it's a context menu).
> Also for tooltip(s), just one tooltip element is preferable.
>

For context menus, I'd recommend HTML5 contextmenu [1]. If it needs to be
styled customly, this is easier to achieve using JS and with better results
than if you need a tooltip that follows the pointer; you need JS to trigger
the menu anyway (unless you use `:target`, which would be a bit of an
overkill). I have yet to see a hover menu that is positioned relative to
the pointer rather than the parent element.

All in all, I'm not quite convinced `position: pointer` needs to provide
for hover menus, context menus, panels and alike. `position: pointer` is
intended for elements that are positioned relative to the pointer all the
time rather than once.


> For a large actuator, the tooltip won't be near the cursor. This new
> example demonstrates something other than what I asked for, and that
> was to display the tooltip (imagine it could be a panel, context menu,
> etc) relative to the pointer.
>
> ISTM that we have a slight miscommunication and what was said was
> buried. Point-by-point discussion can help facilitate better
> comminication (see also: http://www.idallen.com/topposting.html )
> (though it doesn't guarantee it).
>

Yes, I'm sorry for not using point-by-point, I usually do.


> Aside: Regarding the JSFiddle example, I noticed mootools was
> included. The example works without it. And now I see they try and
> force it on you; I see MooTools selected by default.
> http://jsfiddle.net/ I can't any good reason for doing that. Perhaps
> some sort of mootools dogma; religiosity combined with marketing ploy
> in collusion with JsFiddle, As if users need to be pressured to use
> such things.
>

Oh, weird, I wouldn't have even noticed that it inserted MooTools there,
there certainly isn't any need since I don't even have any JS going on in
there.

Cheers,
Jussi

[1] http://www.w3.org/TR/html5/the-menu-element.html#menus