W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: Positioned Layout proposal

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Tue, 19 Oct 2010 00:19:13 -0700
Message-ID: <BAY141-DS645DBDC96E0A45F888A38F85B0@phx.gbl>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:33 GMT