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

[CSSWG] Minutes Paris F2F 2017-08-02 Part IV: Inert, Motion Path, Sizing, Step Function Parameter Names, Intrinsic Sizing of No Intrinsic Size Images [motion] [css-sizing] [css-timing]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 27 Aug 2017 14:57:01 -0400
Message-ID: <CADhPm3v-gj5JLW2+2Rt=vh7N6ecPE4yz9ynnM_ufYsvyq4022A@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.


  - nianar let the group know Chrome was planning to ship an
      experimental version of inert behind a flag.

Motion Path

  - RESOLVED: Eric Willigers is now a co-editor on Motion Path


  - RESOLVED: height:stretch behave as align-self:stretch when
              possible, otherwise revert to auto
  - RESOLVED: Take the change "However, in the case of a replaced
              box with a percentage-based width/max-width/height/
              max-height, the percentage is resolved to zero when
              calculating the min-content contribution in the
              corresponding axis."

Step Function Parameter Names

  - RESOLVED: Use steps() function with the <integer> being number
              of visible frames during the animation duration
  - The names for the properties are still undecided. A github issue
      will be opened for bikeshedding.

Intrinsic Sizing of No Intrinsic Size Images

  - RESOLVED: Replaced elements with only an intrinsic aspect ratio
              has a min-content size of 0 and a max-content size of
              300px wide and 300*aspect-ratio height.
  - RESOLVED: In vertical WM, replaced elements with only an
              intrinsic aspect ratio use a 150px height and
              150*aspect ratio width, instead.


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

Scribe: tantek


  <nainar> Inert spec: https://github.com/WICG/inert/blob/master/README.md
  astearns: So this also doesn't have a gh issue.
  nainar: Currently we have inert shipping behind a flag in Chrome.
  nainar: Alice said there was feedback to have it affect(ed by)
  nainar: We can potentially do visibility later.
  dbaron: Who wanted that?
  nainar: Microsoft
  dbaron: Those sound like pretty different things.
  TabAtkins: Where was MSFT opinion documented?
  nainar: All I have is Alice's word.

  Rossen: We did discuss this in last TPAC
  Rossen: last September.
  Rossen: She did explain, at the time, my recollection of the
          conversation was that that was me responding in 5 min of
          thinking about this, not really thinking through any of
          the consequences.
  Rossen: The general idea wasn't crazy, I think historically some
          of the pushback used to be around the interaction between
          tabbing ... focus ... inert
  Rossen: Someone used to have an issue with that, I don't know who.
  Rossen: Going off of memory. I don't recall asking for it, or
          requesting it.
  Rossen: So to your question as to whether you should go ahead and
          experiment and see what happens, I have no objection to it.
  Rossen: Given that it is going to be shipped as an attribute that
          doesn't impact CSS.
  nainar: I can go back to Alice and get context.

  dbaron: Experiment or release?
  nainar: Experimental web platform feature - behind a flag.
  Rossen: Maybe it was Alex on the Mozilla side?
  dbaron: ok
  astearns: Confirming experimental only.

Motion Path

  <ericwilligers> https://drafts.fxtf.org/motion-1/
  astearns: We got through today's agenda, skipping a few things
  astearns: One additional thing was adding Eric W. as another
            editor on motion path spec.
  Rossen: Current set of editors is-
  Rossen: dirk, shane, and jihye
  astearns: As far as I know dirk is still interested but has very
            little time.
  TabAtkins: He has come back to making some edits.
  Rossen: He cannot commit to making phone calls unless explicitly
          requested for a particular issue.
  Rossen: He can still keep editing on gh.

  astearns: any concerns about adding editor?

  RESOLVED: Eric Willigers is now a co-editor on Motion Path

  <ericwilligers> my github username: ewilligers


  astearns: There are four sizing issues that I didn't get anywhere
            in the agenda.
  astearns: There are also the alignment issues we didn't get to
            this morning.
  astearns: We need to return to those based on some side
  Rossen: No I think the issues were just not short
  Rossen: baseline ... and baseline ....
  TabAtkins: In both of those we made some insight with some of
             yesterday's post meeting stuff.
  TabAtkins: I'd prefer to defer until we discuss and put together
             some evidence.
  fantasai: We should try and sort these out today or so, so when we
            run into problems it's while people are here to help us
            solve them.
  Rossen: Shall we fold in with grid discussions?
  fantasai: Yes let's do that.
  TabAtkins: there is #1614

`height: stretch` should just behave as `height: auto`
  github: https://github.com/w3c/csswg-drafts/issues/1614

  TabAtkins: The stretch keyword is defined for width, except for
             height, it tries to do the same thing except with the
             additional constraints that height has.
  TabAtkins: The effect is that we go up the tree looking for a
             definite height, and we just add up all the MBP between
             the element and the ancestor, essentially trying to
             make it as big as possible without overflowing the
  TabAtkins: This causes at least two problems:
  TabAtkins: 1 what happens if two descendants want height stretch
  TabAtkins: 2 second problem, if no ancestor is definite height,
             then we hit the ICB which is the height of the screen
  TabAtkins: So it's confusing that a height stretch element ends up
             being one screen height.
  fantasai: Or you ate it all up with MBP.
  TabAtkins: Yeah MBP would be subtracted from the ICB height as
  fantasai: It accumulates them all the way to the root.
  TabAtkins: Two possibility, height stretch acts like height auto.
             The other possibility, in layout moves that allow you
             to set a line with justify-*?
  TabAtkins: It does give you good behavior when ...
  TabAtkins: It does most of what was actually requested
  TabAtkins: In the layout modes where it does not make sense, like
             block, it just becomes auto.

  [fremy mentioned how we came up with stretch because align:stretch
      didn't work out for images with aspect ratio; fantasai pointed
      out this was "contain" not "stretch" though both are similar]
  fremy: That was not the reason that this was introduced
  fremy: because we cannot use the alignment so we came up with
  fremy: It does not solve the problem why we created it in the
         first place
  fantasai: Different issue.
  fremy: Oh ok not contains.
  fremy: nm.

  fantasai: What we want is comments from the WG on this, what do
            you think of this proposal, any other ideas how should
            we interpret stretch in the block axis.
  fantasai: We know how it should work in the inline axis.
  iank: ...
  fantasai: This and contain have certainly similarities.
  fantasai: Contain on something that does not have an aspect ratio
            is going to behave as stretch, so whatever stretch does
            has to be appropriate for that interaction with contain.
  TabAtkins: We haven't fully defined that anyway.
  fantasai: We did.
  <fantasai> https://drafts.csswg.org/css-sizing-4/#contain-sizing

  Rossen: You were saying height stretch wouldn't behave the same as
          justify-self or align-self, in layout modes that are ...
  TabAtkins: all kinds, we just don't care in .... ?
  Rossen: like table cells, it would act as height: auto
  Rossen: for absolute positioning ...
  TabAtkins: Stretch has a value which is that it fills the
             containing block without offsets
  Florian: ...
  TabAtkins: There are a few reasons.
  TabAtkins: We really want width:stretch, because there are times
             you want to invoke that behavior but width: auto does
             something different.
  Bert: Would it be more easy to set the stretch on the margin or
  TabAtkins: You can already do margin control but setting those to
  Bert: This I assume to anywhere you have fixed height?
  TabAtkins: Anywhere where alignment properties .... ?
  Bert: Like a case like columns, you have multiple columns, you
        have the height of the elements, but you don't know which of
        the elements will be at the bottom of the columns.
  TabAtkins: Can't do that now, block flow, but ...
  Bert: I want to avoid setting it on height because the element
        might be broken across columns.
  Bert: I still want it stretched to the bottom (edge) but ...
  Bert: you can just set stretch on the margin at the top or bottom.
  TabAtkins: We did make it work on margins with flexbox.

  TabAtkins: Focusing just on height:stretch, any different ideas?
             any objections?
  fremy: Is your proposal to say that in the cases that ... know,
         that you will behave as align stretch or in all cases?
  astearns: Proposal is for height:stretch to behave as align-self
            of stretch in those layout modes that define align-self
            of stretch and fallback to height auto otherwise.
  fremy: When you have nested stretch? when you have scrollable
  TabAtkins: Doesn't solve either of the initial problems, e.g. two
             sibling elements stretch.
  TabAtkins: Align-self: stretch knows how to handle itself.
  TabAtkins: Grid and flexbox know how to handle multiple align self
             stretch elements.
  TabAtkins: I don't want to define a feature that causes horrible
             amounts of overflow.
  TabAtkins: A lot of the use-cases are addressed by just using flex
             or grid.
  fremy: Then why?
  TabAtkins: It's frustratingly confusing if height and width allow
             different keywords, and there is reasonable behavior we
             can define for height: stretch
  TabAtkins: except no reasonable way to define it for a block.
  fremy: Still not entirely sure.
  fremy: It's not useful but it's allowing ... ?
  TabAtkins: The other bit of it there was a discussion in an
             earlier telcon about what the fallback value for
             stretch should be when there is a max-height keeping it
             from being full height.
  TabAtkins: You set height:stretch, then just use align-self as
             normal to set the fallback
  TabAtkins: helps us avoid having to have a specific flag.
  fremy: ok fair.
  TabAtkins: If they know how height-stretch works.

  astearns: Any objections having height:stretch behave as align
            self stretch when possible, otherwise revert to auto?
  astearns: Hearing no objections.

  RESOLVED: height:stretch behave as align self stretch when
            possible, otherwise revert to auto

  astearns: Any other issues that we could ... ?
  fantasai: I think I can do 765

[max-]width|height and intrinsic sizes
  github: https://github.com/w3c/csswg-drafts/issues/765

  TabAtkins: Intrinsic size of some elements with a percentage width
             or height.
  fantasai: Special behavior that images and form controls have
  fantasai: if you specify their width as a %, then their
            min-content size is assigned as if 0 sized.
  fantasai: So this behavior has not been spec'd anywhere and should
            be spec'd.
  fantasai: The one open consideration, form controls did not do
            this for max-width, but images did. so images responded
            to max-width, but form controls didn't.
  fantasai: TabAtkins and I decided to do min and max for both
            images and form controls
  fantasai: The only affected case would be you have specified max
            width percent on a form control, and the form control is
            inside shrink-wrapped container, and the form control is
            affecting the size of the shrink-wrapped container.
  fantasai: Seems like a really obscure case and I haven't found
            any. There may be some out there.
  fantasai: After talking with dbaron it seems that would be ok. We
            want wg resolution to make changes to the spec.

  astearns: I want to see the changes in the spec so we can see them
            in the spec
  astearns: and discuss them there.
  dbaron: To be clear, the thing that browsers do today isn't in the
  dbaron: tab & fantasai are proposing something simpler but still
          fairly consistent.
  astearns: Are you interested in changing your behavior?
  dbaron: Willing to. Have been running with a patch and haven't
          found anything broken yet.

  <fantasai> Proposed text is "However, in the case of a replaced
             box with a percentage-based width/max-width/height/
             max-height, the percentage is resolved to zero when
             calculating the min-content contribution in the
             corresponding axis."
  <fantasai> in https://drafts.csswg.org/css-sizing/#intrinsic-contribution

  dbaron: Other part hard here is defining replaced elements.
  TabAtkins: Apparently a commit went in today to HTML to define
  <TabAtkins> https://github.com/whatwg/html/pull/2857 PR to define
              replaced elements

  fremy: On some we are even more inconsistent.
  fantasai: For the sake of sanity we'd like to have consistency.
  fremy: e.g. video element with a slider
  fremy: all browser but edge, the default size of the control
  fremy: meanwhile in edge, default size of 0.
  fremy: There was a slider for the video element which was sized
         with max-width %.
  fremy: In edge since do we apply ... to this size, the minimum
         size was ... px, and the author provided size was 41px.
  fremy: In other browsers, they just use the normal default size of
         the control which was bigger than 41px.
  fremy: I do believe the edge behavior is what the author wanted.
  astearns: If we take this change then ...
  fremy: All browsers will behave as edge is behaving.

  astearns: any objections to taking this change?
  dbaron: FWIW I just checked the WHATWG HTML defined and it's not
          the one we want.
  dbaron: It's the stricter one.
  dbaron: It doesn't count form elements
  dbaron: only images, iframes, input type=image
  <dbaron> and a bunch of other things
  astearns: I'm hearing no objection to making the change
  <fantasai> I think we need to add "(including form controls)" here

  RESOLVED: take the change "However, in the case of a replaced box
            with a percentage-based width/max-width/height/
            max-height, the percentage is resolved to zero when
            calculating the min-content contribution in the
            corresponding axis."

  <dbaron> applet that represents a plugin, audio that is exposing a
           user interface, canvas that represents embedded content,
           embed, iframe, img, input with Image type, object that
           represents an image plugin or nested browsing context,
           and video
  <dbaron> from

  Rossen: birtles did you have a chance to figure out?
  birtles: fantasai and I talked about.

  dbaron: I don't think the resolution is actually right
  dbaron: I think it is a subset of replaced boxes, not all of them.
          but a subset of a superset of the WHATWG definition
  dbaron: actually it does include iframe.
  dbaron: Replaced boxes may need some caveats.
  dbaron: One definition of replaced that is a more strict
          definition, is the thing things that obey the CSS sizing
          rules for replaced elements.
  dbaron: We just need to figure out which replaced boxes it means.

Intrinsic Sizing of No Intrinsic Size Images
  Scribe: TabAtkins
  GitHub: https://github.com/w3c/csswg-drafts/issues/951#issuecomment-316535854

  fantasai: This issue is about a replaced element with an aspect
            ratio and no intrinsic size.
  fantasai: No intrinsic width or height, just ratio. What size will
            it be?
  fantasai: If you're not trying to compute intrinsic size, you use
            containing block width.
  fantasai: Stretch it to that, then use aspect-ratio to find the
  fantasai: But if you're shrinkwrapping around it, that's not
  fantasai: So we need some kind of size to fall back to for this
  [pausing to talk to Amelia]
  fantasai: There's a number of solutions we could use, some aren't
            good, some are better.
  fantasai: The ones you were listing were: first, use 0, I agree
            it's bad.
  fantasai: Second is to inflate to the nearest container, but that
            requires doing layout, and dbaron said it's apparently
            insane and should not be followed.
  fantasai: Third you listed is to use 300px as width and calculate
            height from the aspect ratio. I think that's the first
            possible option.
  fantasai: Another option is to use the height or width of the ICB.
  fantasai: Another is to use the nearest container with any fixed
  fantasai: Another is nearest scroll container with a fixed size.

  fantasai: We have a similar problem for writing modes, where we
            need to find a default size when we have an orthogonal
  fantasai: So it doesn't have an infinite inline size.
  fantasai: We originally specified using ICB height, but it was
            pointed out that's not the most useful thing if you're
            in a smaller scrolling container.
  fantasai: And so maybe we should use the height of the nearest
            scrolling container with a fixed height.
  fantasai: We could use that same solution here.
  TabAtkins: Find the nearest container options are similar to
             height: stretch problems
  TabAtkins: So might be as bad as that, not sure.

  Myles: Why not zero?
  fantasai: We try to avoid dataloss by default.

  TabAtkins: Seems like 300px would be the easiest.
  fantasai: Scrollport seems more useful.
  TabAtkins: Well, minus intervening mbp, right?
  fantasai: No, just the mbp on the element itself.
  TabAtkins: That'll often overflow then.
  fantasai: Yes, but you can scroll to see it.
  Rossen: Usually.
  fantasai: But you can fit the image within the scrollport at least
            if you scroll it into place.

  AmeliaBR: Even though 300/150 is totally arbitrary, it is already
            being used in other cases where you don't have an aspect
            ratio at all.
  <tantek> like iframes
  fantasai: It's there because there had to be something, not
            because it's in any way useful.
  Rossen: but is going to be obstructed by scrollbars in cases of
          auto scrollbars depending on when the size is resolved.
  AmeliaBR: Yeah, but creating different rules means increasing the
            number of behavior differences, where you change one
            thing and the result dramatically changes.
  AmeliaBR: So "stick with what we already have" has some
            predictability to it.
  TabAtkins: Agree.
  dbaron: Other thing about 300/150 means it'll show up, and if it's
          not what you wanted, you can change it to something else.
  TabAtkins: As opposed to shrinking it to 0.
  <Rossen> and this is also a very new and random behavior that is
           even different than height/width: stretch
  dbaron: Yes.
  fantasai: Yeah, 0 is the worst option.
  Rossen: Yup, the 300px isn't great, but it's reliable and common,
          and if people don't like it, they can set the values
  Florian: And while it's not useful, it's not dangerous; it won't
           usually cause overflow.

  fantasai: One thing for sure is that min-content size should be 0.
  fantasai: Choosing an arbitrary min-content size prevents it from
            shrinking below that size, but the whole point of an
            image without intrinsic dimensions is that it can shrink.
  TabAtkins: I agree with that.
  fremy: So a float would shrink it to 0?
  TabAtkins: Opposite - it'll be as large as possible there. Floats
             are *limited* to min-content below, but they try to be
             max-content size.

  RESOLVED: Replaced elements with only an intrinsic aspect ratio
            has a min-content size of 0 and a max-content size of
            300px wide and 300*aspect-ratio height.

  AmeliaBR: Qualification is that it should be defined as inline
            size, not width.
  fantasai: Images actually are always upright, they don't respond
            to writing mode.
  AmeliaBR: Like in vertical text, use 150px height, then 150*aspect
            ratio for width.
  fantasai: Not sure we want to have the sizing behavior change
            between horizontal and vertical WM.
  dbaron: Does css-writing-modes say how it revises CSS2 10.3.2 and
          10.6.2? Should it?
  astearns: I think we should keep the resolution as-is, and have
            test-cases for it in WM to see what the behavior
            actually is, if we're interoperable.
  fantasai: WM does say how it revises those sections.
  fantasai: Currently this case is undefined in CSS2, so that's fine.
  fantasai: What it says about the case that is defined, is that
            it's analogous - you treat widths as the inline axis,
            etc, and translate the chapter 10 algos accordingly.
  fantasai: But it does say that images don't rotate and their
            intrinsic dimensions don't rotate.

  fremy: I checked in Edge, if you're using vertical text, we do use
         150px height and 150*AR width.
  Florian: Is it annoying to have the intrinsic dimensions depend on
           something like WM?

  RESOLVED: In vertical WM, replaced elements with only an intrinsic
            aspect ratio use a 150px height and 150*aspect ratio
            width, instead.

  Florian: I ran into these sorts of bugs with testing box-sizing/svg
           /aspect ratio, and browsers behave different for
           aspect-ratio+height vs width+height.
  TabAtkins: Oh, that's bad. Having any 2 should be equivalent to
             having all 3.
  dbaron: Did you file bugs?
  Florian: I think I did where we had less than 2 correct cases.
  dbaron: Is there a test suite in WPT for this?
  Florian: Yes.

Step Function Parameter Names
  github: https://github.com/w3c/csswg-drafts/issues/1301

  TabAtkins: Strong objection to anything that resembles sizing or
             alignment keywords.
  TabAtkins: They are extremely confusing.
  TabAtkins: We have start and end already.
  TabAtkins: Imply dropping start or end step
  TabAtkins: we should come up with two keywords that fit that model.
  astearns: One of the reasons I proposed both and neither.
  Florian: it depends what what the step is, flat or vertical.
  TabAtkins: flat
  fantasai: vertical
  TabAtkins: I think for most authors the intuitive model is number
             of values received

  scribe: fantasai

  birtles: If you have say, steps(2, start)
  birtles: this is what you see as the timing function.
  birtles: If you're repeating this, you just see those two values,
           but if you apply this to a transition, you will see the
           pictures before and after the timing function.
  TabAtkins: The starting frame there isn't included in the value
  birtles: But as an author you're seeing all three values.
  TabAtkins: If you say I want transition to last 1s, and steps(2)
             and the time of the steps don't last .5s each, then
             it's bad.
  birtles: I disagree.
  birtles: We've already resolved we're sticking with steps() and
           the number is the number of jumps.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203
  TabAtkins: The argument from RachelNabors is that you can't
             accurately time a transition or animation that during
             the period shows both the start and end value
  TabAtkins: because right now you have to, during the transition,
             either the starting value is not shown and you jump
             immediately or
  TabAtkins: During a single transition, if you want to see both
             start and end there, which is a use case RachelNabors
             brought up, you have to do some non-intuitive
             duration-manipulation to make it show correctly.
  TabAtkins: If you want a 3-step frame-based cartoon that lasts 3s

  birtles: We're talking cross-purposes.
  birtles: We're all agreeing that this timing function exists
  birtles: we're just talking about the syntax for it.
  birtles: We went over the number of steps this morning
  birtles: and resolved on that aspect.
  dino: I think we agree that there are three steps there, if we're
        going up a staircase, there are three steps there.

  fantasai: We're off-topic, the topic is the name of the keywords
            not the syntax of the function overall. That was
            resolved already.
  TabAtkins: I object to that
  fantasai: Doesn't matter, you're off-topic
  TabAtkins: There are 4 things being shown !
  dino: 4 things shown is 3 steps
  TabAtkins: You're thinking about the wrong things.
  [rehash of arguments]
  TabAtkins: I'm representing RachelNabors, nobody else is!
  birtles: I presented the arguments on both sides, and explained
           why I think that the steps() syntax is the right way to
  birtles: Didn't go with frames() for two reasons
  birtles: First is, it's less appropriate for contexts outside of
           looping animations
  birtles: transitions and gradients being examples.
  birtles [gives more specific examples]
  birtles: The other concern was discoverability.
  birtles: If you start with steps() and it's not quite right, then
           can't discover frames() behavior by adjusting arguments,
           and also need to change how you count
  birtles: or vice versa.

  fremy: Your problem is that you count 3 here, what if instead we
         count 4, but keep it in the steps() function.
  TabAtkins: If the third one was steps(4, something) and the fourth
             one was steps(2, somethingelse) then it's fine.
  fremy: So you don't object to using steps(), just object to using
  <Bert> ... another possibilities is to count the # of intermediate
         values: steps(1) would mean going from start to finish with
         1 intermediate step, and steps(0) means go directly to the
         end value without any intermediate values...
  dino: So you're counting the number of places you put your foot
        rather than the number of times you go up.
  TabAtkins: Want it to be number of things you see
  gregwhitworth: Rachel does say that she's fine to re-use steps().
  <gregwhitworth> for reference - here is the comment where
                  RachelNabors says that:


  birtles: The tricky bit is that in the first two cases, which we
           have right now, it just so happens that the number of
           values you see also matches the number of jumps.
  birtles: That's why that happens to be okay.
  birtles: But that's only true when you're repeating
  birtles: If you're transitioning or using animation-fill-mode,
           then you see more.
  TabAtkins: But that's not part of the duration.
  dino: TabAtkins' only cases where you put your foot between the
        start and the end, doesn't care about what's before or after
        the start/end.
  ericwilligers: If we go with where you put your foot, then the
                 bottom left would be steps(4, neither) and the
                 bottom right would be steps(2, both)
  <dbaron> referring to the diagram in
  TabAtkins: You're showing neither start nor end during the duration
  TabAtkins: I think it would be better to have drop-* keywords or
  TabAtkins: but then you'd have to ...
  [mumbling in the corner]

  dbaron: I think start and end made a lot of sense for step-start
          and step-end, but maybe less so here
  TabAtkins: I agree. They are the correct start/end pairs for
             single steps.

  astearns: So I've heard people say they don't like the idea of
            having the bottom left be steps(4) and the bottom right
            be steps(2), but does anyone object to the idea of
            counting places to put your foot?
  TabAtkins: The other people talking about other interpolation
             stuffs also want 4 and 2.
  TabAtkins: So I think they're intuitive on their own.

  birtles: This is a frame based animation here:
  [birtles projects a demo
      birtles writes
      animation: slide 3s infinite steps(10, start)
  birtles: You see you miss frame 1
  <birtles> http://slides.com/birtles/browser-animation-2017/live#/3/2
  birtles: If I s/start/end, I start at 1, but don't set 10
  birtles: If I say frames(11), then I get all the 10 frames.
  birtles: But to get this effect, I have to change the number.
  birtles: If you're switching between the two, then you have to
           change the number.

  dbaron: Seems like we have one solution that isn't drawing strong
          objections from people
  dbaron: which is to use the steps() function with two new
          keywords, and count the number of places you put your foot.
  Bert: Referring back, if you count the number of intermediate
        steps, there's only 9 intermediate steps.
  Bert: Some variations, you only see those 9 steps, the first and
        last are outside the animation itself.
  [everybody picks a number to shout]
  TabAtkins: Using values 10 11 or 9 with some yet-undecided set of
             keywords, using steps() function name, seems to be
             drawing least objections.
  TabAtkins: Anyone object to that, assuming good keyword names?
  dbaron: We need to find names that work with the numbers.

  astearns: Any objections to this proposal?
  astearns: So we'll add to this morning's resolution that we'll use
            steps() function with numbers that count the place where
            you put your foot.
  astearns: I'm concerned that this will prove confusing.
  Bert: If you allow 11 here, then 1 makes no sense.
  Bert: Then why not lower the number, and say it's the number of
        intermediate values.
  dbaron: Bert is concerned about the allowed range of integers,
          which will vary depending on the keyword

  RESOLVED: Use steps() function with the <integer> being number of
            visible frames during the animation duration

  <dbaron> 1- for the existing keywords, and 0- and 2- for the new
  <TabAtkins> dbaron, actually I think the "intermediates only" is
              also 1+, not 0+. You need to have at least one
              "intermediate" value to show!
  <TabAtkins> dbaron, so the frames() use-case is 2+, the rest are
  <dbaron> TabAtkins, actually, maybe the new ones are both 2+
  <TabAtkins> dbaron, Nah, "intermediate only" is fine to be 1 - it
              shows only the 50% value during the animation.

  astearns: What should the keywords be
  fantasai: If we were starting from scratch I have an idea.
  fantasai: ... we'd use the same kind of: fill, start-fill,
            end-fill, and ... we have this concept of fill.
  <fantasai> fill-start, fill-end, fill-between, fill-evenly
  <fantasai> just like alignment
  <fantasai> fill is time that's filled by a frame
  TabAtkins: I'd be ok with 4 new keywords to make a set
  TabAtkins: rather than adding to start+end.
  astearns: You could have the keywords say where you jump. So you
            have steps(3, start), steps(3, end), steps(4, neither),
            or steps(2, both).
  fremy: 4th one is intermediate only, only shows intermediate only
  fremy: 3rd one includes ...
  fremy: open set and closed set
  fremy: intermediate and
  TabAtkins: Intermediate is over the desired spelling level.

  dino: Anyone wants 4th one?
  TabAtkins: Yes, definitely have requests for that
  TabAtkins: esp for gradients.
  <TabAtkins> linear-gradient(red 20%, steps(5, middle-only), blue
              80%) <= 5 color stripes between the red and the blue

  fantasai: So both and neither was ...? No, it's really confusing.
  TabAtkins: As dbaron was saying, the start/end keywords make sense
             for the step-* keywords but not so much for the steps()
  Florian: We do both and neither.
  fremy: So both is show both start and end, and neither is ...
  TabAtkins: No, that's backwards
  TabAtkins: because of the way start and end are defined.
  fremy: Screw it, we should do it this way around anyway.
  TabAtkins: That's okay if we have a prefix, like show-start or
  TabAtkins: show-end, show-start, show-both, show-neither
  <birtles> steps(4, frames)? (Not sure about the fourth option)

  astearns: So show-end is the same as start.
  TabAtkins: if we do show keywords we do it this way, if we do drop
             keywords we can match start/end.
  TabAtkins: But it also was pointed out that drop has some weird
             implications of dropping a frame
  TabAtkins: show-* doesn't have that problem or one of adding a
  dbaron: stripes? :)
  <dbaron> (somebody said before me that frames was for animations
           and the other one was for gradients)
  birtles: steps(4, frames) steps(2, stripes)
  dbaron: Though they all give stripes, just a different set of
  <dbaron> actually 0 does work as the number for the fourth option

  <Bert> just thinking aloud, but how about: step(n [, show-first ||
  fantasai: Oh, I like that Bert. That's better than using start/end
            with opposite meanings
  <melanierichards> +1 to Bert's idea
  <fantasai> although I'd still have both keyword, because it's
             easier to type
  <fantasai> and also, how do you get the 4th variant?
  <TabAtkins> Bert, can't make both keywords optional, unfortunately,
              because the "no keyword" case (steps(3)) already means
              steps(3, end). :(

  [Rossen and Tab discuss some examples]
  TabAtkins: Let's go back to thread with what we've concluded and
             ask for help
  astearns: maybe we should open a new issue
  astearns: OK, let's close this issue and open a new one on the new

Received on Sunday, 27 August 2017 18:57:57 UTC

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