- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Sun, 14 Oct 2012 22:00:07 -0700
- To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Cc: www-style@w3.org
On 10/12/12, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote: > 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: [...] > > For context menus, I'd recommend HTML5 contextmenu [1]. If it needs to be Interesting. Thanks for pointing it out. > 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. > OK. > 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. > Alright. The concept of keeping the element at the pointer requires positioning the element at the pointer repeatedly. Doing that once (and not updating) seemed similar to me. How does position: pointer interact with overflow? Consider also the viewport: When the element is positioned at the cursor, and it's width is clipped by the right edge of the viewport, and, assuming no horizontal scrollbar is currently present, what should happen: a) Element is clipped, scrollbar appears, allowing the tooltip to be scrolled to b) The element is clipped and no scrollbar is shown c) The element is automagically repositioned into the viewable area. -- Garrett Twitter: @xkit personx.tumblr.com
Received on Monday, 15 October 2012 05:00:35 UTC