W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes TPAC Tue 2012-10-30 PM II: Display Models, Animations

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 23:04:55 -0800
Message-ID: <50A34297.7040101@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

Display Models

   - Discussed splitting 'display' into multiple properties, particularly
     whether to split -inside and -outside display models into separate
   - Discussed discarding boxes vs. hiding them
   - RESOLVED: start css-display-3 as a new ED

   See draft at http://dev.w3.org/csswg/css-display-3/


   - Discussed interaction of simultaneous transitions and animations,
     particularly how that fits with the cascade.

====== Full minutes below ======

plinss: Any other items on agenda?
TabAtkins: display model?
fantasai: or paged-media
[discussion of what's left to discuss]

Display Models

   <leaverou> http://dev.w3.org/csswg/css-display-3/
   Tab reviews the draft with the WG
   Currently showing off display-inside/display-outside
   Showing off display-box (none-ness switch)
   stearns: Do you expect authors to use independent properties, or just
   TabAtkins: mostly shorthand, but in some cases would want separation
   TabAtkins: e.g. the SVG case discussed earlier
   stearns: imo the first two properties are too much noise for benefit,
            but third property -- certainly something we should do
   TabAtkins: The first two are mostly a matter of simplifying the spec's
              model of things
   TabAtkins: Our complexity ends up leaking into the [...[
   TabAtkins: e.g. keep having to add inline- versions of everything
   TabAtkins: But also adds some additional functionality
   TabAtkins: e.g. table-caption with flex layout inside
   TabAtkins: or table cells, which can only be blocks right now
   howcome: sympathize with Tab's attempt to make this coherent, but also
            Alan's concern about whether we need to expose this to authors

   fantasai: If splitting out display-none part, then the other part needs
             to go into some property
   Bert: Why is splitting out display-none useful?
   TabAtkins: So you don't clobber the previously-set display value --
              need an on/off switch
   fantasai: Going back, if we're going to split out 'display' type, and
             at any point going to split it further into -outside/-inside,
             should make that split now
   fantasai: otherwise will need two levels of shorthanding if we ever
             split it into -outside/-inside

   [Tab explains why splitting out is beneficial for layout models]
   antonp: Good example is flex items
   antonp: Didn't want to have anonymous box tree generation in order to
           have flex-item display type
   * scribe missed what Tab said

   plinss: What if I say table-header-group, and inside is block?
   TabAtkins: Think there needs to be an edit that such things compute
              display-inside to auto

   antonp: I think key thing here is not this conceptual level, but what
           Bert was trying to tell me the other night
   antonp: what does it really mean, for something to be an inline-block
   antonp: If inline-level, participates in an inline formatting context
   antonp: but not the same as a string of text; can't split across lines
   antonp: What's causing that special behavior?
   TabAtkins: The combination of inline-level and auto does special behavior

   howcome: If we just have the display, then we name things that make
            sense and don't give names that don't make sense
   TabAtkins: things that don't make sense to combine, you force inside to auto
   howcome: It's a lot
   TabAtkins: It's not a lot
   TabAtkins: ...

   howcome: Cascading things separately could be a problem
   TabAtkins: Forcing is at computed value time
   TabAtkins: There's 3 display-outside values: inline, block, and tabley things
   plinss: There are cases where you might want to toggle just the outside,
           e.g. just switch inline to block or vice versa, without affecting

   Bert: I had 2 reasons for dropping it
   Bert: Found out all combinations, that I was defining more, not less,
         with the split
   Bert: Other thing was, even found myself only using the 'display' property
   Bert: Regardless of naming, kept thinking in terms of display types as
         a whole

   Bert: Other issue wrt display...
   Bert: For flex, let it be a display type, mainly didn't think anyone
         would use inline-flex
   Bert: But grid, not convinced
   Bert: Grid element should just have a grid property
   Bert: it's a block, just like any other block
   hober: it's a block on the outside, it's a grid on the inside...
   plinss: when I went through grid proposal, felt the same way -- everything
           should be able to have a grid
   plinss: The difference here is, that MSFT model has ability for contents
           to push around the lines and size around the contents
   plinss: Can't do that otherwise
   plinss: while I think grids should be able to go anywhere
   plinss: think there also needs to be a way to have a grid that auto-size
           around things
   plinss: They're different.
   antonp: Another problem.. multi-col properties apply to block containers
   antonp: but once you turn it into multi-col by applying those properties,
           it's no longer a block container
   antonp: weird editorial cycle
   ChrisL: In SVG, ppl pick a random value when they're switching display on/off.
   ChrisL: It doesn't matter whether choose inline or block, for the SVG,
            unless you explicitly inherit down into something else
   TabAtkins: when we were talking about flexbox, you wanted ability to
              say an item is a flex-item, so that can wrap around  it
   TabAtkins: What model is used inside the flex item?
   TabAtkins: table? flex? block?
   TabAtkins explains cases where you want to mix models
   TabAtkins: Only reason display works ok right now is b/c outside values
              are just block and inline
   TabAtkins: Once we add another outside value, then the combinations will
   TabAtkins: Right now it's sane only because we have only two columns
   TabAtkins gives an example of <h1>, <table>, <p> put into a flexbox

<br until=4pm>
Scribe: sylvaing

   howcome: I think the list of odd cases is not long enough to justify
            the split
   tantek: I think the list is long
   tabatkins: today we have inline versions of a number of displays
   tabatkins: we may want a flex-item display value in the future
   tabatkins: but then we'd add 4 versions of flex item
   tabatkins: every new display outside type multiplies the combinations
   howcome: but not all these combinations make sense
   tabatkins: all these combinations exist today
   tabatkins: and it will keep growing as we add new layout modes

   tantek: does it make sense for these properties to cascade these
           properties separately?
   plinss: yes
   tabatkins: also we have some display-outside values that only take blocks
              inside right now but we could argue that they should support
              more e.g. table-caption
   howcome: but you still have to describe the combinations that don't work
   tabatkins: there are not that many

   antonp: ruby?
   tabatkins: that works similarly to table
   antonp: yes
   howcome: what's the issue with ruby?
   tabatkins: this is not in yet. everything except table-cell and
              table-caption force the inside to auto
   tabatkins: they only make sense in the context of tables; they're not
              fully independent i.e. they're not just display-outsides
   tabatkins: any new display mode we add would work the same; they would
              combine with everything
   antonp describes his proposal re: ruby
   <antonp> http://lists.w3.org/Archives/Public/www-style/2012Oct/0554.html
   tabatkins: we'd have display-outside: ruby-* then inside would be auto
   howcome: so will we say new outside values force auto?
   tabatkins: we would do it as needed
   antonp: you could argue all the display values for table were overkill;
           were 7-8 values for table necessary? would we do this again?

   bert: we also have run-in, this should be inline inside
   tabatkins: yes
   antonp: we're not trying to get rid of awkward cases; we're trying to
           enable independent toggling for many of the cases that make sense
   antonp: the purpose of this is not to remove the inherent complexity we
           already have
   antonp: just adding power to express things in a more flexible and
           powerful way
   bert: why add complexity ?
   tabatkins: because we are currently avoiding situations that are painful
              in the current model
   tabatkins: e.g. any new feature that requires adding a ton of display
              keywords is a turn-off
   ChrisL: an inside and outside is not that complex, is it?
   plinss: the common use-case is that someone is going to use the shorthand
           then override one aspect of it somewhere else.
   plinss: so the common use-case is not authors specifying both inside
           and outside everywhere
   tabatkins: we make it easier to add new values but at a lower cost

   tantek: I have run into cases where I wanted to only change the outside
           because someone already defined the inside
   tantek: I wanted to lay it out along other things e.g. using MQ turn
           some inline thing into block level for responsive design
   tantek: I just want to style the outside, not the inside
   tantek: this is a use-case
   antonp, bert: it's not just a matter of flipping the switch; you may
                 also want to adjust widths and other measures and that
                 will interact with the inside
   antonp: but there may be a way to do this negotiation using some of
           the new keywords in the sizing spec
   antonp: so I'm not sure outside/inside are fully independent
   tantek: for many inline blocks it would work with minimal work.
   antonp: tables, on the other hand, would be more complicated.
   tantek: yes, and we'll have more questions once people use this with
           real content. but in terms of utility and use-cases I think we
           have it.
   tantek: the hack I'm using right now is float; it's my display-outside: block.
           it's workable but not elegant or intuitive.
   Bert: but that doesn't give you the right alignment
   tantek: exactly!
   Bert: I still think you may need to adjust margins, padding etc.
   antonp: yes, but we can handle that
   plinss: and the author can change that but that's better than having
           to handle all the side-effects of switching to floats
   plinss: or you may have to change the markup, which is worse
   <tantek> here's an actual use-case where I had to hack floats to get
            the display effects I wanted where I think it would have been
            easier with display-outside and display-inside
   <tantek> http://tantek.com/xoxo-2012-directory

   tantek: I'd like to get this to a stage where we can get some implementation
           experience and iterate from there
   tantek: and yes, there will be things we do not expect
   tantek: but we should try to get there
   plinss: we'll also find new things that are really cool and would not
           be able to do in any other way
   howcome: I agree but I fear that some of the complexities that will
            appear will be implementation-specific hacks
   howcome: achieving interop will take time
   howcome: but I can see Tantek's use-case
   plinss: do we proceed with this or not?
   Bert: I think we have more important things to do...
   plinss: we're not deciding priorities
   tabatkins: is it OK to make it an ED?

   fantasai: display:none discards the element from the rendering tree;
             some of the values you have - contents - don't quite do that
   tabatkins: no it's not there, only its children
   fantasai: I'm not sure that is what authors actually want
   fantasai: is it the right place to have this control? maybe we need to
             rethink display-none; one meaning discard from the rendering
             tree, the other means that it's not in the rendering tree
             but it is preserved for things like counters
   fantasai: so you could hide a list item without renumbering your list
   tabatkins: I have issues in the spec for this
   plinss: objections to ED?
   RESOLVED: start css-display-3 as a new ED

Scribe: fantasai

   <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15242
   sylvaing: I believe it was the last F2F or the one before, we discussed
             the way animations affect the cascade
   sylvaing: an interesting issue came out of this bug is the interaction
             of animations with concurrent positions
   sylvaing: animations trigger during a transition
   sylvaing: do we treat the transition as if it runs in the background?
             pause it?
   sylvaing: not defined at all
   sylvaing: Not sure there's interop anyway
   sylvaing: essentially, you hover over an element, it transitions, halfway
             through an animation starts -- what happens?

   dean: we've implemented that the transition is still running in the
   dean: if the transition is still running, it picks up from where i
         would have been in the transition
   plinss: does the animation pick up from where the transition was?
   fantasai: This all seems kindof wrong to me. I don't understand why
             transitions don't win.

   plinss: Either way, still have same problem of one taking over from other one
   fantasai: [...]
   dean: Transitions aren't more important than animations b/c they operate
         on property changes
   dean: would be kindof weird for animation that's running, then a transition
         triggers.. does a thing, and then jumps back to the animation frame
   dean: My proposal is to follow what Webkit's done, which is transition
         is still running, events still fire
   dean: and I'm not sure what the spec says, wrt what to do with 0 or 100%
         keyframes, if they're missing
   plinss: if they're missing, would make sense to pick up from where the
           transition was, and if the 100% is missing pick up where the
           animation's at
   plinss: If the transition's running, and during the transition an animation
           fires, runs to completion, and leaves the property in a different
           state than what the transition would have done, had it not been
           interrupted, and the transition still has time left, where does
           the property go?
   plinss: does it go to where the property would have been if there was
           no animation?
   dean: ...
   dean: you should act as if animations could exist in a world where there
         are no transitions
   dean: in that case, we would always override and never pause that
         zero-length instantaneous transition effect
   dean: I'm not sure if we actually have any issues here, if people agree
   dean: I think maybe the spec has enough wording, provided we add this
         description of what happens for zero and 100% case

   dean: interesting question of whether missing from keyword should result
         in starting from transition point, or from transition start point
   dean: seems like it makes sense to start from transition point

   plinss: Suppose I'm animating a box's height through a transition over 5s
   plinss: halfway through an animation runs that wiggles it, and then leaves
           it where started
   plinss: transition continues
   plinss: would that jump from start point to where transition would have been?
   plinss: or transition resumes from where animation left it?
   plinss: The whole point of a transition is you don't want things do jump
   plinss: do you really want to introduce these jumps
   sylvaing: You have no discontinuity at the beginning
   ChrisL: would it make a difference if you freeze the animation?
   sylvaing: repeats when transition is still running...
   dean: Think the spec should say, calculate 0 or 100% and keep that forever
   dean: That saves us having to do 2 computations to figure out the style
   plinss: Agree it makes implementation crazy, but wrt author ...
   arronei: Maybe put a warning to authors, that if you animate and transition
            same property values, it will not be smooth
   plinss: If doing the right thing was reasonably simple and cheap, do
           the right thing
   plinss: but better to do something lame consistently on all browsers
   plinss: than to have inconsistency across browsers
   plinss: want the author to see right away exactly what ways things are
           messed up

   dean: what if you have CSS and SMIL animation on the same thing?
   dean: in webkit right now it pingpongs
   tantek: Is there an effort to unify CSS and SMIl animations?
   ChrisL: yes, it's called web Animations
   krit: ...
   krit: We came up with proposal that the attribute style, in svg, has
         the lowest priority of both style sheets
   krit: Then when we animate CSS property, describes before transition
         and animation
   krit: Therefore overrides SMIL animation
   krit: Already implemented in webkit and Gecko this way
   krit: can't tell about Opera
   leif: we have them now in Opera

   dean: I think our resolution is that transitions continue to run and
         still is overridden by animations wanted
   dean: Even if you're overriding the property
   sylvaing: If 2 completely different sets of properties, happen simultaneously
   sylvaing: Talked about ...
   sylvaing: We may want to have smooth transition back to ...

   fantasai interrupts:
   fantasai: San Diego we have a resolution that transitions happen last
             in the cascade
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0900.html
   plinss: It's not the transition rule that's causing it to transition now,
           it's because some other rule got applied, which is not overridden
           by the animation rule
   fantasai: This resolution says that if you transition and animate the
             same property at the same time, you don't see the animation,
             just the transition
   fantasai: The properties that are in transition are last in the cascade
   dean: you can't do that
   fantasai: I believe Gecko does
   sylvaing reads/interprets the minutes
   dean: Suppose I'm moving this box over 1s
   dean: At the same time I have an animation that moves the top value from
         here to here
Scribe: TabAtkins
   fantasai, dino: [discussion of example]
   <cabanier> jsfiddle example: http://jsfiddle.net/FALtu/

   dino: If the user wants to stop a transition, they put !important in
         their stylesheet.  But that won't stop an animations.
   dino: To stop animation, they put "animation: none !important;" in
         their user stylesheet to kill it.
   fantasai: No, if you have a property that is set to some value in
             the user!important stylesheet, that property can't animate.
             The user!important rule overrides the animation rule.
             Per the resolution that animations are below user!important,
             note above.
   sylvaing: It doesn't stop animations...
   fantasai: Yes, the animation still *happens*, but that property doesn't

   plinss: Now how does that relate to transitions?
   plinss: If the user has a !important color, how can that possibly
   Bert: They have two user!important rules.
   plinss: So the transition will still happen.  But that has no effect
           on an animation from the author.
   plinss: What does transitions in the cascade mean?  Transitions aren't
   fantasai: the "virtual declaration" that's in effect (dictating the
             value of the property at that moment from the transition)...
   fantasai: That declaration is the last thing in the cascade.  It wins
             over everything else.
   * dbaron is going to come back to the CSS room now
   plinss: So now we're flipping the case - transitions override animations,
           not the other way around?
   fantasai: Yes.
   plinss: Now the case is - there's an animation running, and something
           else happens that causes a transition.
   plinss: My color is pulsing from an animation, but then I hover, which
           changes it to black.
   plinss: So the answer seems to be that I transition *from the current
           animated value* (because that's the current computed value)
           to black.
   plinss: Then, if I stop hovering, I think that it should transition
           over to the current animated value, since the animation has
           continued to run this whole time.

   <cabanier> example of a transition during an animation: http://jsfiddle.net/FALtu/
   krit: Transitioning from the current animated value is very hard in
         SMIL.  It will be similarly hard to implement in CSS Transitions.
   [dbaron arrives]
   [we all update David on the discussion]
   dbaron: My pref is that if we want the animation to win when it's running
           with a transition, we should do that with something other than
           the cascade.
   dbaron: Just say that the transition disappears.
   dbaron: If it's the other way around, I don't think we need anything special.
   dino: I think animations should always trump transitions, with the
         exception of !important.
   dbaron: The thing is, it's very hard to make that happen.
   dbaron: It's hard to make a transition run when an animation is running too.
   dbaron: It's hard to make a transition start when an animation is running.
   * fantasai totally disagrees with dean

   plinss: [gives his pulsing color example]
   plinss: So should the transition even happen?  If it does, should it
           transition from the currently animated value, or the base value
           (ignoring animations).
   dino: The reason comes back to transitions being just property changes
         spread out a bit.
   dbaron: So do you think transitions should happen if the 'to' or 'from'
           is a user!important rule?
   dbaron: Like something that says "a:hover { color: pink; }"
   dbaron: If there's also a transition request for that property, does
           that transition happen?
   dbaron: In order to transition, the transition's "virtual rule" has to
           be higher in the cascade than the user!important rule.
   dbaron: So suppose you have an author stylesheet with
           "a:link { color: green; transition: color .25s; }"
           and a user!important sheet with
           "a:hover { color: black !important; }"
   dbaron: What happens?
   dino: It transitions to black.
   dbaron: Okay, so it either immediately changes or it transitions.
   dbaron: So with your answer, the transition overrides it.
   * fantasai thinks we should just accept that dbaron wins
   * stearns thinks that what you always think

   TabAtkins: If you go the other way (no transition from green to black,
              but a transition from black back to green), then that implies
              that you can *never* transition between two user!important
              values, because they *always* beat the transition.  Hopefully
              you see that's not very good.
   plinss: So I see no reason for it to not transition to/from black.
   plinss: And if there's another user!important rule that sets the color
           to something different in non-hover, it should transition those
           two colors as well.
   plinss: (author added the transition, but we're still respecting the
            user's colors)
   plinss: If the user didn't want transitions at all, they can add
           "* { transition: none !important; }"

   fantasai: Clarification. If I have at the author level, two color
             rules, one on hover one on non-hover.  That'll trigger a
             transition when I hover.
   fantasai: If I have an animation on the element as well, then the
             color rules of the animation, because they're at a higher
             cascade level, at every point in time override those
             previous two rules, and therefore no transition is triggered.
   fantasai: So that gets what dean wants: by default animations override
   dbaron: That's not actually how it works in Gecko, but I don't like
           Gecko's implementation.
   TabAtkins paraphrases what fantasai just said

   plinss: So you have an animation running.  Magical animation rules
           overriding all other cascade levels (besides transition).
   plinss: Now if I hover over it, the hover rule's declaration loses the
           cascade, so no transition happens.
   plinss: Now say the animation isn't running.  I have a long transition -
           a 5s one on hover.
   plinss: while I'm hovering, the transition is doing it's magical style rule.
   plinss: Now I trigger some other rule that starts an animation over the
           property.  What happens? What wins?
   plinss: What I think fantasai's model is saying implies that the animation
           happens, it runs, everything goes normally.  But the transition-created
           rule is still running at a higher cascade level, and so it overrides
           the animation's *effects* as long as it runs.
   plinss: To the implementation, transitions win, and everything works more
           or less statelessly.
   plinss: To the author, it kinda looks like the first-set wins, just because
           whether the transition starts or not depends on whether the
           animation is running.
   * fantasai wants to question one of plinss's assumptions here

   [dbaron is drawing out the cascade levels]
   <Bert> q+ to ask if state change triggers transition or property value
          change. If the latter, does the end of an animation trigger a
          transition back to the normal value?
   <ChrisL> to answer bert, transitions trigger on state changes in computed
            values; animations happen on top of that and do not trigger
            transitions or they would trigger hundreds of them
   <sylvaing> we already resolved that updates from animations or
              transitions do not trigger transitions

   dbaron: UA < user < author < magic-animation < author!important
           < user!important < UA!important < magic-transition
   dbaron: This is what Gecko does.
   dino: WebKit does something else.
   dino: In WebKit, magic-transition is higher than UA!important, and
         magic-animation is higher than that.
   TabAtkins: If you set a user!important property to something static,
              does that override the animation or not?
   dino: It does.
   TabAtkins: Then you have a contradiction.  Your behavior cannot be
              explained solely in terms of cascade.

   plinss: Can we action you to come back with examples of behaviors,
           and demonstrate why that makes sense from the user perspective?
   dbaron: I also definitely want to see what the behavior actually is.
   plinss: I think we all agree that transitions belong where they are
           (higher than all non-magic rules).
   plinss: We're disagreeing on what animations do.
   ACTION Dean to come back with an explanation of WebKit's animation model,
          and why it makes more sense for users.
   <trackbot> Created ACTION-523

   plh: Speaking on behalf of WebPerf, I'm here to make your life more complex.
   plh: We're working on animation too - requestAnimationFrame.
   plh: [explains rAF]
   <ChrisL> http://www.w3.org/TR/animation-timing/#requestAnimationFrame
   dino: I think rAF is significantly flawed because you can't use it for
         situations where you want a callback but not at the display rate.
   TabAtkins: You use setTimeout for that. rAF is just for things that want
              to key into the frame rate.
   plh: [more explanation of rAF behavior]
   <plh> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0040.html
   plh: FF runs rAF even on inactive tabs, despite it violating the spec.
        The reason is that they run it on the CSS Animations loop, and
        don't want to run them on two separate animation loops.
   <plh> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0043.html

   TabAtkins: Based on what we already agreed to write yesterday (regarding
              animation scrubbing and how the events get fired in various
              cases), once that's finished, this behavior will be easy to
   TabAtkins: Just say that CSS animations pause when the tab is inactive,
              and then scrub forward once it come sactive again.
   dbaron: I think right now, for background tabs we do exponential backoff
           on the animation timer.
   <plh> http://w3c-test.org/webperf/specs/RequestAnimationFrame/#processingmodel
   TabAtkins: I think that the spec actually doesn't *quite* forbid FF's
   TabAtkins: The first paragraph of that linked section says to queue rAF
              stuff whenever the tab isn't hidden. It doesn't say *not* to
              queue rAF stuff when the tab is hidden.

   Bert: I had an idea of what triggers the transition? A state change or
         a property value?
   TabAtkins: It's the computed property value
   Bert: So then if you have an animation that ends, and the property then
         reverts to its normal value, you should trigger a transition, yes?
   TabAtkins: Depends on our exact cascade model.  The one I favor would
              indeed do that.
   plinss: [explains a few other possibilities, given other models]
   Bert: I was just wanting to see if this was thought of.
   TabAtkins: Yeah, it was definitely brought up during the discussion
              today at some points.
   dbaron: The basic idea in Gecko is that we have a style with animation,
           and a style without animation.  Transitions are triggered by
           changes in the style without animation.
   dbaron: I took an impl shortcut that turns out to not be fully valid
           to that model.
   plinss: Okay, I just want to note for the minutes that we need to make
           sure that the behavior of transitions when an animations begins/ends
           is what we want, when we decide on the cascade model.

Meeting closed.

* tantek makes an aside query, do we have a media query selector for *actual*
   desktop displays/interfaces?
   E.g. http://alpinegarrison.com/images/movies/tron_legacy_unix_os.jpg
Received on Wednesday, 14 November 2012 07:05:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC