W3C home > Mailing lists > Public > www-style@w3.org > June 2013

[CSSWG] Minutes Tokyo F2F 2013-06-05 Wed PM III: Counter Styles, Cascade

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 27 Jun 2013 18:29:41 -0700
Message-ID: <51CCE705.7000003@inkedblade.net>
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

This archive was generated by hypermail 2.3.1 : Friday, 28 June 2013 01:30:10 UTC