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

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>
>wrote:
>> 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
relative
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
>>'captured
>> by WebKit implementation', unless maybe you refer to Web Animations
>>which
>> 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