W3C home > Mailing lists > Public > www-style@w3.org > August 2017

[CSSWG] Minutes Paris F2F 2017-08-02 Part I: CSS Timing, CSS Counter Style [css-timing] [css-counter-styles]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 27 Aug 2017 14:56:01 -0400
Message-ID: <CADhPm3tGT-NmA57Rne5W60FxVbY1wV6xBrMNtBm0zKXs7MOpZg@mail.gmail.com>
To: 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.

CSS Timing

  - RESOLVED: Rename CSS Timing Functions to CSS Easing Functions,
      shortname: css-easing, to accommodate future use outside
      animations (e.g. for color transitions in gradients)
  - RESOLVED: Renames frames() to steps(), argument names TBD.
      - The options names will be decided later in the F2F.
        Current suggestions include:
          1) distribute and justify
          2) distribute and stretch
          3) space-evenly, space-between
          4) center, stretch
          5) both, neither
          6) trim-start, trim-end, trim-both, no-trim*
          7) short, long
          8) include, exclude

CSS Counter Style

  - RESOLVED: Wrt request to compute missing counter styles
              to 'decimal', no change to CR; revert the change
              to the Editor's draft. (This is because it would
              require recomputing styles if a new @counter-style
              rule is appended.)
  - RESOLVED: The language of a counter is computed based on the
              language of the element that the counter applies to at
              the point of retrieval.


Agenda: https://wiki.csswg.org/planning/paris-2017#topics

  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Amelia Bellamy-Royds, Invited Expert (Phone Only)
  Brian Birtles, Mozilla
  Bert Bos, W3C
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Rob Flack, Google
  Daniel Glazman, Disruptive Innovations
  Koji Ishii, Google
  Dean Jackson, Apple
  Ian Kilpatrick, Google
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Jack Moffitt, Mozilla
  Francois REMY, Microsoft
  Melanie Richards, Microsoft
  Florian Rivoal, Vivliostyle
  Simon Sapin, Mozilla
  Till Schneidereit, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Surma, Google
  Jet Villegas, Mozilla
  Greg Whitworth, Microsoft

  Jihye Hong, LG Electronics
  Dael Jackson, Invited Expert
  Chris Lilley, W3C
  Simon Pieters, Opera
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Lea Verou, Invited Expert

Scribe: iank

CSS Timing

  Rossen: So lets start with css timing.
  astearns: Lea might call in later.
  Rossen: Brian can you cover those.


  birtles: The first issue should be easy, spec - css timing
           functions, there is interest in using those functions in
           other specs, e.g. gradient stops
  birtles: css-easing-functions, shortname: css-easing
  birtles: Does anyone have any other suggestions for the name for
           renaming the spec?
  Rossen: Everyone one happy with those names?
  <tantek> not happy with the name but not going to object to any
           bikeshedding. name feels awkward and no idea what it
  birtles: shortname should be css-easing
  dauwhe: Easing doesn't seem obvious to see, an animation term?
  birtles: I think it still makes sense in gradient stops.
  glazou: I think that only English speakers would get it.
  <tantek> I don't think even native English speakers will get it
  <tantek> feels like a very "insidery" term
  <tantek> but I have no alternatives to suggest :(
  Florian: If you use powerpoint, etc, you've probably used ease-in/
           out and from there you can work it out?
  <jet> http://easings.net/ shows some examples

  <tantek> is there a github issue for this?
  <astearns> https://github.com/w3c/csswg-drafts/issues/1577

  birtles: In web animations the property that uses that function is
           called easing.
  Rossen: Parametric functions.
  birtles: Just the short name is css-easing
  fantasai: css-interpolates?
  birtles: interpolates has a very different meaning in animations.
  fantasai: "CSS Transition Functions" seems the most easy to
  Myles: What these functions are used for today?
  fantasai: Animations.
  Rossen: Transition functions sounds pretty easy

  <tantek> I agree with
  tantek: quoting lea - Progression is an everyday word, but easing
          is specific to animation
  birtles: progression doesn't suggest an easing function, fwds vs.
  dino: Easing is the industry term...
  fantasai: I think css-progress is reasonably straightforward
  dino: That seems too generic.
  * fantasai thinks its fine.
  dino: I think understanding terms, is least of worry.
  Florian: If this is a confusing term, which would make you believe
           something else, it would be a problem, but merely
           unfamiliar is OK.

  Rossen: Can everyone live with easing functions?
  <tantek> -0
  * fantasai prefers css-progress to css-easing, doesn't mind what
             the title is tho

  RESOLVED: Rename css-timing-functions to css-easing-functions,
            shortname: css-easing

Name for frames() function
  Github: https://github.com/w3c/csswg-drafts/issues/1301

  birtles: So we specified a frames() timing function, makes sense
           for a usecase, animation that has discrete frames, and
           the start and end of the animation doesn't match, and the
           animation repeats.
  birtles: And for that use-case, frames() is a very good way of
           describing the timing, very obvious name, the counting,
           the number that you put in that function is the number of
           frames, unlike steps() where you count the number of
  birtles: My concerns with frames, is
  birtles: 1) very good in that context, not suitable in other
              contexts, e.g. not a good name for gradients.
  birtles: 2) Having a different function name for something very
              similar can be confusing, e.g. frames() to a css
              transition, has almost identical result to steps()
              timing function.

  birtles: Likewise there has been a proposal for a 4th type of
           timing function where ... jumps happen at both ends of
           the interval.
  birtles: If we introduce that (seems likely) we'd do it as an
           extension to steps.
  <fantasai> Illustration of the 4 options:
  birtles: Means we'd have 4 timing functions, 3 named steps, one
           frames(), seems inconsistent.

  birtles: Also frames() has bad discoverability, within devtools,
  birtles: if you have a steps() timing function, and doesn't quite
           look right, you'd just try and change arguments in that
           function, not easy to "find" the frames() TF instead.
  birtles: Concerned that they wouldn't discover frames();
  birtles: and then would have to use a different way of counting.

  birtles: My preferred way of doing this would be to extend steps.
  birtles: Even though we know that way of counting isn't ideal
           for the particular use case of a repeating frame-based
           animation that doesn't go back to where it starts.

  Rossen: So looking at the community twitter that Rachael did,
          frames() was solidly a preference from designers.
  fantasai: They are only concerned with what they do in isolation,
            not considering the need for consistency with the rest
            of CSS.
  fantasai: I agree with birtles points, agree that its easier to
            learn the set if its an extension to steps() instead of
            a new function, (frames())
  <fantasai> Was pointing out that polling people for their
             preferred syntax for that particular use case isn't
             going to take into consideration the interaction with
             the rest of the system, which is our job here in the WG.
  <fantasai> For people who want a function to do the one thing that
             they're trying to do, yeah, frames() might be nicer.
             But in general people have to learn more than just the
             one case
  <fantasai> and then for almost the same but not quite cases, they
             have to switch to steps()
  <fantasai> which doesn't seem very helpful

  birtles: If you are animating a spinner, and its rotating, you'd
           want a steps TF, if you use frames() it'll double the
           length of the other points.

  Rossen: So the current name in the spec is steps()?
  birtles: No frames()
  Rossen: Any other opinions? otherwise can resolve and move on....
  Rossen: No?
  Rossen: Any objections to renaming frames() to steps()?
  birtles: We'd still need to work out the name of the argument.
  birtles: Some of the proposals have been distribute.
  astearns: We could resolve on using steps, instead of frames, and
            work out param names separately.

  fantasai: <showing examples on github issue>
  fantasai: <https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203>
  fantasai: These are the four options under consideration for this
            set of timing functions. The first two exist already,
            the second two are proposed.

  Rossen: Are there any objections to renaming frames() to steps()?
  fantasai: In favour.
  <astearns> +1
  RESOLVED: Renames frames() to steps(), argument name TBD.

  fantasai: The next thing is that we have the 'start', 'end'... we
            need two more keywords.
  fantasai: We need to be clear of the distinction between the two
            new keywords.

  fantasai: Proposal to use the space keywords, which we use for
            distributing space, e.g. 'space-between', 'space-evenly'
  fantasai: Could also use 'space-around'
  <astearns> inside/outside, inclusive/exclusive also mentioned
  fremy: space-around only has half of the space....
  fantasai: We could space-* keywords, could use another word other
            than space?
  birtles: Could drop the space- prefix, e.g. between, evenly, etc.
  dino: I'd prefer that anyway, we are going to have to look this up
  fantasai: At least you've learned alignment, then we can transfer
            the knowledge to different area.
  <tantek> I've read the entire github issue and I'm still not sure
           about which of the options are better.
  astearns: There is the option using the start, end syntax, to
            start, end, both, none.
  dbaron: start, end made the most sense for 1 step keywords;
          not as helpful for multi-step cases
  <Bert> ('center' seems nice and short, transition in the middle
         rather than at the start or end...)
  <general talking about arg names>

  Rossen: We can always continue this in the discussion.
  Rossen: We are already going against Tab's strong pushback, it
          also doesn't sound like we have clear winners on arg names.
  birtles: Could we at least list the current candidates?
  birtles: 1) distribute and justify naming.
  Florian: 2) distribute and stretch
  birtles: 3) space-evenly, space-between
  dbaron: 4) center, stretch
  birtles: 5) both, neither
  Rossen: 6) trim-start, trim-end, trim-both, no-trim*
  Bert: 7) short, long.
  astearns: 8) include, exclude

  fantasai: Problem with distribute and justify is that they are two
            words that mean almost the same, and aren't used to make
            a distinction anywhere else in CSS.
  fantasai: (We also have text-justify: distribute as a legacy
            thing, which is really not helping here)
  fantasai: Problem with using center is that both space-around and
            space-evenly are centering methods, but they are
            different. It's not clear which one this is.
  <fantasai> I really don't like 1/2/4/7.
  birtles: Don't like the trim names b/c when you use them you
           typically don't drop the endpoints, you see the endpoints.
  Rossen: If folks are passionate about this, they can take this
          offline, and come back to the group, I really want to
          include TabAtkins, unfortunate to re-resolve this later.
  <fremy> My pref would be 3 or 4
  Rossen: Let's close this, if we have a clear set of keywords by the
          end of the F2F, we can resolve on a later day.

CSS Counter style issues

Compute missing counter styles to 'decimal'

  <astearns> https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611
  <fantasai> https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611#issue-7
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0076.html
  fantasai: This is about using a counter style which hasn't been
            created, its kept around and defaulted to decimal.
  fantasai: Proposal was to compute it to decimal, not keeping
            around the name.
  astearns: Seems fine.
  fremy: Why would you want to do that in the first place
  Rossen: Simplifies code, xidorn also said this wasn't a big issue.
  fremy: It would for use require a lot of code.
  fremy: Need some code which would replace the computed style.
  fantasai: Computed style isn't just used in the om, also has to
  fantasai: I'm not sure why it would be harder to switch unknown
            values to decimal.
  fremy: In edge you don't need to store a computed value, if you
         have a specified value.
  fremy: When the style is being defined you need to it is going to
         change the computed style a bunch, you need to invalidate
         all the styles on the page.
  <fantasai> Basically what François is saying is that if you use an
             undefined counter style, and the UA computes it to
             decimal, and then we append an @counter-style rule
             defining the counter style, this invalidates the
             computed styles

  Rossen: Going back to the issue,
  Rossen: xidorn didn't sound too insistent on it, TabAtkins said
          whatever, which ever way is more consistent.
  Rossen: At least 1 impl, which will require more cycles to support
          this, can we live without the simplification?
  Rossen: I'm mostly interested in mozilla folks.
  fantasai: You need to hear from mozilla, and anyone else who is
            going to impl this.

  Bert: Is it possible for an unresolved name to define later in the
  fantasai: No its global scope.
  Rossen: Since fantasai is looking for resolution, can we resolve
          to not simplify? Anyone objecting?
  dbaron: Would be good to hear for xidorn ....
  Rossen: He didn't think it would be a big deal....

  RESOLVED: No change to CR; revert the change to the Editor's draft.

  ACTION TabAtkins revert change in ED
  <trackbot> Created ACTION-853

DOC “in the document language” imprecise

  fantasai: Issue is - The language which counter is read out ...
  fantasai: It currently says the document language, but you probably
            want the language of the element instead, since in a
            multi-lingual document you would end up randomly picking
            one of them.
  fantasai: Another option, is the user-agent language...
  fantasai: 1) Element language.
  fantasai: 2) User-agent language.
  Rossen: 3) Use the Root of the scope of the counter style language.
  <dbaron> So we're discussing

  Rossen: If you have a list which is in English, in the middle you
          have bullet points in French, since the scope is in
          English, all of the counter styles will be based on the
          root (English).
  Rossen: The local elements language makes a lot less sense that
          the other two options.
  fantasai: Which options?
  Rossen: Document, or root of scope
  fantasai: More likely to have a problem with the document language.
  fantasai: A document language is freq. English as someone uses
            that at the top level, when you have multiple languages
            in the document,
  fantasai: Either that language is untagged,
  fantasai: Or the surrounding context, is in the language of the
            list themselves.
  fantasai: The chances that you tag it on the <li>, more likely
            that you tag it on the <span> inside.
  fantasai: Document language is a bad option for this.

  Rossen: Doing something special for the counter styles, e.g. using
          the user-agent, doesn't make any sense.
  Rossen: I gravitate to using the scope of the list.
  Rossen: Rather than using the document.
  Rossen: If we base it on the element, .... I cannot predict if
          thats going to be awkward or not.
  Rossen: The list makes the most sense.
  fantasai: Element would be easiest, as you don't need to carry the
            language through the tree.
  fantasai: If you have a counter which you don't set the scope on,
            its global ....
  fantasai: Right now counters are just numbers: the counter style is
            attached at the time you read out the counter, it's not
            associated with the counter itself.
  Rossen: The current algorithm requires a lot of walking around the
          dom tree....
  Rossen: Figuring out the language is one of those steps, if we add
          a little for counter styles, its not going to add a lot to
          the existing algorithm.
  Rossen: The element would be simplest for sure....
  Rossen: Unfortunately the a11y folks don't care if that alg is

  fantasai: Other problem is what is the scope of the page counter?
  fantasai: Is it the document itself?
  fantasai: Best solution is the local element scope, as simplest to
  fantasai: Easier to figure out the scope of the list.
  fantasai: Gives authors the most control as can set the language
            of the element itself
  fantasai: and also the scope of a counter, in general, is not
            particularly straightforward to understand.

  Rossen: We can do the simplest and see what the pushback for the
          a11y, i18n wgs are.
  Rossen: I wouldn't dismiss the fact that there will be mixed
          content inside of lists.... might not be an edge case.
  <fantasai> Rossen's example was code listings with line numbers,
             and comments in Chinese
  Rossen: We can live with this decision....
  Florian: Would make sense for counters to follow before afters,
           just tied to the element.
  Rossen: Proposed language, the language of a counter is computed
          based on the language of the element that the counter
          applies to.
  fantasai: ... at the point of retrieval...
  fantasai: e.g. target-counter() takes a counter from another
            element and displays it as text on this element
  fantasai: We don't bind counters with styles at the moment, you
            need to specify the counter-style where you are
            displaying the counter
  fantasai: Did you (Rossen) mean that we would use the language of
            the counter's element here or the language of the
            displaying element here?
  Rossen: The displaying element
  fantasai: OK, just want to make that clear.

  <dauwhe> what element does a page counter apply to?
  <astearns> the element that establishes the page fragmentation
  <Rossen> dauwhe, <page>
  Florian: Good when you have elements, but page counter, inside of
           a page, you don't have an element.
  Rossen: What are you computing the description of?
  fantasai: Language that you read other content in the margin box

  Rossen: How is this going to be selection be an a11y tool? In
          order to make the selection you need something selectable.
  Florian: But what's that.
  fantasai: Probably the document language, but I don't think it's
  Rossen: Whatever this is in the DOM, whatever it is in the DOM.
  koji: Selection is defined as DOM range.
  Florian: There is no rule that an AT will just read the page
           numbers when it flips through the page.
  Rossen: However you choose to select it, use that language.
  Florian: The answer is obvious then, it should be use the language
           of the root element.
  Rossen: If this is part of the UAs UI, then the UA should figure
          out how to do it...

  RESOLVED: The language of a counter is computed based on the
            language of the element that the counter applies to at
            the point of retrieval.

  Florian: Is that defined for pseudos?
  Rossen: I'm pretty sure it is, defined in HTML AAM.

  <fantasai> I think the resolution actually meant "The language is
             bound to the counter *style* from the element on which
             it is used"

  <TabAtkins> I'm going to object to this btw
  <fantasai> TabAtkins: maybe you should object now so we know what
             your objection is?
  <TabAtkins> Hard to type right now
  <TabAtkins> (I asked Rossen to move the counter styles issues to
              later in the morning, sigh)
  <TabAtkins> But I discussed this with you earlier in person
  <Rossen> TabAtkins, are you objecting to the current counter
           discussion or the frames()
  <TabAtkins> Counter discussion.
  <TabAtkins> Didn't see frames, will review it. 😀
  <Rossen> ok, we can revisit when you're back
  <fantasai> TabAtkins, that's what I thought so I was surprised it
             was on the agenda this morning

<br length="10m">
Received on Sunday, 27 August 2017 18:56:59 UTC

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