- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 27 Aug 2017 14:57:01 -0400
- 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.
=========================================
Inert
-----
- 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
Sizing
------
- 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.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Scribe: tantek
Inert
=====
<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)
visibility?
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
Sizing
======
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
discussions?
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
parent.
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
well.
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
stretch.
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
padding?
TabAtkins: You can already do margin control but setting those to
auto.
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
containers?
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
spec.
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
them.
<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
https://html.spec.whatwg.org/multipage/rendering.html#replaced-elements
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
height.
fantasai: But if you're shrinkwrapping around it, that's not
usable.
fantasai: So we need some kind of size to fall back to for this
case.
[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
size.
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
flow.
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
explicitly.
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
then...
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
go.
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
3.
<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:
https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-299749586
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
https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203
TabAtkins: You're showing neither start nor end during the duration
TabAtkins: I think it would be better to have drop-* keywords or
something.
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
keywords
<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
1+.
<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()
function.
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
frame.
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
stripes.
<dbaron> actually 0 does work as the number for the fourth option
<Bert> just thinking aloud, but how about: step(n [, show-first ||
show-last]?)
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
keywords
</meeting-day>
Received on Sunday, 27 August 2017 18:57:57 UTC