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