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

On 3/26/13 10:27 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Mon, Mar 25, 2013 at 8:42 PM, Sylvain Galineau <galineau@adobe.com>
>wrote:
>> 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?
>
>No, why would it?  You can just use normal ordering to resolve this
>sufficiently.

If dialog 1 spawns dialog 2 and both give some element the same z-index
I'd assume the latter to be relative to the top layer created by dialog 2
I.e. these things stack up. (Note: I assume these are modal dialogs)

>I believe the <dialog> spec only allows multiple dialogs to exist at
>once if the sub-dialog is a descendant.  Otherwise, the second dialog
>waits for the first to be closed.  (At least, this is how modal
>dialogs work.  We're not yet trying to solve the styling of non-modal
>dialogs, as they require position anchoring.)
>
>>>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.
>
>You're mixing up the terms "applied to" and "start".  I'm referring to
>the latter.  The animation itself, as in its timer that determines
>what precise effect it has at a given moment, starts at 0 when the
>element gains a box, and restarts from 0 if the element loses and
>regains.

No, I am not mixing up anything. Animation start is, as defined today,
unrelated to boxes being 'gained' or 'lost', even though it may appear
that way in the display:none sub-case.

>
>Yes, there are other triggers that will start/restart an animation
>while the element has a box.

Indeed. And those triggers are the more common use-case so far.

>But I don't think that display:none is
>defined to force things into computing to their initial value, is it?
>Thus, there's an implicit extra trigger that pays attention to when
>the box is generated (perhaps in the form of when the property becomes
>"relevant").

My point is that this is undefined.We have resolved that animations stop
when you apply display:none and start again when you get out of it, but
we have never (afaik) defined the underlying trigger as being different
from when a regular change to animation-name's value on a display:block
element. Coming out of display:none, you'll definitely want to make sure
all the other properties of the element are in a current state before you
start animating; whether this style computation always occurs as a result
of leaving display:none is, afaik, undefined and up to UAs, just like
everything related to when properties compute.

My main point is that whatever you think Animations do that you can depend
on is not specified anywhere at the moment. I also know of implementations
that substantially disagree with your assumption, so beware. And, maybe,
file an issue against css3-animations.

Received on Tuesday, 26 March 2013 18:10:04 UTC