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

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

>On Tue, Mar 26, 2013 at 11:08 AM, Sylvain Galineau <galineau@adobe.com>
>wrote:
>> 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)
>
>This can be solved just by making <dialog>s be stacking contexts,
>which I think is a pretty sane thing to do.  No need for separate
>"layers".

That's where I was going. If dialogs create a top layer and dialogs can
spawn more dialogs then stacking contexts for each seem warranted.

>
>>>>>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.
>
>Okay, I think I might get what our disconnect is.  Are you trying to
>say that I'm overgeneralizing when I take the spec text which refers
>specifically to display:none and generalize it to the concept of the
>element not generating a box?
>
>If so, then I argue that my generalization is valid, as display:none
>is the only way to prevent an element from generating a box, and I
>assume that any future ways we may create to prevent an element from
>generating a box will act the same.

Sure. That display:none prevents boxes from being generated is true
independent of animations.

>
>> I also know of implementations
>> that substantially disagree with your assumption, so beware. And, maybe,
>> file an issue against css3-animations.
>
>Can you give an example?  Specifically, I'm asserting two things:
>
>1. If an element is currently display:none, and you set the animation
>properties on it, then when the element's display becomes non-none,
>the animation will start from t=0.

Yes.

>2. If an element is currently running an animation, and you set it to
>display:none and then back to non-none (flushing the styles in
>between, obviously, so no optimizations come into effect that would
>discard the first set), the animation will restart from t=0.

Yes.

>
>If any implementations are differing from this, I believe they're
>violating the spec, and I don't think anyone *did* differ from this
>when we made the decision that animations stopped during display:none.

You're asserting that the only way to conform to both the above is by
binding animation start to the creation or destruction of the element's
box(es). Conceptually, that's a good way to think of it though it's not
necessarily the way it works. But if you just mean to require something
to happen when a box is generated then why not just say that?

>
>If you thought I was asserting something else, then please explain
>what you thought I was asserting, which you thought you could
>demonstrate a violation of.

I can't really explain what exists in your own head. I can only try
and understand what you mean to depend on based on what you believe
to be there. Anyway. I think I know what you mean now; pointing
to Animations hindered rather than helped my understanding. Carry on...

Received on Tuesday, 26 March 2013 19:42:37 UTC