W3C home > Mailing lists > Public > www-style@w3.org > March 2013

[css-positioning]? Handling <dialog> positioning - an update

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 25 Mar 2013 17:21:08 -0700
Message-ID: <CAAWBYDDrvg1MyvBHdvNeeMwfK95Yo_fCx3SDRUgMyxpEKOhvgw@mail.gmail.com>
To: www-style list <www-style@w3.org>
This is a quick update on our (Chrome's) current plan on handling HTML
<dialog> positioning.  We're currently planning to do unexposed magic,
but plan to expose this magic in the future, so verifying that the
group is okay with the magic would be a good thing.

The constraints were:

1. Upon opening a dialog, it should be centered in the viewport
(safe-centered if it's bigger than the viewport), and on top of
everything else.
2. If it's larger than the viewport, the user should be able to scroll
to see all of it.
3. The underlying page should also be scrollable.  It doesn't seem to
matter whether this scrolling moves the dialog as well or not.

The simplest, easiest way we've found to address these requirements
requires two special things:

1. The introduction of a "top layer" for positioned elements. Anything
in the top layer is removed from its containing blocks (it's
positioned as if it were a sibling of the root), and is z-ordered
above anything that's not in the top level.  Within this top level,
z-order is resolved as normal.

2. When the <dialog> is shown (to be precise, when it generates a
renderer), we generate an anonymous containing block for it.  This
containing block is automatically a flexbox, absolutely positioned in
the top layer, with top/left/bottom/right given appropriate values to
make it fill the viewport.  The <dialog> element itself has all
margins "auto" from the UA stylesheet.  This containing block is
thrown away when the dialog stops generating a renderer, and
regenerated fresh it is becomes shown again.

These two changes seem to address all the requirements, and introduce
a minimum of magic to CSS.  The concept of "generates a renderer" is
already captured by Animations, which start animations when the object
generates a box.  We couldn't avoid some aspect of magic positioning,
but we've isolated it to the undetectable containing block, and the
author still has full power to position the <dialog> within it, using
either flexbox or abspos, as they choose.


Received on Tuesday, 26 March 2013 00:21:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:09 UTC