- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 23:04:55 -0800
- 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
properties.
- 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/
Animations
----------
- 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
shorthand?
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
insides
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
explode
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
Animations
----------
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
background
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
change.
plinss: Now how does that relate to transitions?
plinss: If the user has a !important color, how can that possibly
transition?
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
cascading.
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
transitions.
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
specify.
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
behavior.
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