IRC log of css on 2017-07-05

Timestamps are in UTC.

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 <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