- From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
- Date: Tue, 19 Oct 2010 00:19:13 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Sylvain Galineau" <sylvaing@microsoft.com>
- Cc: "www-style list" <www-style@w3.org>
Bound positioning when some dependent element is bound with position of its anchor element is attractive of course. But I'd like to focus on tooltips as we've got some experience of handling tooltips and other popups in CSS. For example here is a screenshot of tooltip defined in CSS for the <span> element: http://www.terrainformatica.com/htmlayout/images/tooltip-balloon.jpg >> More use-cases would be helpful. > > Sure. > > 1) Positioning tooltips and other "popup" information on arbitrary > elements. (CSS currently fails for this, as you must either make the > popup a child in some appropriate position so you can rely on the auto > position, which is hacky and affects innerHTML et al, or use JS to > measure and manually set the position, which becomes invalid if the > element moves around on the screen. Tooltip positioning is a bit more complex that you've defined. 1) Tooltips behave as if they defined with position: popup[-window]. Usually browsers create popup elements (e.g. tooltips, popup lists in <select>s, context menus, etc.) in separate windows. That is why special quasi-positioning - position:popup; 2) Popup element when visible does not participate in content dimension calculation of its parent - it is taken completely out-of-flow of host document and always visible in full in topmost window. 3) Visibility of popup elements cannot be a static declaration. Popup element becomes visible on some starter event and disappears due to other event or condition. So that hypothetical position:popup; is rather internal value than what designer can use in CSS sheet. 4) Positioning of the popup element is relative to its anchor element position. I've seen many different positioning schemas in the wild but found that pretty much all of them can be defined by two 1..9 numbers. Meaning of 1..9 numbers is defined by NUMPAD layout on standard keyboard. So '8' is a center of top edge of a box and '1' is its bottom-left corner and so on. First number defines point on the anchor element border box and second number defines point on margin box of the popup element. UA shall try its best to keep these two points at the same screen location. Example: menu>li:has-child-of-type(menu) { click! : self.show-popup( element( menu ), 9, 7 ) ; } shows secondary popup menu on the right side of this menu item. Top of popup element is at the top of its anchor element. I believe that this is a superset of position-root-top|left|etc. properties that you've defined in http://www.xanthir.com/blog/b48H0 5) I have following popup specific pseudo-classes: :popup - is 'on' when the element is visible as a popup element. :owns-popup - is 'on' on anchor element - the one that owns the popup element. I am thinking about adding of these pseudo-elements too: .anchor::popup - access to popup element of some .anchor. .popup::popup-owner - anchor element of given popup element 6) Positioning of popup is always a recommendation - if popup is requested to be at bottom of its anchor UA is in its rights to position popup at top of the anchor. For example dropdown list in<select> can be shown at top of the select if it is at bottom of the screen. I have also property that defines animation style of popup creation/dismissal but that could be delegated to OS settings. Sorry in advance if all this above is far from topic being discussed. -- Andrew Fedoniouk http://terrainformatica.com
Received on Tuesday, 19 October 2010 07:19:51 UTC