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

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

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

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

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.

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.

~TJ

Received on Tuesday, 26 March 2013 18:37:06 UTC