IRC log of css on 2020-12-16
Timestamps are in UTC.
- 16:55:55 [RRSAgent]
- RRSAgent has joined #css
- 16:55:55 [RRSAgent]
- logging to https://www.w3.org/2020/12/16-css-irc
- 16:55:57 [Zakim]
- RRSAgent, make logs Public
- 16:55:58 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 16:56:49 [Rossen_]
- Rossen_ has changed the topic to: Agenda for Dec 16 meeting: https://lists.w3.org/Archives/Public/www-style/2020Dec/0022.html
- 16:56:54 [Rossen_]
- present+
- 16:57:02 [dael]
- dael has joined #css
- 16:58:45 [chrishtr]
- present+
- 16:58:53 [dauwhe]
- dauwhe has joined #css
- 16:59:27 [becky]
- becky has joined #css
- 16:59:43 [dael]
- present+
- 16:59:47 [dael]
- ScribeNick: dael
- 17:00:16 [cbiesinger]
- present_
- 17:00:18 [cbiesinger]
- present+
- 17:00:23 [dael]
- Rossen: Hello everyone! We'll get going in a couple minutes
- 17:00:27 [Morgan]
- present+
- 17:00:35 [fremy]
- fremy has joined #css
- 17:00:43 [alisonmaher]
- alisonmaher has joined #css
- 17:00:48 [alisonmaher]
- present+
- 17:00:59 [dlibby]
- dlibby has joined #css
- 17:01:16 [dael]
- Rossen: For those that just joined we're waiting for a few more people
- 17:01:25 [dlibby]
- present+
- 17:01:40 [astearns]
- present+
- 17:01:48 [CSSWG_LogBot]
- CSSWG_LogBot has joined #css
- 17:01:48 [leaverou]
- present+
- 17:02:24 [jfkthame]
- jfkthame has joined #css
- 17:02:27 [dael]
- Rossen: I think we have a quorum and a full agenda
- 17:02:31 [brandon]
- present+
- 17:02:33 [miriam]
- present+
- 17:02:36 [rachelandrew]
- present+
- 17:02:45 [jensimmons]
- present+
- 17:02:46 [dael]
- Rossen: Before we get going wanted to hear if there are any extra items
- 17:02:59 [plinss]
- present+
- 17:03:02 [dael]
- florian: No changes, but a bunch of things within the EOY publications that were requested late
- 17:03:12 [faceless2]
- present+
- 17:03:12 [dael]
- Rossen: Yes, I intentionally didn't list b/c I know it would be incomplete
- 17:03:33 [dael]
- Rossen: Any other things?
- 17:03:40 [dael]
- Topic: EOY Publications
- 17:03:48 [fremy]
- present+
- 17:03:52 [dael]
- Rossen: I think fantasai had a bunch. Let's start with the one that are ready
- 17:04:14 [fantasai]
- https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0099.html
- 17:04:21 [dael]
- fantasai: First is CSS Text 3
- 17:04:30 [chris]
- chris has joined #css
- 17:04:35 [dael]
- Rossen: Woohoo!
- 17:04:37 [chris]
- present+
- 17:04:46 [drousso]
- drousso has joined #css
- 17:04:46 [dholbert]
- present+
- 17:04:47 [dael]
- fantasai: At 0 issues for first time in 18 years
- 17:04:49 [drousso]
- present+
- 17:05:10 [dael]
- Rossen: If anyone has an objection to this one...^-^
- 17:05:19 [florian]
- present+
- 17:05:31 [dael]
- Rossen: Let's followthe order. Objection sot publish css text 3 as CR
- 17:05:42 [dael]
- RESOLVED: publish css text 3 as CR
- 17:05:44 [florian]
- \(^o^)/
- 17:05:46 [oriol]
- oriol has joined #css
- 17:05:52 [oriol]
- present+
- 17:06:08 [chris]
- q+
- 17:06:08 [TabAtkins]
- present+
- 17:06:09 [dael]
- fantasai: WE sent 2/3 to CR already. writing modes and text decor require this. This is the last piece
- 17:06:26 [dael]
- chris: DoC, up to date changes, usual questions
- 17:06:30 [dael]
- fantasai: All in the email
- 17:06:31 [Rossen_]
- q?
- 17:06:36 [Rossen_]
- ack chris
- 17:06:38 [dael]
- florian: In terms of tests we're beyond what we need
- 17:06:47 [dael]
- fantasai: Should have been CR a long time ago, never got it together
- 17:06:54 [dael]
- chris: Who is going to raise the issue?
- 17:07:01 [dael]
- fantasai: I can file the transition request
- 17:07:10 [fantasai]
- https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0103.html
- 17:07:17 [dael]
- fantasai: Next is css images L3
- 17:07:22 [dael]
- fantasai: Minor update
- 17:07:27 [dael]
- Rossen_: That's a WD?
- 17:07:29 [dael]
- fantasai: CR
- 17:07:41 [dael]
- Rossen_: What's the update?
- 17:08:14 [dael]
- fantasai: Several, 4, substantive changes and one editorial change. Have to publish this so all other specs can crosslink the rename
- 17:08:16 [dael]
- florian: CRD?
- 17:08:21 [dael]
- fantasai: Yes, CRD for this.
- 17:08:32 [dael]
- Rossen_: CRD or CR?
- 17:08:36 [dael]
- fantasai: CRD is easier so that
- 17:08:43 [dael]
- Rossen_: Objections to new CRD for images 3?
- 17:08:49 [dael]
- RESOLVED: new CRD for images 3
- 17:08:54 [dael]
- fantasai: CSS grid 1 and grid 2
- 17:09:01 [dael]
- fantasai: Handful of mainly editorial fixes
- 17:09:16 [dael]
- Rossen_: Have 1 issue on grid for today. Any implications if we resolve?
- 17:09:16 [emilio]
- present+
- 17:09:30 [dael]
- fantasai: I believe there are a few minor editorial tweaks for that but they're included
- 17:09:34 [argyle]
- argyle has joined #css
- 17:09:38 [dael]
- Rossen_: Okay, so can proceed without
- 17:09:46 [dael]
- Rossen_: New CRD to Grid L1
- 17:09:48 [dael]
- Rossen_: Obk?
- 17:09:58 [dael]
- RESOLVED: New CRD for Grid L1
- 17:10:02 [dael]
- fantasai: And grid 2
- 17:10:19 [dael]
- Rossen_: Grid 2. Objections to republish a new CRD for Grid 2?
- 17:10:26 [dael]
- RESOLVED: republish a new CRD for Grid 2
- 17:10:37 [dael]
- fantasai: florian contain?
- 17:10:40 [smfr]
- smfr has joined #css
- 17:10:46 [dael]
- florian: Would like contain1 and contain 2. Start with 1
- 17:10:48 [smfr]
- present+
- 17:10:57 [dael]
- florian: contain 1 is rec, made a few editorial and 2 substantive
- 17:11:02 [fantasai]
- https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0104.html
- 17:11:18 [dael]
- florian: One is how we deal with computed values and the other is re-write of contain sizing. Didn't change behavior but old text was vague and short
- 17:11:54 [dael]
- florian: Resolved to do this, under p2020 we can make a new publication w/o requesting approval but by making annotations in spec we attend to do this. Done that editorially and can push with approval
- 17:12:05 [dael]
- florian: This would be the first use of this process and plh waiting on us to try
- 17:12:07 [Rossen_]
- q?
- 17:12:17 [dael]
- chris: This is the we can update the rec with new features or is this something else?
- 17:12:23 [dael]
- florian: Not new feature, just a correction
- 17:12:28 [dael]
- Rossen_: We just need a resolution?
- 17:12:42 [dael]
- florian: Yes. I think for mechanics a team member needs to do it, but we need resolution
- 17:12:50 [dael]
- Rossen_: Obj to update Containment 1 REC?
- 17:12:58 [dael]
- RESOLVED: update Containment 1 REC
- 17:13:12 [chris]
- Okay, if that is ready I can prep it for publication on Tuesday
- 17:13:21 [dael]
- florian: Just a REC. As before can do editorial. Substantive things are not done but are notes we want to so it's just a rec
- 17:13:38 [dael]
- florian: Containment 2. mostly resolved or editorial. I could almost repub but there's 1 item
- 17:13:40 [florian]
- https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-contain-2%2F&doc2=https%3A%2F%2Fdrafts.csswg.org%2Fcss-contain-2%2F#cv-notes
- 17:13:42 [dael]
- florian: This diff ^
- 17:13:52 [GameMaker]
- present+
- 17:14:08 [dael]
- florian: Discussed in a PR with several people but merged w/o resolution. Seems innocuous, but if anyone wants to not publish now is the time to say so
- 17:14:36 [dael]
- Rossen_: Besides the note the addition is the new restriction for visibility [reads]
- 17:14:41 [dael]
- Rossen_: That's the essense of it?
- 17:14:48 [dael]
- florian: Yes, everything else is resolved or editorial
- 17:15:07 [Rossen_]
- q?
- 17:15:31 [dael]
- Rossen_: Any objections to accepting the PR and republishing WD of containment 2?
- 17:15:44 [dael]
- chrishtr: Can you repeat the change?
- 17:15:59 [dael]
- florian: You approved it, you merged the PR where it was approved. There's a link to the diff in IRC
- 17:16:11 [dael]
- chrishtr: I approve that ^-^
- 17:16:33 [dael]
- RESOLVED: Accept the PR ( https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-contain-2%2F&doc2=https%3A%2F%2Fdrafts.csswg.org%2Fcss-contain-2%2F#cv-notes ) and republishing WD of containment 2
- 17:16:41 [dael]
- Rossen_: Other requests?
- 17:16:42 [dael]
- fantasai: Yes
- 17:16:43 [fantasai]
- https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0106.html
- 17:16:46 [dael]
- fantasai: CSS box model L3
- 17:17:10 [dael]
- fantasai: Requesting CR transition. no new features from css 2. Redefines padding and margin. Created so we had something to refer to and add terms.
- 17:17:35 [dael]
- fantasai: Couple issues asking for more terms but I think can do in CR. i18n completed review. I can't think reason why anyone else would care about a module with nothing new in it.
- 17:17:47 [dael]
- fantasai: I suggest we transition to CR so we have stable reference
- 17:18:00 [dael]
- Rossen_: I don't have issue with that. Question, what is benefit of advancing this to CR?
- 17:18:05 [dael]
- fantasai: So we can get to REC
- 17:18:10 [dael]
- Rossen_: If it doesn't add anything
- 17:18:17 [dael]
- florian: Adds terminology
- 17:18:19 [dael]
- Rossen_: Okay
- 17:18:27 [dael]
- chris: So that means it passes all tests in css 2?
- 17:18:28 [dael]
- fantasai: Yes
- 17:18:36 [dael]
- Rossen_: Can we go directly to rec :)
- 17:18:39 [bradk]
- bradk has joined #css
- 17:18:39 [dael]
- fantasai: I don't htink so
- 17:18:51 [dael]
- Rossen_: Obj to moving css box model 3 to CR?
- 17:18:56 [chris]
- lol
- 17:19:02 [dael]
- RESOLVED: Move css box model 3 to CR
- 17:19:05 [fantasai]
- https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0107.html
- 17:19:05 [bradk]
- present+
- 17:19:12 [dael]
- fantasai: backgrounds and borders L3
- 17:19:20 [dael]
- fantasai: Very stable, few changes. But should be republished
- 17:19:27 [dael]
- fantasai: Summary of tests ^
- 17:19:41 [dael]
- Rossen_: You said only editorial?
- 17:20:07 [dael]
- fantasai: 3 normative. First 2 have tests in wpt. 3rd is practically unobservable. I'm sure someone can write a test but I don't think will make a difference
- 17:20:20 [dael]
- Rossen_: Objections to new CR for Backgrounds and Borders 3?
- 17:20:26 [dael]
- Rossen_: And next time we can do CRD for it
- 17:20:39 [dael]
- RESOLVED: publish a new CR for Backgrounds and Borders 3
- 17:20:49 [fantasai]
- Topic: 2020 Snapshot
- 17:20:50 [fantasai]
- https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0105.html
- 17:21:14 [dael]
- fantasai: Last publication issue. florian and I reviewed 2020 snapshot. It is ready based on earlier discussion. We think a few specs should be added/shifted though
- 17:21:14 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/4715#issuecomment-745856263
- 17:21:25 [dael]
- fantasai: If it's okay I'd like to ask WG about possible changes.
- 17:21:47 [chris]
- github: https://bugs.webkit.org/show_bug.cgi?id=149772
- 17:21:50 [chris]
- oops
- 17:21:54 [dael]
- fantasai: First is add css box module L3 to top tier since it has no new functionality. Pretty stable
- 17:21:58 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/4715#issuecomment-745856263
- 17:22:00 [hober]
- hober has joined #css
- 17:22:07 [dael]
- fantasai: Let's go one by one
- 17:22:15 [dael]
- Rossen_: Objections to moving box to the top?
- 17:22:24 [dael]
- Resolved: move box to the top
- 17:22:33 [dael]
- fantasai: Next [missed]
- 17:22:40 [dael]
- fantasai: ditto for images L3 since we cleaned that up
- 17:22:50 [dael]
- fantasai: It is now in sync with all the changes and pretty stable
- 17:23:00 [dael]
- fantasai: Not top level as top, but stable spec with limited testing
- 17:23:10 [fantasai]
- https://drafts.csswg.org/css-2020/
- 17:23:20 [dael]
- Rossen_: Objections to moving images 3 to stable bucket?
- 17:23:27 [dael]
- RESOLVED: Move images 3 to stable bucket
- 17:23:39 [dael]
- Rossen_: Moving css ui 5 to stable limited test
- 17:23:44 [dael]
- RESOLVED: Moving css ui 5 to stable limited test
- 17:23:48 [dael]
- fantasai: Next few less sure
- 17:23:59 [fantasai]
- s/ui 5/sizing 3/
- 17:24:00 [fantasai]
- s/ui 5/sizing 3/
- 17:24:19 [hober]
- present+
- 17:24:30 [dael]
- fantasai: There was an issue against snapshot about transforms l2 to rough interop bucket
- 17:24:34 [dael]
- chris: It has one impl
- 17:24:39 [dael]
- chris: Chrome has a bug on it
- 17:24:49 [dael]
- fantasai: transforms 2 I thought multi impl of 3d transforms
- 17:24:57 [dael]
- chris: Yes, but single transform is only one impl
- 17:25:05 [dael]
- florian: Seems short for rough interop
- 17:25:15 [dael]
- fantasai: Could add and exclude those bits or save for next year
- 17:25:17 [dael]
- florian: Save it
- 17:25:25 [dael]
- fantasai: Other was color adjust 1. Maybe save for next year as well
- 17:25:42 [emilio]
- hmm, Gecko ships individual transform properties iirc
- 17:25:45 [dael]
- chris: Doesn't have any tests so claim of interop is hard to substantiate. Is it only human testable?
- 17:25:54 [dael]
- fantasai: SHouldn't require human interaction to work. We can do it next year
- 17:26:00 [dael]
- fantasai: I asked about color and font 4
- 17:26:05 [dael]
- chris: I responded.
- 17:26:06 [dael]
- Rossen_: 2021
- 17:26:08 [gsnedders]
- WebKit has an impl, but not shipped in Safari
- 17:26:29 [dael]
- chris: Color 4 is stable. A few bits are not. Closed enough that I expect cr in jan or feb. stable and getting impl
- 17:26:35 [gsnedders]
- s/an impl/an impl of individual transform properties/
- 17:26:37 [dael]
- fantasai: color 4 in stable needs testing or save for 2021
- 17:26:44 [dael]
- chris: let's say stable and needs testing.
- 17:26:48 [dael]
- chris: Same with fonts 4
- 17:27:00 [dael]
- Rossen_: color l4 move to sable needs testing
- 17:27:07 [dael]
- RESOLVED: color l4 move to stable needs testing
- 17:27:24 [dael]
- fantasai: fonts 4 a lot of open issues. Lot of impl happeneing but spec text mayne not stable
- 17:27:37 [gsnedders]
- do we not have tests for most of color l4 in WPT from when impls implemented it?
- 17:27:48 [dael]
- chris: It is. I disagree on issue. 2 groups of long running issues. generic font families and privacy issues. It's stable apart from those bits.
- 17:28:00 [dael]
- florian: There are 76 open issues. Are they all what you said?
- 17:28:08 [dael]
- chris: At least 3/4 of them
- 17:28:16 [dael]
- Rossen_: Seems a little early with number of issues
- 17:28:28 [dael]
- chris: I'll push a little but I'll fallback with graceful degredation
- 17:28:34 [dael]
- fantasai: I think we want to save that for next year
- 17:28:36 [dael]
- chris: Fine
- 17:28:49 [dael]
- fantasai: Prop publishing the snapshot 2020 as a note
- 17:28:52 [dael]
- chris: Grid 2
- 17:29:13 [dael]
- fantasai: Oh, yes. Grid 1 is rough interop but needs more testing. Grid 2 is a superset of 1.
- 17:29:22 [dael]
- fantasai: Part that's different in L2 has had no issues
- 17:29:32 [dael]
- fantasai: Might make sense to put them in the same bucket
- 17:29:36 [dael]
- chris: Makes sense to me
- 17:29:48 [fantasai]
- s/same bucket/same bucket, since what's holding 2 back is the shared part/
- 17:29:55 [dael]
- Rossen_: Publishing snapshot as a note. Objections?
- 17:29:58 [fantasai]
- s/bucket/bucket as 1/
- 17:30:03 [dael]
- fantasai: Didn't resolve on grid 2.
- 17:30:09 [dael]
- Rossen_: I thought we were not going to move
- 17:30:17 [dael]
- fantasai: Add to snapshot in same place as grid 1
- 17:30:22 [dael]
- Rossen_: Objections?
- 17:30:30 [dael]
- RESOLVED: Add grid 2 to snapshot in same place as grid 1
- 17:30:49 [dael]
- Rossen_: And now, are we ready to push snapshot 2020 as a note?
- 17:30:56 [dael]
- RESOLVED: Publish snapshot 2020 as a note
- 17:31:05 [dael]
- chris: What state is it in and when to prepare for publication?
- 17:31:15 [dael]
- fantasai: Need to make resolution edits. Tomorrow, I'm guessing
- 17:31:27 [dael]
- Rossen_: Anything else for publication?
- 17:31:30 [dael]
- fantasai: That's all I got
- 17:31:33 [dael]
- florian: I'm done
- 17:31:42 [dael]
- Topic: [css-variables?] Higher level custom properties that control multiple declarations
- 17:31:44 [jensimmons]
- Does that mean we get a CSS 2020 in 2020??
- 17:31:53 [astearns]
- just barely
- 17:31:59 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/5624
- 17:32:27 [dael]
- leaverou: I didn't explicitly add this. WE discussed last time and didn't get resolution. Interesting discussion in issue and off GH
- 17:32:32 [leaverou]
- https://github.com/w3c/csswg-drafts/issues/5624#issuecomment-746339609
- 17:32:34 [dael]
- leaverou: I summerized current state in ^ comment
- 17:33:10 [dael]
- leaverou: Summary: It looks like best course of action for block conditionals. Can't use pseudo class, casuse issues. If if() cascades have to carry extra context and increases too much complexity
- 17:33:30 [dael]
- leaverou: Best is impl if based on idea of desugering to inline if calls and take into account properties in same rule. example in comment
- 17:33:53 [dael]
- leaverou: Rasises some issues b/c certain values eval differently depending on prop. Hasn't come up that much. Length in some MQs
- 17:34:13 [dael]
- leaverou: For example, ones we could come up with TabAtkins is %, em values, rem, lh, rlh, currentColor.
- 17:34:13 [chris]
- rrsagent, here
- 17:34:13 [RRSAgent]
- See https://www.w3.org/2020/12/16-css-irc#T17-34-13-1
- 17:34:51 [dael]
- leaverou: Problem. If it desugars to inline if calls nad conditional has relative values you may have cases where part of rule eval to true and a part of false. Example in comment.
- 17:35:00 [dael]
- leaverou: Agreed don't want partial applicaitons. How to solve?
- 17:35:32 [dael]
- leaverou: Came up with defining how these relative values would be evaluated. cureentColor is as if in color and so on. New inline conditional function to desugar iff
- 17:35:39 [dael]
- leaverou: Doesn't sound good, but couldn't come with better
- 17:36:00 [bradk]
- bradk has joined #css
- 17:36:01 [dael]
- leaverou: Addresses single conditional. Css nesting has same partial applicaiton problme. May have condition true for a rule but not decendnents.
- 17:36:10 [Rossen_]
- q?
- 17:36:21 [dael]
- leaverou: Might have var warning = on and a value for --warning on parent and different value on the child
- 17:36:31 [dael]
- leaverou: You again have @if block applied paritially
- 17:36:49 [dael]
- leaverou: Not sure if there's a way to address this. Couldn't come up with anything but just discussed yesterday. Don't know if there are ideas
- 17:37:13 [dael]
- fantasai: What do you do if content has if clause with a property that effect evaluation. if on a em and evaluate em against font size
- 17:37:18 [dael]
- leaverou: Can you put example in IRC?
- 17:37:36 [fantasai]
- @if (var(...) > 1em) { font-size: 35pt; }
- 17:37:44 [dael]
- leaverou: I see
- 17:37:47 [dael]
- leaverou: I'm not sure
- 17:37:55 [dael]
- leaverou: What would you suggest should happen?
- 17:38:06 [dael]
- leaverou: It's basically same as if you have inline if
- 17:38:20 [dael]
- Rossen_: In interest of time, are we ready to resolve or should we take it back to GH and continue there?
- 17:38:48 [dael]
- leaverou: I suppose we could go back to issue
- 17:39:08 [dael]
- Rossen_: Let's do that. Let's continue discussing there. I was hoping we were closer to resolution then we are. We'll come back
- 17:39:16 [dael]
- Topic: [css-font-loading] Browsers disagree on what it means for a FontFace object to be "CSS-connected", and what effect does it have.
- 17:39:24 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/5707
- 17:40:39 [dael]
- emilio: Browser behave really oddly. Spec-wise spec says FontFace object once the rule is removed you should be able to use like it's not css-connected. A bit messy, browsers don't impl to the letter. Simplier would be if fontface created for a css rule it is concidered css-created. Then impl and spec are simplier
- 17:40:52 [dael]
- emilio: Given behavior is all over the place and it's an edge case it would be nice to simplify
- 17:41:03 [leaverou]
- fantasai: 1em evaluated against font-size refers to the *parent* font-size, so there's no conflict there. That's *why* we'd evaluate ems against font-size, to avoid that sort of thing
- 17:41:08 [dael]
- TabAtkins: What imacts does ti have on the connection between properties if we just make a flag for css-created
- 17:41:42 [dael]
- emilio: afaict is chrome and ff don't allow change of descriptor of fontface object. Per spec it's 2-way mapping. I think FF and Chrome don't impl. I don't see an issue with 2-way mapping as is.
- 17:41:55 [dael]
- TabAtkins: If keeping the connection I'm unclear what the change is
- 17:42:17 [fantasai]
- leaverou, I think it would be super unexpected if you evaluated em against font-size, unless all of the if clause lengths evaluate against the parent or something
- 17:42:29 [fantasai]
- s/font-size/parent font-size/
- 17:42:38 [dael]
- emilio: Per spec once you removet he rule from the style sheet, even though om wrapper for rule exists, the fontface object is diconnected from it. Means a lot of functions that need to check for css connection need to also update stylesheets and other expensive stuff
- 17:42:51 [fantasai]
- leaverou, and in that case, seems a lot less useful?
- 17:43:10 [dael]
- TabAtkins: So if you move a cssom fontface object into another stylesheet in another document so it shows in a different fontface set would that make 1 more object
- 17:43:24 [dael]
- emilio: afaict you can't do that. cssom method is strings so you need to stringify
- 17:43:35 [leaverou]
- fantasai: then the other options are: a) it evaluates differently per property, so you have partial application b) it evaluates against another property, e.g. width, so you have a cycle in font-size.
- 17:44:00 [dael]
- TabAtkins: Okay. If purely when an om rule is created it gets a corresponding object and that's a permanent connection I'm okay with that. Simplication. Fine with me
- 17:44:04 [Rossen_]
- q?
- 17:44:04 [dael]
- emilio: I think so too
- 17:44:08 [dael]
- Rossen_: Other opinions?
- 17:44:22 [dael]
- Rossen_: Summary?
- 17:44:52 [dael]
- emilio: Proposed: Change css-connected by css created bool where it cannot be unset until removed frmo a document
- 17:44:57 [fantasai]
- leaverou, sure I recognize those are bad... but also, it seems to me that the use cases would want to evaluate against the element itself
- 17:45:04 [dael]
- Rossen_: Objecitons?
- 17:45:17 [dael]
- RESOLVED: Change css-connected by css created bool where it cannot be unset until removed from a document
- 17:45:42 [dael]
- emilio: Another issue in this. That was changing definition. Now what happens to document.fonts.add with that object
- 17:45:45 [fantasai]
- leaverou, if that's not the case and evaluating the parent font size is useful and expected, great, but if not, then making it implementable isn't actually solving the problem
- 17:45:49 [dael]
- emilio: It's in the same issue, but needs different resolution
- 17:46:33 [dael]
- emilio: it's when it's from a rule created in another document. I think blink does nothing. Spec says throw which is what gecko does. Doesn't match WK or blink. Happy to use either, both are reasonable.
- 17:46:36 [dholbert]
- dholbert has joined #css
- 17:46:52 [dael]
- emilio: It does nothing if called on same document which is odd. I think easiest is follow blink
- 17:46:57 [dael]
- TabAtkins: Meaning it doesn't get added to set?
- 17:46:58 [dael]
- emilio: Right
- 17:47:06 [dael]
- TabAtkins: No opinion on throw or ignore. Whichever
- 17:47:32 [dael]
- emilio: I don't care either. Throw to do nothing is a bit easier for use. Doing nothing to throwing may break. No strong opinion. Whatever gets faster interop
- 17:47:57 [dael]
- TabAtkins: Seems rare to do this. I suspect we could move to throw and I would prefer because it's an error. Do we have an issue to fix in chrome?
- 17:48:04 [dael]
- emilio: I'm okay change to throw
- 17:48:13 [dael]
- TabAtkins: I'll try that and talk to Rune. If not we'll come back
- 17:48:47 [dael]
- Rossen_: With my TAG hat I'd argue strongly for throwing. There's a pretty clear guidance on this pattern. Should do most observable. Let's not have silent error. I agree with prop
- 17:48:50 [dael]
- Rossen_: Objections?
- 17:49:03 [dael]
- RESOLVED: Have it throw an error
- 17:49:36 [dael]
- RESOLVED: have document.fonts.add when called with css create fontface object throw an error
- 17:49:36 [leaverou]
- fantasai: If you look at the use cases wrt WC, none of them really seems to need ems. We just need to define what happens when someone uses it that way. I agree that parent is not that useful, but not sure the alternatives are better. I'm hoping there might be a 4th alternative we haven't considered, but I think the top priority would be to make sure that either the entire @if is applied or none of it, even if some values become less useful in
- 17:49:37 [leaverou]
- conditions.
- 17:49:53 [dael]
- Topic: [css-color-adjust] It's a bit unfortunate that user stylesheets can't specify arbitrary colors.
- 17:50:00 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/5779
- 17:50:30 [dael]
- emilio: I don't htink it's huge. Came up when reviewing changes to forced colors. It's a bit unfortunate user colors stop working
- 17:51:03 [dael]
- emilio: I don't have a super great use case for user stylesheets spec arbitrary colors. I don't think it's huge but wanted to raise b/c it's weird.
- 17:51:13 [Rossen_]
- q?
- 17:51:24 [dael]
- fremy: I think we did consider it. You can spec any color and say forced color adjust none
- 17:51:27 [dael]
- emilio: Yeah
- 17:51:41 [dael]
- fremy: You want to do it anyway to disable backplate. You can say antying in stylesheet.
- 17:51:48 [fantasai]
- or stick to the forced colors palette
- 17:52:06 [dael]
- emilio: Would need to disable for everything but yeah. It's a different behavior. not a huge issue. Can disable forced-colors all together or change system colors to match what you want
- 17:52:15 [dael]
- Rossen_: Doesn't sound like there's anything ot resolve
- 17:52:19 [dael]
- emilio: Resolve no change
- 17:52:22 [dael]
- Rossen_: Objections:
- 17:52:26 [dael]
- RESOLVED: Close no change
- 17:52:34 [dael]
- Topic: css-color-adjust] [css-scrollbars] scrollbar-color should probably compute to auto in forced-colors mode.
- 17:52:42 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/5778
- 17:53:08 [dael]
- emilio: This was the case I could think of b/c we don't have system color for scrollbars. Probably should force to auto and have system scrollbar colors to show
- 17:53:12 [fremy]
- sounds reasonable to me
- 17:53:16 [dael]
- Rossen_: Sounds sensible. Other opinions?
- 17:53:46 [dael]
- Rossen_: Prop: Scrollbar colors should compute to auto in forced-colors mode
- 17:53:51 [dael]
- RESOLVED: Scrollbar colors should compute to auto in forced-colors mode
- 17:54:07 [dael]
- Topic: [css-scroll-snap-1] Snap area trapping behavior of non scrollable elements
- 17:54:28 [dael]
- github: https://github.com/w3c/csswg-drafts/issues/4496
- 17:55:24 [dael]
- fantasai: Added b/c we had original set up scroll-snap-type where if it's non-inital it traps snaps. If elements inside asking for snap position we ignore. scroll cotnainers have to trap. Added additional behavior for scroll-snap-type so if someone wants to say in this area ignore a snap position they could do so
- 17:55:54 [dael]
- fantasai: Seems this is difficult to impl for Blink. Do we want to not have the behavior? Would mean only way to prevent contents from having snap behavior is put in a scroll container
- 17:56:21 [dael]
- Rossen_: It's a hack. The hack will work. People will hate the hack. It'll probably end up in css hacks books.
- 17:56:30 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/4496#issuecomment-706333521
- 17:56:33 [dael]
- Rossen_: Is it really that difficult that we should go to that extent.
- 17:56:39 [dael]
- fantasai: Here's comment from impl ^
- 17:56:48 [dael]
- fantasai: I'm not aware of any requests for the behavior
- 17:57:02 [dael]
- Rossen_: non-Blink impl with opinion?
- 17:57:15 [dael]
- smfr: My hunch is it doesn't make sense for non-scrollable things to trap snapping
- 17:57:23 [dael]
- fantasai: Within that element we don't track snap position
- 17:57:33 [dael]
- Rossen_: Image in a carosel scenario?
- 17:58:16 [dael]
- fantasai: No. a section and in that section there's properties setting snap points, you can turn that off. You can say this element ignore the snap positions. We can just not have that behavior and see if someone complaints
- 17:58:31 [fantasai]
- s/positions/positions inside/
- 17:58:37 [dael]
- Rossen_: In interest of time we can resolve here. If there are no strong arguments for keeping it I'm fine with that
- 17:58:48 [dael]
- smfr: Looked at WK and would be easy to impl
- 17:59:00 [dael]
- Rossen_: Argument for reverting doesn't seem to be a problem for WK
- 17:59:19 [dael]
- Rossen_: What if we keep issue open and when we get to actual impl and get experience I think that's when we come back and decide
- 17:59:22 [dael]
- fantasai: Mark at-risk?
- 17:59:24 [dael]
- Rossen_: Sensible
- 17:59:27 [dael]
- Rossen_: Objections?
- 17:59:35 [dael]
- RESOLVED: Mark this property at-risk
- 17:59:47 [dael]
- Topic: end
- 17:59:55 [dael]
- Rossen_: We're at the end of the call.
- 18:00:05 [dael]
- Rossen_: I'd like to use the last few seconds for the yearly summary
- 18:00:26 [dael]
- Rossen_: Have resolved and made 52 publishings. 4 notes, 31 wd, 16 cr and 1 REC
- 18:00:32 [dael]
- Rossen_: Over 192 resolutions
- 18:00:56 [fantasai]
- dael+++++++++
- 18:01:28 [dael]
- Rossen_: Crazy year, very busy. I want to thank all the members for participating, editors for working, staff for helping us, dael for scribing, and everyone for putting up with what 2020 brought us. WG showed up strong.
- 18:01:41 [dael]
- Rossen_: Thank you everyone for going through this together and let's hope for a better 2021
- 18:01:48 [dael]
- [lots of cheering]
- 18:07:19 [antonp]
- antonp has joined #css
- 18:30:27 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/12/16-css-minutes.html fantasai
- 18:30:44 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/12/16-css-minutes.html fantasai
- 18:31:25 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/12/16-css-minutes.html fantasai
- 19:03:32 [bradk]
- bradk has joined #css
- 19:43:37 [dauwhe]
- dauwhe has joined #css
- 20:00:33 [zhengxu]
- zhengxu has joined #css
- 20:14:13 [Zakim]
- Zakim has left #css
- 20:25:01 [dauwhe]
- dauwhe has joined #css
- 20:30:28 [dauwhe]
- dauwhe has joined #css
- 20:46:46 [jensimmons]
- jensimmons has joined #css
- 20:59:06 [fantasai]
- TabAtkins: Yo, need you to merge https://github.com/tabatkins/bikeshed/pull/1834 so we can publish
- 20:59:46 [TabAtkins]
- Been busy this morning, will get to in a bit.
- 21:28:27 [zhengxu]
- zhengxu has joined #css
- 21:40:03 [jensimmons]
- jensimmons has joined #css
- 21:40:37 [gonggong]
- gonggong has joined #css
- 21:42:37 [gonggong]
- gonggong has left #css
- 22:57:37 [zhengxu]
- zhengxu has joined #css