22:59:23 <RRSAgent> RRSAgent has joined #css
22:59:23 <RRSAgent> logging to http://www.w3.org/2017/07/05-css-irc
22:59:25 <trackbot> RRSAgent, make logs public
22:59:28 <trackbot> Zakim, this will be Style_CSS FP
22:59:28 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
22:59:28 <trackbot> Date: 05 July 2017
22:59:28 <Zakim> ok, trackbot
22:59:34 <astearns> present+
22:59:36 <tantek> regrets+
22:59:42 <Florian> present+ Florian
22:59:43 <ChrisL> present+
22:59:55 <nainar> I'm not a member and can't access the details.
23:00:02 <antenna> antenna has joined #css
23:00:11 <dael> present+ dael
23:00:12 <astearns> https://mit.webex.com/mit/j.php?MTID=m34e7a273ee0398395b9408821caaa184 <https://mit.webex.com/mit/j.php?MTID=m34e7a273ee0398395b9408821caaa184
23:00:14 <dael> ScribeNice: dael
23:00:23 <dael> ScribeNick: dael
23:00:29 <astearns> US Toll Number: +1-617-324-0000
23:00:29 <astearns> 
23:00:29 <astearns>     Access code:640 905 190
23:01:53 <dbaron> Present+
23:02:13 <TabAtkins> present+
23:02:14 <leaverou> present+
23:02:24 <gregwhitworth> present+
23:02:40 <melanierichards> present+
23:02:55 <myles> present+ myles
23:03:00 <nainar> present+
23:04:10 <alex_antennahouse> present+
23:04:16 <jensimmons> jensimmons has joined #css
23:04:22 <jensimmons> present+
23:04:34 <fantasai> present+
23:04:46 <antenna> present+
23:04:49 <dael> astearns: As always does anyone have any extra things to add to the agenda. With the cavet that the CSS 2 issue should go to next week.
23:04:51 <myles> ChrisL: wow you are amazing!
23:04:51 <dael> fantasai: Right.
23:04:58 <dael> astearns: Anything else?
23:04:59 <myles> thank you ChrisL!
23:05:21 <dael> astearns: One thing to point out is we have a month before Paris meeting. If people can add agenda items and add yourself to the wiki that would be great.
23:05:25 <dbaron> https://wiki.csswg.org/planning/paris-2017
23:05:33 <dael> Topic: rec next steps
23:05:41 <dael> astearns: Is anyone blocked or have progress not on ML?
23:06:05 <dael> Florian: In terms of extra progress fantasai has done quite a bit of the review I asked for. I need to respond to her comments, but progress is made.
23:06:10 <smfr> smfr has joined #css
23:06:14 <dael> Florian: ChrisL where are we on pub for CSS contain?
23:06:18 <hober> present+ hober
23:06:23 <dael> ChrisL: I'm not sure. I'll get backc to you after call.
23:06:32 <dael> fantasai: What are we publishing?
23:06:37 <dael> Florian: CSS Contain to CR.
23:06:45 <dael> fantasai: Ah. I just found some issues.
23:06:55 <dael> Florian: That's good. Do you want to report them on CR or delay CR.
23:07:34 <dael> fantasai: I don't know. It's possibly a major problem. It's about how the paint containment is defined. IT says becoming a formatting context and that's not defined. It changes the display value at use time which you can't do because you have to contruct the box tree first.
23:07:40 <RachelNabors> Trying to be present. Wifi... failuring...
23:07:51 <ChrisL> q+ for status update
23:08:00 <dael> fantasai: I don't know what you want to do for these things where you're definingin not defined behavior. We can figure out a defintion or say contain doesn't apply to certain elements.
23:08:17 <dael> Florian: Not sure I want to fix that off the top of my head, but sounds like it needs to be addressed.
23:08:46 <fantasai> Florian,
23:08:47 <fantasai> https://github.com/w3c/csswg-drafts/issues/1457
23:09:10 <smfr> present+
23:09:50 <RachelNabors> present+
23:10:13 <ChrisL> On CSS contain, I need to convince ralph that the security issue he raised is no existent
23:10:27 <Guest> Guest has joined #css
23:10:53 <dauwhe> present+ dauwhe
23:11:22 <Jia> Jia has joined #css
23:11:39 <astearns> waiting on dbaron response to align issues
23:12:05 <ChrisL> +1 to republish motion path
23:12:08 <fantasai> ScribeNick: fantasai
23:12:11 <astearns> https://lists.w3.org/Archives/Public/www-style/2017Jul/0000.html
23:12:21 <astearns> request to publish motion path
23:12:28 <fantasai> astearns: Just a regular WD
23:12:37 <fantasai> astearns: Lots of updates since last WD, so we should republish. Any comments?
23:13:06 <fantasai> ChrisL: Might have to be done manually, since FXTF is nominally between two WGs. If so let me know, and I'll republish manually.
23:13:23 <birtles> I'm pretty sure I've been able to publish Web Animations (FXTF) automatically
23:13:41 <fantasai> ChrisL: In practice, CSSWG has taken up FXTF work atm, but anyway, let me know if it fails publication automatically and I'll do it manually.
23:13:53 <fantasai> astearns: objections to new WD?
23:14:01 <fantasai> RESOLVED: New WD of motion
23:14:17 <fantasai> Topic: nowrap vs no-wrap
23:14:29 <astearns> [css-flexbox] [css-text] Alias "nowrap" as "no-wrap"
23:14:41 <astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1537
23:14:44 <fantasai> drat, call dropped
23:14:51 <astearns> all dropped
23:14:54 <nainar> Call dropped
23:14:55 <TabAtkins> oh, cool
23:14:59 <jensimmons> yup
23:15:11 <astearns> 10 people still on
23:15:15 <astearns> 10 people gone
23:15:30 <jensimmons> back
23:15:44 <nainar> im in
23:15:58 <nainar> Github issue: https://github.com/w3c/csswg-drafts/issues/1537
23:16:12 <fantasai> astearns: Last time we discussed, had 3 alternatives
23:16:16 <fantasai> astearns: 1 No change at all
23:16:22 <fantasai> astearns: 2 Add dashed version as a parse-time alias
23:16:32 <fantasai> astearns: 3 Add dashed version as a new values that behaves the same as nowrap
23:16:47 <fantasai> astearns: There was some discussion on the issue since, but no conclusion
23:17:25 <fantasai> hober: I'm mildly opposed, which is to say that I'm for option 1
23:17:33 <fantasai> hober: Alias has a cost, not sure that the benefit is more.
23:17:52 <fantasai> TabAtkins: I mistype this all the time, and I can't be the only person who does it. It's bad keyword.
23:18:02 <fantasai> TabAtkins: We should have done it right the first time.
23:18:14 <dbaron> This is CSS1:  https://www.w3.org/TR/REC-CSS1/#white-space
23:18:26 <gsnedders> present+
23:18:30 <fantasai> TabAtkins: Would have preferred if we had no-wrap in flexbox and nowrap in white-space with additional white-space: no-wrap keyword
23:18:47 <fantasai> nainar?: I'm with Tab, we have multiple people making this error within a week.
23:18:57 <fantasai> TabAtkins: parse-time alias is low-cost. I'm fine with just doing it htat way
23:19:07 <fantasai> astearns: Difference is in CSSOM?
23:19:09 <fantasai> TabAtkins: yeah
23:19:23 <fantasai> TabAtkins: CSSOM will always return nowrap
23:19:29 <fantasai> TabAtkins: Benefit is that older tools will continue to work
23:19:36 <fantasai> TabAtkins: downside is authors might be confused
23:19:51 <fantasai> TabAtkins: Full alias does incur more cost on engine
23:19:58 <fantasai> TabAtkins: parse-time is trivial
23:20:00 <nainar> s/nainar?/nainar
23:20:30 <fantasai> Florian: Not a strongly held belief, but I think 2 is in-between, not really worth it
23:20:38 <fantasai> Florian: Doesn't really give a transition path to a better world
23:21:05 <fantasai> Florian: If we go with option 3, we can eventually forget nowrap ever existed
23:21:15 <fantasai> ChrisL: Agree with Florian
23:21:25 <fantasai> dbaron: Both option 2 and option 3 have a substantial cost to developers
23:21:35 <fantasai> dbaron: If we go with option 2, then ppl who use dash need to know that OM doesn't use dash
23:21:53 <fantasai> dbaron: With option 3, then it depends on who wrote the CSS rather than just being the developers with a dash habit
23:22:00 <fantasai> astearns: Your JS has to check for both in option 3
23:22:08 <fantasai> dbaron: With option 3 we're imposing cost to developers for a long time
23:22:23 <fantasai> TabAtkins: So all three put cost on developers
23:22:31 <fantasai> TabAtkins: None seem obviously better
23:22:39 <fantasai> hober: If it's a toss-up between all three, this decision is insans
23:22:51 <fantasai> jensimmons: I am always thinking where is CSS going to be in 30 years
23:23:09 <fantasai> jensimmons: If we switch to option 3, 30 years from now everyone can forget this ever happened. No one will use nowrap.
23:23:13 <fantasai> jensimmons: I'm into 3
23:23:15 <hober> s/this decision is insans/the correct choice is no change/
23:23:22 <fantasai> TabAtkins: I'm 100% sure minifiers will remove the dash
23:23:49 <fantasai> TabAtkins: Option 1 puts mental load on everyone who uses CSS. Option 2 only puts it on ppl who deal with OM, which is a much smaller class.
23:23:58 <fantasai> TabAtkins: I don't have an opinion on 2 vs 3
23:24:03 <fantasai> TabAtkins: But do feel strongly about 1
23:24:10 <jensimmons> +1 for what Tab just said. Most people writing CSS aren’t also writing JS handling that CSS
23:24:19 <fantasai> Florian: This is also not a property value that is commonly manipulated through JS
23:24:45 <fantasai> astearns: One person in favor of #1, anyone else?
23:24:57 <fantasai> smfr: I would vote for no change
23:24:59 <gsnedders> I agree with TabAtkins.
23:25:04 <smfr> it was me
23:25:05 <fantasai> myles: Me too
23:25:13 <Florian> Favors 3, not as strongly as Tab.
23:25:14 <smfr> basically #apple
23:25:22 <nainar> I'm with Tab on this one. (3 > 2)
23:25:45 <fantasai> astearns: So Apple against change, Google for some kind of change, and some arguments for change being #3 in order to make future of CSS make more sense.
23:25:50 <dbaron> I think I lean towards no change; I don't think getting rid of the 'nowrap' value at some indefinite point in the future is realistic.
23:25:53 <fantasai> hober: My impression was also dbaron was arguing no change?
23:26:11 <fantasai> dbaron: I lean towards no change, but I see both sides so not that strongly in that camp.
23:26:17 <fantasai> dbaron: But pretty hesitant to agree to do it now
23:26:43 <fantasai> gregwhitworth: I'm with dbaron, no strong opinion. Do know that authors run into it, e.g. postCSS plugin to fix this
23:26:49 <fantasai> gregwhitworth: I wouldn't be in a rush to implement.
23:27:08 <fantasai> astearns: Sounds like we have no consensus to add no-wrap at this time, in either version.
23:27:19 <fantasai> astearns: One engine interested, and others not so interested, so not something to bite off today.
23:28:17 <fantasai> fantasai: I would add that if we have one engine add and others don't, we're in a really bad world, because authors using that engine will think it works and in other engines it won't.
23:28:33 <fantasai> astearns: OK, so I'm saying we close this as no change, and the ppl who want it can try to convince hte others.
23:28:44 <astearns> topic: [css-timing] reconsider name of frames() timing function
23:28:44 <fantasai> RESOLVED: No change for issue about adding no-wrap
23:29:35 <RachelNabors> I'm here. But waiting on more feedback from the community.
23:29:45 <astearns> topic: [css-values] Computed value of a negative calc unit that doesn't allow negative lengths.
23:29:54 <astearns> github topic: https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908
23:30:10 <fantasai> TabAtkins: Spec text previously said that you can put negative numbers into calc(), it's fine, because we can't in general tell if it's negative or not
23:30:18 <fantasai> TabAtkins: we do a clamping at some point if it needs to clamp to a particular range
23:30:36 <fantasai> TabAtkins: Spec previously said that clamping happens at computed value time, but you can't always tell, e.g. width has to happen at used value time
23:30:49 <fantasai> (and font-size has to happen at computed value time)
23:31:09 <fantasai> TabAtkins: fantasai and I discussed and realized there are two possible interpretations of this conclusion
23:31:29 <fantasai> TabAtkins: for properties that clamp at computed value time
23:31:41 <fantasai> TabAtkins: can clamp through at computed value time
23:31:56 <fantasai> TabAtkins: For properties that clamp at used value time, some things can clamp at computed value time
23:32:08 <fantasai> TabAtkins: So do those properties clamp both at used and computed value time, or just at used value time?
23:32:29 <fantasai> Florian: So for multi-stage examples if you can't clamp, you keep a calc() expression, right?
23:32:50 <fantasai> TabAtkins: If you're width is calc(5px-5%) it'll stay as that at computed value, clamps at used value
23:32:53 <birtles> I think we want to clamp as late as possible -- since animation operates on computed values (more or less)
23:33:01 <fantasai> Florian: But if you clamp at calc(5px-5em) can clamp at computed value
23:33:21 <fantasai> TabAtkins: If we clamp only at used value time, we need a definition of which property is which kind of computation
23:33:43 <fantasai> TabAtkins: And then, if we ever add a unit that does used value time computation to a property that currently clamps at computed value time, it would change behavior
23:33:54 <fantasai> TabAtkins: So I prefer clamp at all times behavior
23:34:04 <fantasai> dbaron: I was going to say I prefer the other one
23:34:24 <fantasai> dbaron: birtles said same thing on IRC, but was thinking about animations
23:34:42 <mike_miller> mike_miller has joined #css
23:35:00 <fantasai> dbaron: I was thinking essentially of things like width: calc(-5px) vs width: (0%-5px) vs width: (0-5px) vs width: (10%-5px)
23:35:19 <fantasai> TabAtkins: You can't add 0% to 1s, so while we technically can resolve zero immediately, we would treat it like any other percentage
23:35:36 <fantasai> dbaron: Still worth thinking about animations
23:35:45 <dbaron> s/vs width: (0-5px) //
23:36:05 <fantasai> Florian: If we go that way, pretty important to go the way Tab says for 0%, otherwise discontinuity between 0% and 0.00001%
23:36:05 <birtles> specifically my concern is you want to interpolate using the unclamped values and then clamp
23:36:12 <fantasai> TabAtkins: Don't understand animations issue
23:36:23 <fantasai> TabAtkins: font-size resolves everything at computed time already
23:36:40 <fantasai> TabAtkins: So animations should see value of 0 for 0px, don't see why width should be different
23:36:54 <fantasai> dbaron: You can have a calc() that's a result of interpolation
23:37:11 <fantasai> dbaron: If one of the end points does different things than the intervening value..
23:37:25 <fantasai> TabAtkins: If the values are different, then the middle value will always be a valid value anyway
23:37:31 <fantasai> ... bouncing ...
23:37:45 <fantasai> TabAtkins: If it's a used value time unit involved, then it'll always stay as a calc()
23:37:57 <dbaron> (bouncing meaning timing functions that go outside 0-1)
23:37:59 <fantasai> Florian: None of these allow us to have results earlier, to get fully resolved value at computed value time ..?
23:38:00 <birtles> e.g. if you support calc() for opacity and interpolate between calc(-1) to calc(3) you'll get different results if you clamp the endpoints before interpolating
23:38:20 <fantasai> TabAtkins: Just feels nasty and weird if font-size can clamp its values at computed value time, but width can't even if it uses the exact same value
23:38:37 <fantasai> TabAtkins: And also, as I said before, if we add a used-value time unit to a computed-value-time-only property, it would change behavior
23:38:48 <fantasai> TabAtkins: observable in animations as well as OM
23:39:03 <fantasai> TabAtkins: If we say that a property only has computed value time units, then it can never gain a used-value time unit
23:39:09 <fantasai> Florian: Why?
23:39:26 <fantasai> TabAtkins: Because it will change from clamping at computed value time to clamping at used value time, seeing raw calc() value in the animation
23:40:43 <fantasai> TabAtkins: Difference is e.g. animated from -1000px to 1000px, would stay at 0 for first half if doing used value time, and would animate from 0 to 1000px over full range if doing computed value clamping
23:40:55 <fantasai> dbaron: What do implementations currently do?
23:40:59 <fantasai> TabAtkins writes some tests
23:41:17 <fantasai> TabAtkins: Looks like in Chrome at least, appears to delay width clamping to used value time right now
23:41:25 <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5256
23:41:38 <fantasai> TabAtkins: Spends half of the animation sitting at zero
23:42:07 <fantasai> TabAtkins: wait, this is inconsistent
23:42:17 <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5257
23:43:22 <fantasai> ?: Does the other behavior. never sticks at zero.
23:43:30 <fantasai> TabAtkins: Sounds like no interop
23:43:31 <gsnedders> s/?/Myles:/
23:43:31 <RachelNabors> BAHAHAHAHA... Tab.
23:43:59 <myles> s/?: Does/Myles: Safari does/
23:44:01 <fantasai> astearns: Think we should kick this back to github for testing, come back with animation data
23:44:15 <fantasai> astearns: Anything else to bring up on this topic?
23:44:36 <astearns> topic: [css-syntax] Trim whitespace around declarations?
23:44:49 <astearns> github topic: [css-syntax] Trim whitespace around declarations?
23:44:59 <astearns> github topic: https://github.com/w3c/csswg-drafts/issues/774
23:45:36 <fantasai> TabAtkins: This has impact on what custom property values are
23:45:42 <fantasai> TabAtkins: Because custom properties capture tokens
23:45:58 <fantasai> TabAtkins: Currently the white space before first value token is preserved
23:46:24 <fantasai> TabAtkins: All of the normal properties serialize out from OM, so they get normalized white space output
23:46:37 <fantasai> TabAtkins: Some people brought up maybe we should trim the white space from beginning and end of a token stream
23:46:42 <fantasai> TabAtkins: This would be a tweak to the Syntax spec
23:46:49 <fantasai> TabAtkins: to throw away this white space
23:47:01 <fantasai> TabAtkins: No consequence for ordinary CSS, they will continue to parse and serialize as usual
23:47:22 <fantasai> TabAtkins: It may or may not have an observable difference on serializing a rule of a style sheet... I think they generally reserialize from internal structures
23:47:57 <gregwhitworth> basically this saves authors from writing trim() when manipulating custom props
23:48:03 <fantasai> TabAtkins: Would have desired difference on serialization of custom property value when ppl write with typical whitespace after colon
23:48:32 <fantasai> TabAtkins: Saves authors from writing trim(), right, and also from forgetting to write trim() because they never have to write that for any other property
23:48:41 <fantasai> leaverou: Is there any use case where you want the white space
23:48:53 <fantasai> TabAtkins: If you're embedding an esoteric language...
23:49:07 <fantasai> TabAtkins: If you're embedding another programming language into CSS you'll have consequences anyway
23:49:12 <fantasai> TabAtkins: Don't think any other issue
23:49:23 <fantasai> leaverou: So benefit to it, and not hurting any use case. So I'm hugely in favor.
23:49:31 <myles_> myles_ has joined #css
23:49:40 <fantasai> leaverou: Every time I use OM for custom properties, have to use trim(), it's really annoying.
23:49:45 <ChrisL> +1 to trimming
23:49:55 <fantasai> astearns: Proposal to trim whitespace on either side of all declarations. In favor / opposed?
23:50:13 <fantasai> RESOLVED: trim white space before / after property value in a declaration.
23:50:17 <astearns> topic: [css-align] Values section shouldn't point wholesale to CSS Level 2
23:50:23 <gregwhitworth> TabAtkins: can you submit a test for this when you make the change?
23:50:31 <astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1397#issuecomment-311471628
23:50:46 <fantasai> TabAtkins: Issue raised by dbaron on css-align, the values section pointed straight to CSS2
23:50:56 <fantasai> TabAtkins: better to point to more up-to-date specs
23:51:22 <fantasai> TabAtkins: This text shows up in many of our specs, so we went an updated all of them... we can revert or change as necessary
23:51:36 <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1397#issuecomment-311471628
23:51:38 <fantasai> TabAtkins: Because it's a wide-ranging change, wanted to get WG approval before making part of spec boilerplate
23:51:52 <fantasai> This specification follows the <a href="https://www.w3.org/TR/CSS21/about.html#property-defs">CSS property definition conventions</a> from [[!CSS2]].
23:51:55 <fantasai> Value types not defined in this specification are defined in CSS Values & Units [[!CSS-VALUES-3]].
23:51:58 <fantasai> Other CSS modules may expand the definitions of these value types.
23:52:01 <fantasai> In addition to the property-specific values listed in their definitions,
23:52:03 <fantasai> all properties defined in this specification
23:52:05 <myles_> myles_ has joined #css
23:52:06 <fantasai> also accept the <a>CSS-wide keywords</a> keywords as their property value.
23:52:08 <fantasai> For readability they have not been repeated explicitly.
23:52:18 <fantasai> Florian: Seems to work for vast majority of specs. Have you checked it makes sense for specs that don't define properties?
23:52:24 <fantasai> Florian: Like MQ or Selectors?
23:52:41 <fantasai> TabAtkins: Those either don't have values section or it worked.
23:52:59 <fantasai> TabAtkins: One or two specs had an extra line of text, but everything that had a value section could take this without any addition
23:53:10 <fantasai> Florian: If put in bikeshed boilerplate?
23:53:14 <fantasai> TabAtkins: Defer that question to later
23:53:32 <fantasai> TabAtkins: Just wanted to verify the text, and if ppl ok to me updating all the specs
23:53:53 <fantasai> dbaron: I'm okay with the replacement, but think it could use further improvement.
23:54:42 <fantasai> dbaron: E.g. in Animations we define Animation line, CSSOM defines another line...
23:54:53 <fantasai> fantasai: I think we should have an updated propdef explainer somewhere, e.g. snapshot
23:55:01 <fantasai> dbaron: can just make everything hyperlinked
23:55:23 <fantasai> fantasai: Yeah, but should have more explanation than just a hyperlink
23:55:26 <fantasai> ...
23:55:34 <fantasai> Florian: ???
23:55:54 <fantasai> TabAtkins: It was definitely outdated, e.g. didn't link to CSS-wide keywords becaus that wasn't a thing
23:56:01 <fantasai> TabAtkins: Definitely better than what we have, could improve further.
23:56:13 <Florian> s/???/did any of the sections to be replaced have anything about what dbaron mentioned? if not, it's a strict improvement and we can deal with that later/
23:56:29 <fantasai> astearns: So you want approval of the changes
23:56:33 <fantasai> fantasai, Tab: Yes
23:56:51 <fantasai> fantasai: And also if there are specific changes desired, resolve to have us propagae those or discuss further in GitHub
23:57:07 <fantasai> astearns: Proposed to accept this improvement, raise GitHub issues for further improvement
23:57:13 <fantasai> RESOLVED: New Values boilerplate accepted
23:57:43 <astearns> topic: [css-images-4] Gradients with a single color stop
23:57:56 <astearns> github issue: https://github.com/w3c/csswg-drafts/issues/1576
23:58:24 <fantasai> leaverou: Intended to be allowed in images 3, was prose in the spec...
23:58:34 <fantasai> fantasai: Actually, no, the CR of gradients did not include it in prose or grammar
23:58:43 <fantasai> leaverou: But anyway, would like to relax in Images 4
23:58:58 <fantasai> leaverou: Doesn't allow a lot of use cases, but it's simple case and improves debugging / preview
23:59:06 <fantasai> leaverou: Can quickly see the gradient
23:59:16 <fantasai> leaverou: Use case of single color image isn't great, because we have image() function for that
23:59:19 <fantasai> leaverou: I'm fine either way
23:59:27 <fantasai> leaverou: But would allow it if it was up to me
23:59:31 <fantasai> leaverou: Thoughts?
23:59:57 <dbaron> seems reasonable to me if there aren't compatibility issues -- and if implementations can update in a reasonably synchronized way
23:59:58 <fantasai> Florian: Since it's a syntax you could easily accidentally write, hoping for it to do somehting, even though it currently does not, there's a non-trivial risk of web pages out there relying on it not working
00:00:08 <fantasai> Florian: Maybe not, but could be a case
00:00:12 <fantasai> leaverou: Could we get stats?
00:00:29 <fantasai> ChrisL: People wanted to do solid colors and animate ...
00:00:38 <fantasai> ChrisL: There were people who wanted to have a single color gradient
00:00:51 <fantasai> leaverou: We have image(<color>)
00:01:04 <fantasai> ChrisL: Which way should we move people , towards image() or linear-gradient()?
00:01:11 <fantasai> TabAtkins: Would prefer to move ppl to image(), much clearer and shorter
00:01:22 <fantasai> ChrisL: It's also unintuitive to get that effect.
00:01:44 <fantasai> Florian: If you use it as a start point for an animation, though, then linear(blue, blue) ...
00:02:16 <fantasai> TabAtkins: For animations, you need to match up number of stops anyway
00:02:23 <fantasai> leaverou: So the main use case seems to be debugging / tooling
00:02:28 <Florian> s/.../ is easily written/
00:02:36 <fantasai> astearns: We are over time, not hearing any implementers lining up for this
00:02:53 <fantasai> astearns: Maybe solicit feedback directly from implementers, if anyone wants to champion then add back to agenda
00:02:57 <fantasai> astearns: If not, shouldn't go in spec
00:03:15 <fantasai> astearns: Thanks everyone, we're done.
00:03:18 <fantasai> Meeting closed.
00:03:31 <astearns> topic: end
00:04:23 <astearns> trackbot, end meeting
00:04:23 <trackbot> Zakim, list attendees
00:04:23 <Zakim> As of this point the attendees have been Rossen_, dael, dauwhe, tgraham, bdc, rachelandrew, astearns, birtles, myles, TabAtkins, fantasai, antenna, gregwhitworth, leaverou,
00:04:26 <Zakim> ... bkardell_, tantek, dbaron, AmeliaBR, plinss, bradk, RachelNabors, melanierichards, ChrisL___really, Florian, ChrisL, nainar, alex_antennahouse, jensimmons, hober, smfr,
00:04:26 <Zakim> ... gsnedders
00:04:31 <trackbot> RRSAgent, please draft minutes
00:04:31 <RRSAgent> I have made the request to generate http://www.w3.org/2017/07/05-css-minutes.html trackbot
00:04:32 <trackbot> RRSAgent, bye
00:04:32 <RRSAgent> I see no action items