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

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

From: Sylvain Galineau <galineau@adobe.com>
Date: Mon, 25 Mar 2013 19:02:47 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <CD764EF6.A32%galineau@adobe.com>


On 3/25/13 5:21 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>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.

Can a <dialog> spawn another <dialog>?

>
>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.
>

Šwhat do you mean by 'captured by Animations'? If you mean the CSS
Animations 
spec, what language are your referring to? This sounds more like 'captured
by WebKit implementation', unless maybe you refer to Web Animations which
I haven't looked at in a while.

>  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.
>
>Thoughts?
>
>~TJ
>
Received on Tuesday, 26 March 2013 02:03:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:07 GMT