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 20:42:30 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <CD766461.A40%galineau@adobe.com>

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

>On Mon, Mar 25, 2013 at 7:02 PM, Sylvain Galineau <galineau@adobe.com>
>> On 3/25/13 5:21 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>>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>?
>Yes, definitely.

Which implies some hierarchy of top layers? In particular, with z-index
to whatever top-layer is currently topmost?

>>>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
>> by WebKit implementation', unless maybe you refer to Web Animations
>> I haven't looked at in a while.
>I mean the CSS Animations spec, and I'm referring to the way in which
>animations aren't started until the element generates a box, and are
>stopped and reset from the beginning when an element loses and then
>regains a box.

You seem to be referring only to the display:none cases; animations can
be applied to existing boxes without no loss/'regain' of a render box
e.g. you can just change animation-name or set animation-name to a value
different from its initial 'none' value.

>Whatever hand-wavey concepts we use to capture that concept in
>Animations, we'd use the same thing to capture the appropriate
>concepts for <dialog>, and whatever eventual author-exposed mechanism
>for the same positioning  scheme we come up with.

Animation start is currently defined in terms of when animation-name
computes. There is no connection with boxes or when they're generated
so you may be referring to concepts in your own mental model that I'm
having a hard time to follow. 
Received on Tuesday, 26 March 2013 03:43:03 UTC

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