- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 27 Jun 2013 18:29:41 -0700
- To: "www-style@w3.org" <www-style@w3.org>
These are the official CSSWG minutes. Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*
Counter Styles
--------------
Discussed LC publication of Counter Styles and linking to i18n's
Counter Styles NOTE.
CSS3 Cascade
------------
RESOLVED: Close issue on how !important interplays with scoped styles;
current spec is good.
RESOLVED: Ok with current definition of 'default', remove issue,
but also clarify the spec and add examples.
Discussed adding a new keyword for 'inherit-or-initial' depending on
whether property inherits by default.
RESOLVED: Adopt A, C, D, and E from
<http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html>,
cascade as currently-specified in css3-cascade, plus magic:
animation on an element turns off transitions for the affected
properties. Re-evaluate after implementation experience.
RESOLVED: Take CSS3 Cascade to LC, with edits mentioned in minutes today.
ping HTMLWG especially, also notify WebApps, SVG, WAI
4 weeks LC period
====== Full minutes below ======
Figuring out the CSSWG agenda
-----------------------------
<glazou> http://wiki.csswg.org/planning/tokyo-2013?&#agenda
* jdaggett let the minutes record much mubbling
* plh and part of it was french mubbling :)
Counter Styles L3
-----------------
<r12a> http://www.w3.org/International/docs/counter-styles/Overview.html
<myakura> r12a, I see some Japanese counter styles in the Hebrew section...
http://www.w3.org/International/docs/counter-styles/Overview.html#hebrew-styles
<dbaron> http://dev.w3.org/csswg/css-counter-styles-3/
<dbaron> there's one issue listed in
http://dev.w3.org/csswg/css-counter-styles-3/#ethiopic-numeric-counter-style
Discussion of whether to publish Counter Styles as LC
<dbaron> want to link to r12a's document, which is to be published as a note
Richard posts the i18n note wrt @counter-style rules for various scripts
glazou: should we give people a few weeks to review
fantasai: we already did that
<dbaron> I'm fine with going to LC, though I'm really not sure how high
of an implementation priority this is for anyone.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013May/0757.html
<dbaron> ... css-counter-styles-3 to Last Call, ask for review from HTML,
i18n, ... oh, wait, we resolved to go to LC last week
* fantasai was on break most of last week
CSS3 Cascade
------------
<TabAtkins> http://dev.w3.org/csswg/css-cascade/#cascade
TabAtkins: This is in section describing how levels of things are handled
TabAtkins: We inserted Scope in the middle here
TabAtkins: Scoped style sheets always win over unscoped styles
TabAtkins: Scoping something further down in the document overrides scoping
rules further up in the document
TabAtkins: Question is, does this sound sufficient for a spec defining this?
TabAtkins: Think it is correct
fantasai: By default, inner scopes win over outer scopes
fantasai: But for !important rules, order is reversed
fantasai: Outer !important rules override inner !important
dbaron: Other alternative is for inner !important to win over outer !important
heycam: I think the current spec is a nice parallel with how origins work
fantasai: I think this gives !important a useful purpose in negotiating
rules between inner and outer scopes
fantasai: So somewhat prefer this behavior
TabAtkins: Seems from heycam that the spec is clear enough
Bert: Why have scopes be special, why not have it same as ID selector
glazou: I proposed that several times, was turned down
dbaron: Not the same is because you want rule in inner scope to beat
rules in outer scope, and if you treat them as both +ID, they
will intermingle
Bert: That's what I expect
dbaron: That's not what authors expect
TabAtkins: Point is that scoped rules apply only to your bit, and can
have short, simple selectors
TabAtkins: Lends itself to lower-specificity selectors
TabAtkins: Rules that apply to whole document tend to be more verbose,
more specific
TabAtkins: Want the simpler scoped rules to still override document-wide,
more-specific rules
Bert: But adding new concept
glazou: It's similar to adding a 4th argument to specificity
Bert: span.foo { blue } vs. scoped span { green }
Bert: Expect <span.foo> to be blue, not green.
dbaron: Expect it to be green
glazou: Last time we discussed this, the painful bit was only adding
dynamically adding styles [?]
TabAtkins: From author feedback over long period of time, because
specifying things defined in HTML for awhile, this was the
most intuitive behavior for authors
plh: Not implemented though, so haven't played with it.
RESOLVED: Close issue on how !important interplays with scoped styles
<br type="break"/>
TabAtkins: Continuing with 'default' keyword
<jdaggett> reference url?
<jerenkrantz> http://dev.w3.org/csswg/css-cascade/#default
dbaron: I had initially proposed default as something else, as initial/inherit.
Still would like that behavior.
TabAtkins: The reason I don't want to do that, doesn't do what authors want
TabAtkins: E.g. want "default" to mean "display: block/inline" depending
on whether <p> or <span>
dbaron: Not always. E.g. reset stylesheets want my behavior
TabAtkins: Don't think we need to cater to reset style sheets
fantasai: Could add special ability to 'all' shorthand, 'all: initial inherit'
dbaron: The other issue with this definition of default is that it's a
decent amount of work to implement
TabAtkins: Won't disagree with that
SimonSapin: Think it requires keeping around multiple specified values
TabAtkins: Don't have to keep things around, just might need multiple passes,
and just for elements it shows up on
SimonSapin: Isn't that similar perf cost with variables?
dbaron: It can be done without that perf cost
TabAtkins: I don't really want initial-or-inherit. No use case for it
dbaron: Use it internally a lot
dbaron: e.g. Web Components style reset
dbaron: Think that basically is equivalent to all: initial-or-inherit
TabAtkins: Given that those don't have any UA style rules anyway...
I think that's equivalent to 'default'
heycam: want s/continues/repeats/ ?
TabAtkins clarifies what default does
ACTION TabAtkins clarify what default does
dbaron: Putting !important and normal together makes it harder to implement
dbaron: Implementation I would take would do the wrong thing for user
!important and ua !important
dbaron: Current spec, user !important rule says go use the author styles
dbaron: But if no author styles, don't use user styles
TabAtkins: No, no, we only glom together all the author styles.
TabAtkins: You still keep user as an origin level
dbaron: Ok, that's fine
dbaron: But make it clearer
fantasai: We could put in a simplified cascade list, just to make it
more obvious
fantasai: Any other concerns with default?
fantasai: Do we want an initial-or-inherit keyword?
TabAtkins: I suggest using actually 'initial-or-inherit'. Want to steer
authors to 'default', since that's usually the right answer.
dbaron: Would like to see a keyword for that
Bert: Would like to understand better what this is used for
TabAtkins: You use it in most use cases for dbaron's examples, except
this is the better answer in most cases
TabAtkins: For a use case, sometimes it's much easier to create positive
selectors than :not() selectors, and wipe out what you had before
TabAtkins: Point is to wipe out whatever author has done
TabAtkins: This is better because it respects user styles
TabAtkins: And UA styles
TabAtkins: Most authors don't understand difference between initial value
and UA default value
TabAtkins: This lets you not worry about that
...
plinss: This removes your rules.
TabAtkins: Not sure what you're objecting to, what you're asking for is
exactly what this does.
Bert: You said it's easy to specify a generic rule, and override a specific case
Bert: span { color: green; } span.foo { color: default; }
Bert: Then I get inherited
TabAtkins: That's what you get, unless user or UA says something
TabAtkins: Let me show different example
TabAtkins: User says wants links are bright blue
TabAtkins: Author styles links purple, except some links with class should
use default colors
TabAtkins: If you use 'initial' or 'inherit' to wipe out author rules,
the colors will reset to black.
TabAtkins: Doesn't go back to blue.
Bert: Why would I want user's rule
Bert: I don't know what they are
plinss: That's the point
TabAtkins: This goes back to "whatever style would be without my influence"
Bert: Think examples would be good
fantasai: Better example would be paragraphs. By default, have 1em margin
on top and bottom.
fantasai: If I styling thing, and want to go back to the default styling,
would ask for 'default'. Gets back to 1em margin.
fantasai: If said 'initial', then would set margins to zero.
Bert: I'm not convinced, but if you can get some examples in there, would help
<leaverou_away> Can you help here?
RESOLVED: Ok with current definition of 'default', remove issue,
but also clarify the spec and add examples
fantasai: Suggest inherit-or-initial
plinss: reset?
TabAtkins: Want it to be long an annoying
TabAtkins: Using 'default' for this because already reserved, and does
more or less what was intended for that value.
Cyril: Question wrt inheritance
Cyril: First paragraph, 2nd sentence
[... wordsmithing ...]
<dbaron> "unless the cascade results in a value" -> "when the cascade
does not result in a value"
Cascading of Transitions and Animations
---------------------------------------
<stearns> http://www.w3.org/TR/2013/WD-css3-cascade-20130103/#cascade
TabAtkins: Order in css3-cascade matches Gecko behavior. Apparently
WebKit's behavior can't be explained in terms of cascade
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html
dbaron: There were pieces of each behavior that was considered crazy
and unimplementable
dbaron: Made progress towards acceptable behavior for this during special
meeting
dbaron: Wrote up in this message, which I have long since forgotten
dbaron: This message actually has transitions at a different point in
the cascade, but agrees with cascade wrt animations
fantasai: Does this mean that you can never transition !important values?
dbaron: It means that if you change something to !important, it will
not transition
dbaron: But if you change something from !important, might get a transition
fantasai: What if both are !important?
dbaron: No transition
fantasai: Don't like that.
dbaron: We all agreed that we want animations to override transitions,
and that we want !important to override animations, and
dbaron: now proposing that transitions override !important rules?
plinss: I think in Lyon we talked about animations not causing transitions
shane: I don't think we're asking that transitions override !important,
just that they be able to transition
fantasai: Think animations win over transitions because the two rules
transitioning are lower than animations
dbaron: Could introduce some magic
dbaron: Could say that if you have an animation running, any transition
rules for that property don't apply
dbaron: Not sure that works, because we have to consider inherited properties
dino: I think in our discussion we got to that point and then gave up
dbaron: Gave up on starting transitions
TabAtkins: What is the inheritance problem? Is that #3?
dbaron: Say you have animations/transitions on color
dbaron: Have a currently running transition on the child, and start an
animation on the parent
dbaron: nevermind
dbaron: Nothing in the cascade will help there; you just lose
dbaron: transition will keep running on child, we're ok with that?
TabAtkins: The effects of animations can never cause a transition,
including inherited effects of animations
plinss: Could have set value of child, that gets unset,
plinss: And then goes back to inherited, but that value is animating
dino: Bad example was parent and child with transition set up for color
dino: But child has color inherit
dino: You transition parent. What happens to child? When does its
transition start?
dbaron: What my proposal does for plinss's question...
dbaron: What the model I proposed does, if you have an override on the
child that you remove such that you now inherit an animating
value from the parent
dbaron: This wouldn't produce a great result, would cause transition
to go to animating value at the time the transition started,
and when completed, would jump to wherever it would be
dbaron: Model I was proposing is that mechanism by which we prevent
animations from triggering transitions, when you decide whether
to transition you look at animations as they are at the current
time
dbaron: So never comparing to animation at a different time
dbaron: So when there is a style change that is not animation-triggered,
you need to get your animation style up-to-date first, before
figuring out whether to start transitions
dbaron: And that was a defined way of describing interaction between
the two.
fantasai: Have a question, may or may not make sense.
fantasai: would it work to solve the things we want
fantasai: if we went with the cascade that's in gecko
fantasai: But said that a transition never starts if the start state
or the end state is an animation
TabAtkins: Or is produced by an animation via inheritance.
dbaron: Produced by animation via inheritance, say you have font-size
animating, and width in em units
dbaron: Tracking what's caused by an animation is very complex
plinss: Thing about this that bothers me
plinss: Talking about a lot of edge cases, cause lots of discontinuous
jumps when animations/transitions applied
plinss: Understand some implementations may not be able to avoid jumps
plinss: But certainly don't want to require them
plinss: [...?]
dbaron: One concern wrt that kind of thing, we tend to as a group want
to gradually narrow possibilities
dbaron: But some of those gradual changes might trigger a rewrite in
certain implementations
plinss: Then get it right the first time
dbaron: Need a description of what the right behavior is
plinss: Transitions should always be smooth
dbaron: start value and end value for transition
dbaron: Are you ok with start value is always static, but end value
might be animating
fantasai: ?
TabAtkins: Start state is something specific, end state is inherit
TabAtkins: Parent was running a thing, and now inheriting animated value,
so transitioning towards moving target
TabAtkins: Are we ok with tranistioning towards a moving target?
dino describes WebKit's behavior, which is bad, which chains transitions
together
* fantasai q+ to ask about #5 and em units
[discussion of this bug]
<dbaron> you may recall
http://lists.w3.org/Archives/Public/www-archive/2013Jun/att-0030/x2_10c92e9a.jpeg
from Tucson
TabAtkins: I think I'd be ok with either dbaron's model where inherited
animation or transition values don't kick off new transitions
on the child, but do move endpoint of running transition
TabAtkins: Or, I guess proper implementation of Dean's model, where they
do continually kick off transitions, but values are only 1
frame apart in transition, so transition end won't be detectable
dbaron: It's detectable due to TransitionEnd events
Rossen: What you see as a user, you'll see color transition from green
to blue (looking at point 7) over 2s
[ See http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html ]
Rossen: then detransitioning from blue to green over 10s
...
Rossen: so proposal was for #a and #b t transition over 2 and 10 s,
respectively
* fantasai lost example explanation
plinss: Would argue from user's perspective, behavior that user expects
is that #b will transition from green to blue over 10s
plinss: at the same time #a is transitioning over 2s
dbaron: There's another problem
dbaron: I think user expectation is that whichever time is longer wins
dbaron: If you swap the times, especially when one is unnoticeable
plinss: I think if you swap the times, user will expect #a to transition
over 10s and #b over 2s
plinss: IMO #b's behavior should not change based on whether #a has a
transition or not
dbaron: Other way to frame problem, don't want a discontinuity between
no transition at all vs. very short transition (e.g. 10ms),
that lasts longer than 10ms
rossen: Transitioning independently
dbaron: What if you swap times and put longer time outside?
plinss: irrelevant
dbaron: The thing is, default for transition not happening is time is zero
dbaron: The only thing that makes the transition happen is the time
dbaron: If #a has a long transition and you change from #b from 0s to 10ms,
that drastically cuts the time of #b's transition
dbaron: Rules could come from different parts of cascade, e.g. box and
button inside box, designed to have independent transitions
jdovey: [...]
TabAtkins: I think your model works for this, dbaron
dbaron: No, don't yet know of a model that works for this
TabAtkins: his model is if you inherit a value from your parent, and that
value is produced by transition or animation, it will not start
transition, but existing transition will still update its
endpoint to that value
TabAtkins: ... no, won't start. Nevermind
* Rossen and Peter are arguing that users expect
#a:hover, #a:hover > #b { color: blue }
dbaron: When I proposed that, just thought of it for animations, not
transitions
dbaron: if you start applying to transitions, too...
TabAtkins: A change from a static value to an animating value,
will kick off a transition
dbaron: you don't have that info
...
plinss: In this example, when you start/stop hovering, both transitions
start simultaneously
plinss: The short transition will have end point of blue
plinss: And long transition's endpoint, over first 2s, will transition
from green to blue
TabAtkins: In order to say endpoint is changing, have to know that
endpoint is coming from transition
TabAtkins: But that's not updating endpoint, it's resetting transition
counter
plinss: Don't need complex data flow analysis. Just tag all the transitions
[...]
dbaron: If you're kicking off multiple transitions at the same time,
need to recompute style twice for each transition you're kicking
off, possibly for entire subtree
plinss: Problem is transitioning for something changed via inheritance
plinss: Because you're inheriting result of a transition
dino: Similar problem with width in ems
TabAtkins: Can't just track inheritance
...
TabAtkins: Think reasonable model is that every single computed value
change triggers transition
plinss: So I have clarification ...
plinss: If in this case, the font-size #b does not have a transition on it
plinss: #c has transition on width.
plinss: Is width going to transition?
dbaron: Yes
plinss: The 10ems didn't change
plinss: the specified value didn't change
fantasai: transitions are based on computed value
dbaron: This is the list of testcases that I proposed we not care about
<Cyril> equivalent example in SVG: http://jsfiddle.net/7WsP2/
dbaron: Meaning, some of these will do weird things, and authors will
just get what they deserve
TabAtkins: So we go back to the earlier idea: use the cascade origins
as defined, but say that a running animation turns off
transitions on the affected properties.
TabAtkins: If you :hover an element, and that starts an animation,
and the animations' first value is different from the old
value, will trigger a transition
TabAtkins: Which, if it's shorter than the animation, will be hidden
by animation (but not otherwise)
Rossen: In all of these cases, when transition is longer than the animation,
the end tail of the transition [...] almost the same value,
so visually in lock-step with animation
dino: Think point B is significant change from WebKit
dbaron: Was just proposing to modify point B with magic
TabAtkins: With animations turns off transitions magic?
dbaron: Sounded like what we're moving towards
dbaron: B would then be what Cascade then has
TabAtkins: If transition is kicked off on different property via computed
value linkage, will still trigger transition.
TabAtkins: Something will happen, will be well-defined answer, but we
don't care what happens
dino: And authors will be so confused, they won't know what went on
TabAtkins: Proposal is Adopt A, C, E, and D, and use cascade's ordering
plus animations turn off corresponding transitions magic
fantasai: I *think* that sounds alright
plinss: That precludes a lot of situations we might want, like transitioning
to an animated state
fantasai: We talked about that in Lyon, and I was convinced we don't want to
tackle that right now, because we don't have rate-based transitions
fantasai: And getting those kinds of transitions to work well requires
more sophisticated tools than just time-based transitions
fantasai: I think that's something we could add later, maybe with an
'animation-transition' property or something. :)
dino: David, when do you think you'll start testing this?
dbaron: No idea
TabAtkins: Shane, you said Blink's changing animation stuff?
TabAtkins: Oh, well why don't you implement this?
shane: I'd say, I'd be surprised if we didn't have something by the next
F2F meeting
TabAtkins: So plan for Paris to have feedback from us
shane: Some concern wrt changing behavior, but does seem to be fairly
edge cases.
dbaron: A bunch of this requires edits to Transitions, particularly to
places where spec is very vague
dbaron: If we resolve on this, I'd make those edits
Proposal: Resolve on those edits, then re-evalueate after implementation
experience
RESOLVED: Adopt A, C, D, and E from <http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html>,
cascade as specified in css3-cascade, plus magic:
animation on an element turns off transitions for the affected
properties. Re-evaluate after implementation experience.
dbaron: For Transitions, only one other issue. Tab has had an action
to write a demo for last few F2Fs.
TabAtkins: Ok, I will make a demo tonight!
plinss discusses CR strategy
plinss: I'm happy to go to CR with our best guess of what we think will
stick. We can bounce back to LC to fix things. Implementation
experience is what CR is for.
dbaron: Would write several screenfuls of At-Risk text
dbaron: But ok
plinss: Would like to leave this F2F with both specs going to LC
TabAtkins: Ok, so this means no change to Cascade.
TabAtkins: Which closes all the issues on Cascade.
<dbaron> I'm happy moving cascade to LC.
TabAtkins: How do people feel about going to LC?
RESOLVED: Take CSS3 Cascade to LC, with edits mentioned in minutes today.
ping HTMLWG especially, also notify WebApps, SVG, WAI
4 weeks LC period
Cyril notes an inconsistency in the definition of "cascaded value",
which needs to be fixed
Received on Friday, 28 June 2013 01:30:09 UTC