19:53:19 RRSAgent has joined #css 19:53:19 logging to https://www.w3.org/2020/10/19-css-irc 19:53:21 RRSAgent, make logs Public 19:53:22 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 19:57:51 Morgan has joined #css 19:58:44 I may be able to be around for a few bits and pieces of the meetings this week, but mostly I won't be able to be around. 20:00:11 dlibby has joined #css 20:01:24 zhengxu has joined #css 20:01:42 alisonmaher has joined #css 20:02:13 present+ 20:02:25 present+ 20:02:28 tantek has joined #css 20:02:33 present+ 20:02:33 present+ 20:02:39 present+ 20:02:43 present+ 20:02:43 present+ 20:02:44 present+ 20:02:47 present+ 20:02:50 present+ 20:02:53 present+ 20:03:01 present+ 20:03:08 present+ 20:03:09 present+ 20:03:38 present+ 20:03:40 ScribeNick: heycam 20:03:57 present+ 20:04:09 present+ 20:04:11 drousso has joined #css 20:04:13 present+ 20:04:41 present+ 20:04:52 present+ myles 20:04:55 GameMaker has joined #css 20:05:38 present+ 20:05:42 present- 20:05:47 present+ 20:05:52 I can if need be however this is me gesturing the touch UI of my iPad 20:05:54 present+ 20:06:02 bkardell_ has joined #css 20:06:13 Scribes [Cam, Tab, Myles, Tantek] 20:06:37 present+ 20:07:34 Topic: Introductions 20:07:44 brandonferrua has joined #css 20:07:58 Rossen Atanassov, Microsoft 20:07:58 present+ 20:08:03 Alan Stearns, Adobe 20:08:12 Alison Maher, Microsoft 20:08:41 Cameron McCormack, Mozilla 20:08:49 Daniel Libby, Microsoft 20:09:13 present+ 20:09:29 Elika Etemad aka fantasai, Invited Expert 20:09:51 Emilio Cobos, Mozilla 20:09:53 François REMY, Invited Expert 20:10:11 Brian Kardlel, Igalia 20:10:26 Javier Fernandez, Igalia 20:10:33 Florian Rivoal, Invited Expert 20:10:37 Manuel Rego, Igalia 20:11:06 Miriam Suzanne, Invited Expert 20:11:08 Oriol Brufau, Igalia 20:11:28 Myles C. Maxfield, Apple Inc. 20:11:38 PLH, W3C 20:11:39 Tantek Çelik, Mozilla 20:11:46 Theresa (Tess) O'Connor, Apple 20:11:49 Megan Gardner, Apple 20:12:05 Mike Bremford, BFO 20:12:09 Morgan Reschenberg, Mozilla 20:12:10 Brandon Ferrua, Salesforce 20:12:14 Ting-Yu Lin, Mozilla 20:12:36 q+ 20:12:39 q- 20:12:39 Tab Atkins, Google 20:12:42 [[ Type q+ into IRC to add yourself into the queue ]] 20:12:56 Topic: Republishing tasks 20:12:59 github: https://github.com/w3c/csswg-drafts/issues/5613 20:13:21 chris has joined #css 20:13:34 fantasai: we are super behind on keeping outselves up to date on TR pages 20:13:42 ... as of Sep 13 the Process has been updated 20:13:51 ... I created this issue to make sure we get around to publications 20:14:00 ... Houdini is mostly not published, for several years 20:14:06 ... open request for Sizing 20:14:16 ... any other people who want to request publication, agenda+ this issue 20:14:23 ... then we can use this issue to track whether it got published 20:14:38 ... at astearns's request, I made an "estimated publication badness chart" 20:14:42 http://fantasai.inkedblade.net/style/reports/csswg-status-radar/ 20:14:47 q+ 20:14:52 fantasai: if you want to edit this file it's in GitHub 20:14:57 ... there are lots of spec that need publication! 20:15:06 ... it's causing confusion for other groups 20:15:43 ... publishing is easy. if you're confused on how to do it, ask in IRC 20:16:05 ... the one thing without resolution that needs it is sizing-4 20:16:09 https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0015.html 20:16:10 ... that's a WD 20:16:30 q? 20:16:31 present+ 20:16:31 RESOLVED: Publish sizing-4 20:16:34 ack astearns 20:16:53 q+ 20:16:59 q+ 20:17:00 astearns: based on fantasai's analysis of things that haven't been updated on TR, I've started reaching out to editors to see if we can get the ones that are (in some cases) nearly a decade out of date published 20:17:29 fantasai: cascade-3 is blocked 20:17:44 ... on various Proposed Rec things 20:18:18 chris: conditional-3 has the oldest one I think, 2013 20:18:40 ... it's getting there, should we get an updated CR on that? 20:18:44 fantasai: CRD? we can do that 20:19:00 ... Process 2020 has two types of CR publications 20:19:26 ... the official snapshot, that goes through approvals etc. then there's Candidate Rec Draft, similar to WD, which allows some open issues 20:19:46 ... a CRD has to represent WG consensus 20:19:57 smfr has joined #css 20:19:58 Rossen_: any delta between what would be in the CRD and what is currently in broad horizontal review? 20:20:15 fantasai: yes. there a bunch of changes since the last PR 20:20:20 s/PR/CR/ 20:20:39 Rossen_: do we have to go and review all the changes? 20:20:45 fantasai: no, purpose of CRD is so you don't have to do that, or the DoC 20:21:00 ... have to list changes since the last CR, and WG consensus on material different from the last CR 20:21:18 florian: goal is equivalent in quality to CR, but less process heavy 20:21:50 dbaron: just need a resolution, if nobody objects, it's WG consensus 20:21:52 q? 20:21:52 s/dbaron/chris/ 20:22:17 RESOLVED: publish CRD of conditional-3 20:22:29 ack chris 20:22:32 ack florian 20:22:34 present+ 20:22:59 florian: back when Tess was an editor, we were going to have an event handler section in highlighter 20:23:07 ... the rest of the spec is not final, but it's FPWD-ish 20:23:10 s/highlighter/highlight-api/ 20:23:10 ... proposing we publish it as is 20:23:19 ... there's a placeholder in the ToC for event handling 20:23:28 ... but having live material live off /TR for years is not good, so let's publish it 20:23:47 Rossen_: who are the authors? 20:23:53 +1 20:24:19 hober: editors will be Megan, Florian, Sanket 20:24:34 florian: I will fill that in, then work with Megan/Sanket to get issues resolved after publishing 20:24:43 RESOLVED: publish highlight-api 20:25:26 fantasai: just want to note that env and scroll-animations also should be published 20:25:35 s/should be published/have no FPWD/ 20:26:17 florian: as Alan pings authors, we'll follow up with the env folks 20:26:22 s/florian/Rossen/ 20:26:53 Topic: Fix aspect-ratio errors in css-grid-1 20:26:58 github: https://github.com/w3c/csswg-drafts/issues/5615 20:27:27 fantasai: there was a commit which attempted to clarify interaction of aspect-ratio and grid item sizing 20:27:31 ... that introduced an error, which I fixed 20:27:37 ... I'd like to verify the fix with the WG 20:27:50 ... and republish grid-1 and grid-2 with the correction 20:27:53 ... as a CRD 20:28:05 Rossen_: is there a commit diff we should be looking at? 20:28:12 ... or just that PR that you linked there 20:28:17 https://drafts.csswg.org/css-grid-1/#grid-item-sizing 20:28:27 fantasai: commit I linked, that shows the fix to the problem, but the resulting text needs to be reviewed 20:28:37 q? 20:29:12 Rossen_: we resolved for this change that will be different from flexbox, right? 20:29:20 fantasai: this one wasn't supposed to be a change, just a clarification 20:29:30 ... can grab a diff against the older version 20:30:06 https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FCR-css-grid-1-20171214%2F&doc2=https%3A%2F%2Fdrafts.csswg.org%2Fcss-grid-1%2F#grid-item-sizing 20:30:21 https://github.com/w3c/csswg-drafts/commit/ee91993c92ba7d119a6b89c64667094511d67272 20:30:55 rrsagent, here 20:30:55 See https://www.w3.org/2020/10/19-css-irc#T20-30-55 20:31:03 rrsagent, make minutes 20:31:03 I have made the request to generate https://www.w3.org/2020/10/19-css-minutes.html chris 20:31:11 Rossen_: any comments or objections to accept this diff? 20:31:32 oriol: I think it's a good change, because there was a sentence saying that for stretch the rules would be modified to follow aspect-ratio. but impls were not doing that 20:31:40 ... so if you have stretch, aspect-ratio is not taken into account 20:31:44 ... so I think removing this sentence is good 20:31:47 I was hoping oriol had reviewed this. Given that he has, I feel confident it's fine :) 20:32:12 (There was a line attributed to me above that wasn't me, btw.) 20:32:24 RESOLVED: accept aspect-ratio error changes in css-grid-1 20:33:40 Topic: Resolution of percentage row tracks and gutters with indefinite height 20:33:44 github: https://github.com/w3c/csswg-drafts/issues/5566 20:34:06 rego: this is an old discussion 20:34:28 ... this is about how we resolve percetange row tracks/gutters 20:34:33 ... with a minimum height 20:34:38 ... we resolve to intrinsic height that we compute 20:34:41 ... that causes overflow in many cases 20:34:48 ... and makes it more complicated, and no interop 20:35:07 ... in Firefox it is doing the old behavior. %age tracks resolve to auto 20:35:16 ... I was proposing here to change again, and get interop in this case 20:35:32 ... and then also change how gutters work, which Firefox does do 20:36:05 ... we have been discussing for a long time, checking compat issues, we already had a use counter for %age tracks, also for gutters 20:36:09 q? 20:36:13 ... checking the results, grid tracks where 0.03% of page views 20:36:30 ... that's going down, to not count 1 row with 100% 20:36:38 ... we analyzed the pages from that, only 1 broke 20:37:06 ... with gutters, the usage is very low. 0.003% of page views 20:37:09 ... 40 pages, only 1 broke 20:37:21 ... so this change will align us with flexbox, and get interop in the tracks part that we don't have right now 20:37:54 Rossen_: we did discuss this in the past, in the context of flexbox, grid and gutters. every time the discussion goes around and comes back to one of the main points/principles for grid 20:38:13 ... which is to hold the behavior of rows and columns, and row gutters / col gutters, to be symmetric 20:38:16 ... strong desire for this 20:38:23 ... strong pushback against things going against this principle 20:38:30 ... don't want to relitigate that 20:38:45 ... so why should we change it for this one? 20:38:55 rego: it will break that principle. the reasons we should change are in the top of the issue 20:39:00 ... it usually causes overflow when people use it 20:39:09 ... it requires worse perf in track sizing 20:39:12 ... and we don't have interop 20:39:19 ... but I agree it will break that principle 20:39:26 q? 20:39:56 Rossen_: would like to hear from more people. personal preference to hold on to that principle 20:40:09 ... it's an easy slippery slope to get on 20:40:37 ... yes there are expectations when they compare other 1D layout systems like block and flexbox. 20:40:48 ... with this particular one, I think we should hold a high bar in keeping that principle going forward 20:41:17 jensimmons: I haven't heard much about this kind of stuff at all 20:41:25 ... feel like authors haven't quite grasped grid fully yet 20:41:35 ... lack of compat is a problem, would like interop asap, even if the behaviour feels a bit buggy 20:41:45 ... and stop using percents for gutters anyway 20:41:57 ... so in some ways I don't really care about this, since they shouldn't be using percentages 20:42:33 Rossen_: I think the data agrees with your observations, few cases in the wild 20:42:47 ... doesn't feel like it's strongly motivated 20:42:52 miriam: that's my experience as well 20:42:57 fantasai: I think it'd be good to hear from mats and rachel 20:43:08 ... if nobody else had anything else to add, could defer to hear from them 20:43:17 Rossen_: in the meantime we can publish grid-1 and grid-2 as CRDs 20:43:35 Topic: Fix aspect-ratio errors in css-grid-1 20:43:40 github: https://github.com/w3c/csswg-drafts/issues/5615 20:43:57 Rossen_: any objections to publishing a CRD for grid-1? 20:44:05 RESOLVED: publish a CRD for grid-1 20:44:12 Rossen_: and for grid-2? 20:44:20 RESOLVED: publish a CRD for grid-2 20:44:38 Topic: Clear 'aspect-ratio' for shipping 20:44:50 github: https://github.com/w3c/csswg-drafts/issues/5598 20:45:17 fantasai: do we want to add aspect-ratio to the snapshot? 20:45:23 ... suitable for shipping in impls yet? 20:45:37 cbiesinger: the intent to ship has been approved 20:45:43 ... so we are planning to ship in the next version 20:45:51 q? 20:46:00 heycam: we are also making good progress, will be ready in the coming months 20:46:54 fantasai: this wouldn't be CR, needs more work before that 20:47:07 ... we add it to snapshot-2020 in the "not CR but ready for shipping" section 20:47:38 heycam: issue status? 20:47:41 fantasai: thing most have been resolved 20:47:47 ... Tab and I did a triage recently 20:48:07 Rossen_: will we reach CR if we go through these issues? 20:48:16 fantasai: sizing-4 is a WD 20:48:22 Discussion is about adding to https://www.w3.org/TR/CSS/#CR-exceptions 20:49:06 RESOLVED: add aspect-ratio to the "clear for shipping despite not being in CR" section of snapshot-2020 20:49:22 Topic: How widely should HTML's 'aspect-ratio' presentational attribute be applied? 20:49:27 github: https://github.com/w3c/csswg-drafts/issues/5608 20:50:17 TabAtkins: Emilio brought up in the HTML spec that it would make sense to make the aspect-ratio attribute integration from width/height setting intrinsic size, to being them setting an intrinsic ratio pres hint 20:50:23 ... I wrote the spec text for it 20:50:30 ... Domenic asked which elemetns it should apply to 20:50:35 ... prev spec text applied to img specifically 20:50:40 ... (side discussion about ) 20:50:50 ... but there are other elements that we do use width/height on 20:50:59 ... video, possibly embed/object 20:51:11 ... canvas, 20:51:13 q 20:51:16 q+ 20:51:34 ... first question, does it make sense to widen the spec text from the previous img/picture only, and if so, which elements should we expand it to? 20:51:43 ... I think we should, and go with elika's list 20:52:10 ... embed/object applying an intrinsic ratio doesn't always apply) 20:52:29 q+ 20:52:47 jensimmons: to remind everyone, this is about improving the experience for users while the page is loading 20:52:56 ... the intention is that it has no affect on layout after these assets have loaded 20:52:56 ack jensimmons 20:53:08 ... once an image has loaded, it should get the same layout it would've had 20:53:12 ... should work the same way for video 20:53:18 ... they do have an intrinsic aspect ratio 20:53:29 ... should apply to any HTML element where this is true 20:53:43 ... so does not apply to a typical iframe, since they don't have intrinsic aspect ratio 20:54:05 ... it's also true that embed/object can sometimes have an intrinsic aspect ratio 20:54:10 q+ 20:54:14 ... but if there are complications it's not critical 20:54:21 emilio: I agree with this 20:54:27 ack emilio 20:54:41 ... when we initially implemented this for img, we still didn't have the compat requirements 20:54:49 ... I think this is pretty reasonable 20:54:58 florian: makes a lot of sense to me 20:54:59 ack florian 20:55:12 ... given the text you're replacing didn't apply to these things, is the compat story different for img and the things that are like it? 20:55:16 ... or it all falls into the same bucket? 20:55:36 emilio: when we did it for img, we override the aspect ratio, but people put wrong values 20:55:41 ... the auto value is like a low priority hint 20:55:50 ... I think the compat impact is going to be extremely low 20:55:58 florian: canvas loads a bit differently from these other things 20:56:05 ... you don't load an external file 20:56:20 TabAtkins: intrinsic size is based on the backing store 20:56:32 florian: script controlled? and so if the script hasn't run yet it's a similar situation? 20:56:39 myles: it's based on the attributes on the element 20:56:46 TabAtkins: you're right 20:56:50 q? 20:56:59 ... but it would still be consistent with images 20:57:03 florian: less useful but still doesn't hurt 20:57:17 Rossen_: in the case of picture/srcset, does it come from the first image? 20:57:25 emilio: I think it would be the actual inside the picture 20:57:31 ... but there's another PR to make width/height apply to src 20:57:51 ... there's no precedent for other elements' attributes affecting intrinsics 20:57:57 TabAtkins: but that's behind discussed elsewhere 20:58:02 s/behind/being/ 20:58:26 img, input type=image, video, canvas 20:58:49 RESOLVED: apply aspect ratio pres hint to img, , video, canvas 20:59:38
(back at :10 after your hour) 21:01:04 topic: break 21:13:27 ScribeNick: myles 21:13:40 Topic: zoom! 21:13:44 github: https://github.com/w3c/csswg-drafts/issues/5623 21:14:06 dlibby: Last time this was discussed as 5 years ago. The zoom property came from IE. It was picked up by webkit / blink. 21:14:52 dlibby: it's a bit hacky tbh in the way it's implemented. multiplies the used values by a factor. Comes with a factor of bugs. Gecko doesn't implement it, so they've been running into compat issues 21:14:56 dlibby: There have been attempts to implement in terms of transform / transform-origin. It fixed some content, but didn't fix everything 21:15:26 dlibby: We should try to standardize this. What appetite is there for documenting existing bugs / odd behavior vs trying to fix them. 21:15:57 dlibby: Broader context: From MS, there are a few properties that have been looking at zoom as a low-cost way of zooming in on a webkit. They use it and get good results, and haven't had to rearchitect their app / change their layout structure. 21:16:04 present+ leaverou 21:16:05 dlibby: Others' thoughts? 21:16:19 present+ dbaron (intermittently) 21:16:21 zcorpan has joined #css 21:16:52 emilio: I made my comment in the issue. I would not be a fan of standardizing the current behavior. It's extremely wrong. 21:17:24 emilio: There's a bunch of quirks that exist for compat. I only found out by chance. Like zoom affecting intrinsic sizing of some elements but not others, or zoom:0 = zoom:1, because why not. It feels to me like the property is really odd b/c it's a property that affects the computed style of pretty much all lengths, including font size, which is terrible. Ot 21:18:08 emilio: It's one of the biggest compat issues we have to fix. But we might break more content than we fix. If it was me, I would try to remove it from Chromium. But that's not a big [missed]. That may require Chromium implementing -moz-transform, which isn't great. it's a mess. I would be skeptical standardizing this as-is right now. 21:18:51 astearns: I don't think there would be much utility in documenting the existing weirdness in CSS-space. I would be much more interested if someone had a solution they wanted to have implementations move toward. Something that was interoperable and didn't have quirks 21:19:09 florian: I agree the current thing is messy, but it's used. If you want to write a browser that works with the web, you need this thing. That's what the usage data tells us. If's being used, it should be known how it works. 21:19:11 q+ 21:20:04 ack emilio 21:20:05 florian: I am not sure it's only being used for its primary purpose. Maybe it's used *for* its quirks. Maybe it depends on its quirks. I believe they no longer care strongly about this, but Bloomberg could have used transforms, but font-rendering was different than that, and this is a quirk, and they were desired by Bloomberg. If we can't get rid of it, we should write down what it is 21:20:52 emilio: I would argue that you don't necessarily need to implement zoom to render the web. There's content that either depends on .... I think it would be interesting to disable the property in Chrome and see what breaks and what works in Firefox. The 2 solutions are prefixed -moz-transform + no zoom, or zoom + no prefix -moz-transform 21:20:59 emilio: You don't want double-scaling which sucks 21:21:08 florian: Is moz-transform cleaner? 21:21:23 emilio: -moz-transform is an alias to transform. 21:21:30 q+ 21:21:42 fantasai: Would Chrome be able to remove zoom and add -moz-transform as an alias of transform? 21:21:47 ack dlibby 21:22:48 q+ 21:22:52 dlibby: That might be worth exploring. The behavior is not identical between a scale transform and a zoom. To pursue something that would provide similar functionality sounds like there might be some interest in doing something like that from the group? Or at least no clear opposition? But that's an interesting experiment in Chromium - understanding the impact of turning off zoom. 21:22:52 dlibby: I don't know if there's precedence, thought. I'd have to consult with others. The idea is interesting. 21:23:05 florian: There is precedence for setting in stone things with odd names with vendors in them. Maybe not -moz- specifically though. 21:23:45 fantasai: It would be better for the web if we did that because it's one less quirky weird unspecified thing that needs to be embedded in the platform, if it's just an alias. If we can have a zoom feature that does what people want, it would be a good way forward. If it can't be removed, we have to spec it. 21:23:47 ack fremy 21:24:08 s/it can't/legacy zoom can't/ 21:24:17 fremy: one question: The zoom property can, if you have grid + some elements, the zoom property, zoom:200%, it not only scales the element but also changes the size of the tracks. 21:24:24 florian: It is layout-affecting transforms. 21:24:31 fremy: You can't achieve that with transform 21:24:42 q+ 21:24:51 florian: The way that zoom affects layout is weird. Can we remove the weird one, or do we have to spec it 21:24:56 fremy: Can we redefine how zoom works that's sane? 21:25:14 fremy: Can we look at this? What is the minimum amount of things that makes zoom useful and sane, but are more powerful than transforms. 21:25:38 s/The way that zoom/Layout-affecting zoom is useful and we should have a feature that does that. However, the way that legacy zoom/ 21:25:40 fremy: If you don't know what all the tricks are, it's scary to implement, but if we all agree on something similar and that works, it's a safer bet than something nobody understands 21:26:07 florian: If we could do this, that would be good. I believe we had looked and concluded we couldn't change it. It's strange, but the sites we looked at relied on its weirdness 21:26:08 astearns: right. 21:26:13 ack jensimmons 21:26:31 q+ 21:27:23 jensimmons: For a long time I've thought one of the thigns that was not exciting about transforms and motion-path is none of them affect sizing / calculation, especially for calculating flow. If you make something bigger or move it over, it doesn't affect anything around it. It's an interesting space. Zoom is one of the qualities we might want to look at about making transforms affect sizing and layout. I hate when the answer to a small problem is 21:27:23 "let's make something incredibyl complicated" but that feels like the right direction. 21:27:34 jensimmons: zoom is unspecified and has total lack of interop. 21:27:43 I think we had a working group resolution to pursue layout-affecting transforms. :-/ I remember an extensive discussion of it in a meeting -- and I remember SteveZ was there. 21:28:11 jensimmons: It was trying to do everything in one property. We should break it down and say "actually what we really want is have layout-affecting transformations" or "maybe there should be alternative ways that fonts should be rendered" 21:28:15 ack heycam 21:28:32 heycam: To follow-on from jensimmons, I'm curious dlibby what the specific things that these authors are trying to get out of it, and why regular transforms were not sufficient. 21:28:34 q+ 21:28:35 q+ 21:29:20 btw, I made this demo while listening to see what's different between zoom & transform scale: https://codepen.io/jensimmons/pen/gOMMJMz 21:29:24 zakim, close queue 21:29:24 ok, astearns, the speaker queue is closed 21:29:29 dlibby: One of the compelling use cases was outlook web access to zoom in the reading pane for your emails. These emails were coming in with arbitrary styles / content / sizing, so enabling jsut that section, but no horizontal overflow, zoom gave them a low-cost way of doing it. "hey it could work" it keeps the layout constrained in the inline direction. They've been happy with results in Safari and Chrome and Edge so far. That's the main use case. 21:29:39 dlibby: There were a few other use cases that were less compelling. 21:29:50 dlibby: This one is the most compelling to me. 21:29:52 ack emilio 21:30:21 emilio: If you're zooming arbitrary content, zoom doesn't work. Percentages don't get scaled. Which is one of the quirks of the zoom property. I guess for email it kinda works because most emails are fixed sizes, but that's a very specific use case to justify adding this with the existing quirks. 21:30:26 ack smfr 21:30:40 https://lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0267.html at least recorded an action to post a proposal for layout-affecting transforms 21:30:55 smfr: Safari's command-plus zooming behavior is built on top of the zoom property. Makes images and text bigger while reflowing. Transforms aren't what you want. 21:31:07 emilio: Control-plus in gecko affects the CSS px scale. and viewport. 21:31:38 myles: We also have that zoom 21:31:46 smfr: That's what we have, it changes the size of css px 21:32:14 emilio: command-plus is interoperable, it just changes the size of a CSS px. But it's complicated / messy, maybe it's a mix of the two. 21:32:52 astearns: dbaron posted a link where we wanted to make layout-affecting transforms before 21:33:02 astearns: proposed resolution: avoid specifying zoom as it stands, but we will if we have to, and a new proposal about a better zoom property would be a good use of time 21:33:10 dlibby: Good discussion. Thanks. 21:33:22 dlibby: This is a clear path forward that ideally does not specifying the current behavior. 21:33:48 Topic: Updating the css `env()` function to enable selection by index from a list of pre-defined environment variables 21:33:58 GitHub: https://github.com/w3c/csswg-drafts/issues/5622 21:35:36 dlibby: A continuation of the previous discussion. Targetting dual-screen devices. Creating primitives that are more extensible to target desktops or future devices. That could be better than the original proposal. Previously we described where a fold might exist in yoru viewport, but this changes to describe segments of your viewport and their dimensions. It's probably 2 issues: 1. Whether this set of env variables makes sense, and 2. the right way 21:35:36 to represent it syntactically. TabAtkins replies about 2. Focusing on the env variables themselves... these would be in visual viewport coordinate system. Targetting the top level layout constructs. 21:35:49 dlibby: We have not yet heard use cases for integrating into the various layout submodules. 21:36:03 q+ (after Tab gets an opportunity to reply) 21:36:09 zakim, open queue 21:36:09 ok, astearns, the speaker queue is open 21:36:12 q+ 21:36:22 q+ 21:36:51 dlibby: the ordering in the proposal for this issue is a row major order with a single index. Maybe there will be some discussion about whether that should be a 2-d index. -> Syntax question about whether env variables should be specified up front about the ones that are represented by the UA, or if an open-ended set of variables is sufficient for that spec. 21:37:03 dlibby: Our goal is to get something into the WD for css-env. But feedback on the concept / makes sense/ etc. would be appreciated. 21:37:04 ack TabAtkins 21:37:21 q+ 21:38:13 TabAtkins: On the syntax question, the original proposal has an index(var name, integer) and represents an indexed variable name there. We don't' need a function, if we want a list or matrix value env variables, we can build them into the name like name-1 or name-2 but if we want to make them separable, which is reasonable, we can't target a particular screen if it's built into the ident, we can add 1 or more integers into the main argumetn part of 21:38:13 the [missed] 21:38:17 +1 to Tab 21:38:27 TabAtkins: I'm happy to add in 1+ integers after the variable name, that makes sense. 21:38:28 s/[missed]/env() function/ 21:38:30 ack fremy 21:38:52 fremy: That mostly covers the thing I was going to say. 21:39:10 q+ 21:39:11 fremy: One little thing: when I looked at this, one of the things you can do if you have a way of separating the numbers and the value is you can have the number be a variable. You cannot have the name of a variable be a variable. There can be use cases for that. 21:39:19 fremy: Why limit ourselves to integers? 21:40:29 fremy: Right now, the syntax for variable is [ident comma fallback]. What if instead we allowed the ident to be a list of identifiers or numbers, and then concatenate them. Then we could use variables in the name of variables, which would be cool. You could have a structure, like main color, secondary color, and then prefix them with the name of a theme, like dark-maincolor or light-maincolor, and use a variable to select which theme you're using on 21:40:29 an element. 21:40:51 fremy: Like what TabAtkins said, we don't need a function, but we can put any arbitrary ident there. 21:41:01 myles: Floating point values makes that tricky 21:41:07 TabAtkins: it would be ident | int 21:41:10 ack heycam 21:41:37 heycam: In the proposal, there's talk of 2d screen setup. Will this work with non-mobile device situations? 2d arrangements of monitors is usually for desktop machine. 21:42:05 ack bkardell_ 21:42:11 21:42:34 ack fantasai 21:42:34 fantasai, you wanted to ask about viewport vs display 21:42:42 q+ bkardell_ 21:42:48 q- 21:42:59 fantasai: 2 questions: 1. Are we distinguishing between viewport and physical display, is env() returning the value for the viewport (if you move a window on the display) how does that effect the env() 21:43:23 fantasai: 2. Do we want to linearize the list? Or do we want to assume a gridded layout and have a matrix w/ 2 indices, one for each axis 21:43:51 astearns: If we decide to use a list syntax now, can we extend that to accommodate a matrix syntax? 21:44:52 fantasai: It depends on what exactly we decide to do. A linear form is ... the syntax would have different needs depending on what you wanted to do. It's interesting how exactly the syntax work and how it relates to the MQ and how it relates to each other and other things in CSS. It's important that we think of these two features together. The MQ + the env() 21:44:52 21:45:08 dlibby has joined #css 21:45:21 fantasai: 2 questions: 1. Are we distinguishing between viewport and physical display, is env() returning the value for the viewport (if you move a window on the display) how does that effect the env() 21:45:46 dlibby: We are querying the viewport in relation to the physical/logical display regions. 21:45:50 fantasai: That needs to be clear in the name. 21:45:56 fantasai: and in the spec also. 21:46:18 fantasai: With the MQ we were talking about going toward a matrix form, where you've got rows and columns. For the env(), would we want to do that here also? Or a linearized version here for some reason? Both? 21:47:00 This sounds like pagination but for different shaped pages that are displays 21:47:08 dlibby: Perhaps having both would be useful, but the hesitation with the matrix is just for the set of hardware we know about currently, that extra metal load of the matrix-like syntax seems a difficulty for authors to get over. If there's consensus that having that consistency with the MQ.... We're amenable to having it for the syntax as well. 21:47:31 Also curious if this is meant to model complex non-rectangular amalgams of displays like adjacent Times Square video screens 21:47:35 fantasai: It would be good if the MQ + the env() would have consistent syntax. If we need the linear version for some reason, then maybe we can look into that. But we should aim for consistency 21:47:39 dlibby: Okay, we can take a look. 21:47:47 heycam: In the proposal, there's talk of 2d screen setup. Will this work with non-mobile device situations? 2d arrangements of monitors is usually for desktop machine. 21:47:54 q? 21:48:02 q+ 21:48:57 dlibby: One thing we've been referring to is a semantic mode from the window manager. If there would be a desktop OS that supports an app window going into a configuration where it has a rectangular viewport that is spanning some number of screens, we would want it to apply. But if you're moving your window between displays and happen to let go of your mouse where a few pixels are bleeding into another monitor, that doesn't feel right for the 21:48:57 semantics of this. 21:49:05 window manager should be snapping that, probably 21:49:18 chris has joined #css 21:49:31 heycam: It seems like you would want to know the spatial arrangement of these displays. Even in a simple situation of two halves, if they are arranged vertically or horizontally, that would change how you woudl use the env() vars. Maybe we want the matrix syntax. 21:50:06 dlibby: Yes, it's important, and part of a separate issue related to the media issue that fantasai alluded to earlier. The proposal: Two media features, one in X direction and one in Y direction about how many you have in a certain axis. 21:50:19 dlibby: As newer form factors come into existence, they can fit into that 21:50:52 heycam: The author would have a MQ to select on arrangement, then within that, env() to index within that 21:50:52 dlibby: Yes. fantasai is right that we want consistency 21:50:54 ack smfr 21:51:41 smfr: I have a hard time evaluating these proposals b/c I don't understand the model w/r/t scrolling + zooming. When you scroll, do both screens move up and down at the same time? Is the right side showing the bottom of the left side down? Or can we do multicol thing where scrolling is 21:52:03 smfr: Or does the whole thing scroll as once? If you zoom, where is the origin? Is it all one big thing? I would like to see animated images how scrolling + zooming works. 21:53:14 dlibby: Okay. We can put that together. By default you have a single rectangular viewport / ICB which is the size of the rectangle, spanned across both screens. If you don't do anything special, the entire thing will scroll. The site could use the primitives that independently scroll themselves with overflow-scroll. We don't want these values to change on zoom. Similar principle on zoom - shouldn't change, like safe-area-inset. We don't want 21:53:14 relayouts on every zoom frame. To the exten that we can match that existing behavior we think that's a good model for these env() vars 21:53:50 smfr: I think it would be useful if your examples started with a simple case that didn't have a scrollable left column, and then add in teh scrollable left column wehre it makes sense to map things on to two screens. 21:53:58 smfr: Like a page with no columns. Wikipedia. 21:54:04 dlibby: At the bottom there's an example of an outlook application. 21:54:51 dlibby: Where it just flows across that seam or fold, across the 2 displays. It would scroll as if your viewport was just that size. This is about letting people customize that w/r/t the viewport. 21:54:51 smfr: I think that's fine. 21:55:28 astearns: I read through the proposals a few times. There's lots of layout described. Different kinds of layout across / separately. But to smfr's point, there isn't the extra stuff that he's asking for in terms of scrolling / zooming / other actions across both screens / independently. But it's a separate issue. smfr, can you raise a new issue about including more, specific examples? 21:55:30 smfr: Sure. 21:56:08 astearns: proposal: Develop a list and matrix version of variable references so that we can pull various pieces of an env() out, and resolve the syntax we choose for these variables should match the MQ for it 21:56:16 dlibby: That sounds like what i've been hearing? 21:56:33 RESOLVED: Develop a list and matrix version of variable references so that we can pull various pieces of an env() out, and the syntax we choose for these variables should match the MQ for it 21:57:16 Topic: [css-values-4] Ratio of `0/0`? 21:57:20 GitHub: https://github.com/w3c/csswg-drafts/issues/4954 21:58:16 TabAtkins: A bit ago there was a question of what an aspect ratio of 0/0 means. Auto? Invalid? Something else? I opened an issue, but then closed it because I thought there was an obvious answer. But fantasai re-opened it because it wasn't obvious. I'll give my explanation, but if there's no easy answer, we can keep the issue open. 21:59:13 TabAtkins: The behavior of 0/0 is [should be?] Identical to 1/0. They produce an element that produces an element that wants to be infinitely tall/wide, depending. We have text in the values spec about what to do when you say width: 154892798542. Should be clamped to largest value you support. Nothing wrong with infinite or 0 ratio. 21:59:31 TabAtkins: So 0/0 should preserve the concept of an earlier meeting: a/b should be the same as calc(a/b). 21:59:52 TabAtkins: If you do calc(0/0) you get NaN which turns into positive infinity, which is the same a 1/0. It's an easy answer. 22:00:09 TabAtkins: So calc(0/0) is already defined, so just writing 0/0 should act the same. 22:00:22 aspect-ratio: calc(0/0) i salready well-defined (and same as aspect-ratio: 1 / 0) 22:01:29 TabAtkins: OTOH, 0/0 is a clear error case, so we can make it fall back to the initial value. We can't reject it at syntax time because the 0s could be produced by calc. But we could fallback to auto. Not unreasonable. But because infinite ratios already have well-defined behavior, and the behavior of treating it like 1/0 falls out of the calc behavior already, it's easier to be consistent with that. 22:01:38 honestly, why not 22:02:09 technically 0/0 is an "indeterminate form" https://en.wikipedia.org/wiki/Indeterminate_form 22:02:15 leaverou: I don't have an objection, but it seems weird to treat 0/0 == 1/0. 0/0 is indefinite in maths. It seems more reasonable to treat as invalid than infinity. If we can't change calc(0/0), then internal consistency is more important. 22:02:34 TabAtkins: Yes, 0/0 is definitely indefinite, but we censure (sensure? sensor?) it to infinity 22:02:57 did we consider animation implications here and is this the desired result? are aspect-ratio denominators animatable? 22:03:08 censor, I think 22:03:31 TabAtkins: Right now it always the case that calc() always produces a valid value. As long as you don't typecheck at parsing time, you can't produce a non-numeric value. That seems like a reasonable constraint to hold on to. Because you can approach 0 from different directions, there are multiple answers, but saying it's the same as 1/0 gives you *one* of the answers. 22:03:47 florian: Calc(0/0) can't turn into a keyword because it can be used in different properties 22:04:26 TabAtkins: When animation, we animate the division result, so the animation is consistent depending on whether you use calc(a/b) or use a / b, so animation behavior will be the same. 22:04:52 leaverou: If you animate 0/0 -> 0 / positive, you'll get disconuity. 22:04:54 TabAtkins: Don't do that. 22:04:59 TabAtkins: All the answers are arbitrary. 22:05:03 TabAtkins: We just pick one. 22:05:15 is it animated linearly or as the logarithm? Using the logarithm seems like it would give more consistent behavior between dimensions... 22:05:16 heycam: Are there other properties other than aspect-ratio that takes a ratio? Aspect-ratio does discrete animation. 22:05:32 TabAtkins: I have an issue open about aspect-ratio animation. I propose that it works like division. 22:05:52 TabAtkins: The only other place where ratio type is used is the MQ about aspect ratio. 22:06:12 astearns: Do people feel the argument about keeping the current calc behavior and make aspect ratio match it, is that compelling enough? Or should we leave the issue open? 22:06:19 I buy into TabAtkins 's logic 22:06:28 fantasai: The people who raised concerns were AmeliaBR and cbiesinger 22:07:04 I'm ok with TabAtkins logic though I'm going to s/indefinite/indeterminate per Wikipedia citation. 22:07:09 oriol: One argument about this, maybe we could say that saying the initial value is not possible, but we could resolve it to NaN and keep NaN into the outer calc, then bubble it up, and say if the number resolves to NaN it behaves as the initial value. 22:07:25 TabAtkins: If a top-level calculation ends up being NaN, the property would be invalid at computed value time. It's possible. 22:07:28 oriol: mhm. 22:07:38 q+ 22:07:49 TabAtkins: I would prefer that aspect-ratio be consistent in both of its forms, but I don't have a strong opinion about which option we pick. 22:08:25 florian: For properties that take a single number or a single length, then sure. But if you're using calc() as one of many numbers in a property that takes many, like calc() in a shadow-spread, then maybe it's okay that you don't want to invalid the color just because the spread ended up being NaN. 22:08:52 cbiesinger: fantasai was poking me. I don't have an opinion. My suggestion is to treat 0/0 as the initial value. But I don't really have an opinion on how this should work with calc. But I don't really have an opinion 22:09:17 astearns: I'm inclined to resolve that we treat an aspect ratio of 0/0 as current calc(0/0). AmeliaBR isn't here, but we can always re-open the issue if she feels strongly about the resolution. 22:09:24 cbiesinger: calc(0/0) is a parse error in Chrome right now. 22:09:34 TabAtkins: We don't support dividing by zero yet (!!!) 22:09:54 RESOLVED: Define aspect-ratio: 0/0 to be equal to aspect-ratio: calc(0/0) 22:10:26 topic: break 22:10:29 anyway, since it was a side comment, I mentioned my interpolation point at https://github.com/w3c/csswg-drafts/issues/4953#issuecomment-712469770 22:11:29 is 'aspect-ratio' not a ? 22:11:42 dbaron: it's auto || 22:11:51 Ah, dbaron, thanks for the comment there. 22:11:58 https://drafts.csswg.org/css-sizing-4/#aspect-ratio 22:12:01 dbaron: ^ 22:12:40 It would be nice if that were in the first 2 pages of results of https://www.google.com/search?q=site%3Acsswg.org+aspect-ratio 22:13:18 yeah... anyone have contacts at a search engine? 22:13:36 dbaron: Remember that https://drafts.csswg.org/indexes/ can locate any CSS property for you. 22:14:15 TabAtkins (IRC): that points to mediaqueries 22:14:27 ahaha nice 22:15:15 Oh maybe Sizing 4 isn't in the list of specs to look at yet! 22:15:32 ('grid', for example, clearly handles both property and descriptor forms) 22:16:37 present+ James_Craig 22:17:23 Ah yeah, Sizing 4 is currently marked as an ignorable spec in Bikeshed's defaults. fantasai, sound good to remove that? 22:17:50 It'll mean links start going to 4 rather than 3 in other specs 22:18:00 Links should go to 3, not 4 22:18:11 But if something's only in 4, then link to 4... 22:18:19 idk if you can do that, but that's kinda where we're at 22:18:44 Sizing 4 is an unstable diff spec, not really a good reference 22:19:46 Yeah, if you *specify* that you want to link to Sizing 4 explicitly, you can still link into it, but otherwise it'll never resolve as a valid link destination 22:20:58 ScribeNick: TabAtkins 22:21:14 Topic: MQ serialization 22:21:31 github: https://github.com/w3c/csswg-drafts/issues/5627 22:21:57 astearns: Proposed resolution is to drop the CSSOM-specified sorting of MQs in lexicogrpahic order when serializing 22:22:27 TabAtkins: No objection, but one example shows removing duplicates as well 22:22:36 TabAtkins: Should also make sure that is covered as well 22:22:36 astearns: Consensus in the issue, looks like 22:22:59 emilio: Don't think Gecko has ever sorted, and we don't seem to have an issue 22:23:08 astearns: Did you dedup? 22:23:22 emilio: Don't think so; maybe as part of MQList apis, but not serialization. will doule-check 22:23:28 astearns: So any objections? 22:23:40 RESOLVED: Do not sort or dedup MQs when serializing 22:23:48 Topic: forced-colors and prefers-contrast 22:24:03 github: https://github.com/w3c/csswg-drafts/issues/5433 22:24:27 Morgan: We've been implementing prefers-contrast and forced-colors in Moz for a while 22:24:33 Morgan: Hoping to unpref adn ship soon 22:24:40 Morgan: Hesitant until this issue is resolved 22:24:53 Morgan: Don't have an opinion on the stances taken here 22:25:02 florian: Attempted summary of where we are 22:25:08 florian: We have two related things here 22:25:23 florian: prefers-contrast MQ, which is about letting the author know whether the user prefers higher or lower contrast on the page 22:25:34 florian: So author can change colors, add/remove borders, etc 22:25:59 florian: And notably, authors can use it without a specific value; (prefers-contrast) just indicates that they have *some* preference, but not whether it's high or low 22:26:10 florian: But general rule is that, regardless, removing visual clutter is often a good thing 22:26:22 florian: A related thing was added to css, forced-colors mode 22:26:32 florian: Not a user pref, it changes colors for the author automatically 22:26:48 florian: When responding to forced-colors, it can be useful for an author to do the same contrast adjustments, reducing clutter and such 22:27:00 florian: So we ahve a (prefers-contrast: forced-colors) value to indicate this 22:27:18 florian: So my feeling is that they're theoretically distinct, but in practice they're close together and can be addressed in similar ways 22:27:27 q- 22:28:00 Worth noting also that "forced colors" is called "high-contrast mode" in Windows, which developed it. It's clearly intended to handle a contrast preference. 22:28:02 florian: So right now we ahve both the (forced-colors) MQ as well, for legacy reasons 22:28:25 florian: We probably can't remove (forced-colors), for legacy compat reasons. We probably *could* remove the (prefer-contrast: forced), but I think it would be more useful to keep 22:28:50 jcraig: We also have prefers-reduced-transparency; I mention because we use it more to indicate reducing clutter 22:29:11 jcraig: Sometimes lower-vision users who would prefer contrast would also prefer less things floating with transparent bgs, so they'll often be set up together 22:29:50 jcraig: One unmentioned theoretical purity arg is that having forced-colors in here is the only instance so far with a prefers-* MQ having a value that does *not* correspond to a user preference 22:29:59 jcraig: Also reached out to aboxhall 22:30:02 jcraig: She shared this: 22:30:10 Alice: I am pretty convinced that the MS version (forced-colors: active) is better, but I don’t think I would have any critical arguments to add given there will presumably be MS folks there to articulate the reasoning (i.e. that forced-colours doesn’t necessarily have anything to do with contrast, since the color choices are arbitrary) 22:30:42 jcraig: So she doesn't have a strong opinion, but tends to agree that (forced-colors) is better 22:31:03 jcraig: Other thing I shoudl probably mention is that Apple doesn't ahve a forced-colors setting, so it's not particularly troublesome from Apple's perspective. 22:31:08 q+ 22:31:13 jcraig: But I have opposite opinion from Florian for the author experience 22:31:33 jcraig: I think the convenience of being able to just write (prefers-contrast) doesn't outweight the clarity gained from writing (forced-colors) 22:31:33 ack fantasai 22:31:54 fantasai: It's worth noting that the forced-colors feature was developed as Windows High Contrast mode, so it was *intended* as forcing a particular contrast. 22:32:04 fantasai: Doesn't necessarily force a high contrast, but it does force a *fixed* contrast 22:32:17 fantasai: So not unreasonable for it to fall under the (prefers-contrast) MQ 22:32:27 fantasai: I have a side question on (prefers-reduced-transparency) 22:32:48 fantasai: If you have an opaque BG with a pattern on it, is that something that should be turned off if this pref is on? 22:33:07 fantasai: bc if it's actually about visual clutter, that's not stated by the name 22:33:19 q? 22:33:22 fantasai: Also, prefers-contrast *will* be true in the majority of cases where Windows High Contrast will be on 22:33:51 q+ to respond to Elika's q re background pattern versus transparency 22:33:54 fantasai: Because those forced colors will generally cause it to resolve to high or low (from the specification fo the forced-colors feature). ONly an indeterminate color scheme will not trigger it. 22:34:27 fantasai: So it's concerning a bit if authors are testing with High Contrast mode, and triggering (prefers-contrast), but then a user comes along with an indeterminate scheme, they might not get caught 22:35:06 fantasai: And in general, both (prefers-contrast) and (prefers-color-scheme) do reflect the choices made by Forced Colors mode 22:35:16 Morgan: Turns out I have an opinion 22:35:23 ack Morgan 22:35:28 Morgan: I added some info to the issue just a bit ago 22:35:37 Morgan: Firefox has a high-contrast mode built in, that's not OS-specific 22:35:51 Morgan: It triggers True when Windows High Contrast, or the browser-local HCM, is on 22:36:00 Morgan: So far we've found people using it for both high and low contrast reasons 22:36:06 Morgan: But also for things like photosensitivity 22:36:15 What does Firefox HCM "regardless of browser" mean? 22:36:16 Morgan: Those don't necessarily fall into high or low contrast bins 22:36:32 jcraig, suspect she meant "regardless of OS" 22:36:39 Morgan: So I agree with fantasai's concerns that they might not have their prefs reflected by authors 22:36:55 Morgan: Also, we find that devs often dont' have the ability to test with high contrast themes. 22:37:07 ack jcraig 22:37:07 jcraig, you wanted to respond to Elika's q re background pattern versus transparency 22:37:11 Morgan: So if our local HCM doesn't trigger this query, they dont' have a way to test 22:38:23 q+ 22:38:57 jcraig: So (forced-colors) just means colors were forced, not anything about the contrast. So I still think (prefers-contrast) isn't right to trigger it automatically 22:39:01 jcraig, sorry yeah regardless of OS :) 22:39:23 jcraig: wrt transparency and backgroudn color, on Apple OSes we hav separate settings for these bc the user may want or not want each of them 22:39:35 jcraig: There's often overlap, but the clarity from breaking them into separate settings is worth preserving, I think 22:40:13 jcraig: With the patterned background - in iOS we have a lot of transparency, but not a lot of loud backgrounds 22:40:44 jcraig: So if we wanted to do something more general about legibility, we could do something for that, but trying to tie "increase legibility" to a contrast setting seems weird, it should just be about contrast 22:40:46 present+ 22:40:53 ack fantasai 22:40:53 fantasai, you wanted to re-explain her point 22:41:11 fantasai: So james had one point about "this is not a preference, so why is it in a MQ about preference) 22:41:34 fantasai: So it's *already* going to trigger that *in most cases* - Forced Colors mode will *usually* trigger (prefers-contrast) and (prefers-color-scheme) 22:41:49 fantasai: And an author will thus usually see those turned on when they test in forced colors mode 22:42:47 fantasai: Also, for testing now - if authors write (prefers-contrast) in their stylesheet, and it *usually* triggers in forced colors (not all users, but most, including themselves), it's likely they'll write code depending on that, which then doesn't trigger for users in the in-between state that coudl still usefully use the adjustments 22:42:56 fantasai: So it's easy to leave out a class of users by accident 22:43:00 q+ 22:43:19 I don't agree that "most prefers-contrast users" will have forced colors on... iOS "increase contrast" doesn't force colors. 22:43:22 fantasai: So I think that's another reason why having forced colors *explicitly* fall under prefers-contrast helps out 22:43:51 jcraig: I think elika said taht most prefers-contrast people will ahve forced colors... 22:43:58 q+ 22:44:20 florian: No, other way around. If they have forced colors, and they are high-contrast, then you'll trigger (prefers-contrast: high). And same for (prefers-color-scheme) if they're light or dark, etc 22:44:48 florian: So *most* of the time forced colors will cause these other MQs to trigger, but if you have a middling color scheme, you'll be in a rare bucket that won't trigger the boolean form at all 22:45:07 florian: So adding the 'forced' keyword in makes sure they trigger at all times 22:45:28 jcraig: So as an author, I'm not sure whether to check for (prefers-high-contrast: high) or (prefers-high-contrast: forced) 22:45:46 jcraig: And then it's just weird still to have another setting to the exact same thing 22:45:50 q? 22:45:55 ack florian 22:46:07 florian: Both in terms of transparency and patterns and this argument, I think there's a general tension between a11y features here 22:46:20 florian: On the user side, general desire to express complex needs, because users have many needs and preferences 22:46:28 s/(prefers-high-contrast: high) or (prefers-high-contrast: forced)/(prefers-contrast: more) or (prefers-contrast: forced)/ 22:46:52 florian: But if we expose too many fine-grained prefs, it's likely authors won't respond to everything. The more we group them, the more likely the response isn't *perfectly* targeted at their need, but more likely they'll get a *reasonable* response. 22:47:09 florian: So trade-off of perfect responses (that ar eless likely) vs okay responses (that are more common) 22:47:23 florian: I think the current design is about right for this reason, but we can disagree on the limit 22:47:35 ack TabAtkins 22:47:38 ack Morgan 22:47:40 TabAtkins: Florian made the exact point I was going to 22:47:51 Morgan: Last time this discussed, no definition of "more" or "less" ratios 22:48:01 more than default, less than default 22:48:04 Morgan: Saw this as a sliding scale of more and less as higher and lower ratios defined by user agent 22:48:08 s/ar eless/are less/ 22:48:26 Morgan: So if you see this as a continuum, makes sense to me that the middle values also trigger the MQ, rather than there being a threshold that turns it on only for more extreme values 22:48:41 jcraig: Responding to florian's, I agree we ahve a decision to make about granularity 22:49:00 jcraig: My opinion is that it should be towards granular side. 22:49:02 q+ 22:49:35 florian: The people who ask for it know what they want, but if too granular, they just wont' get what they want often 22:49:58 jcraig: How i understand windows hcm right now, it'll match both 'forced' and either 'more' or 'less' if appropriate 22:50:12 jcraig: I think it's quite reasoanble to match 'more' if HCM is on 22:50:25 jcraig: is on with a high-contrast scheme 22:50:43 jcraig: And if we want to have a separate granular reference to forced colors in general, still don't understand why it needs to be the same 22:51:07 jcraig: You're talking about a boolean match for contrast that is high, or low, or in the middle. 22:51:09 CSSWG_LogBot has joined #css 22:51:13 q+ 22:51:16 ack TabAtkins 22:51:23 TabAtkins: wrt granularity choice, directly related to what you were saying 22:51:30 TabAtkins: our current proposal has that granularity 22:51:44 TabAtkins: You can target high contrast, low contrast, and forced contrast specifically and independently 22:52:01 TabAtkins: But something you are likely to want to do for all of them is to simplify the page 22:52:19 TabAtkins: If this is indeed the case, then we should have something that catches everything simply 22:52:32 TabAtkins: And certainly should be something that catches the more common and less common cases the same way 22:52:50 TabAtkins: I would rather authors have an general switch, rather than needing to list each thing independently 22:53:02 TabAtkins: If your argument is that there is no reasonable thing to do that applies to all these contrast modes 22:53:05 TabAtkins: then we don't need it 22:53:08 Loss audio in the middle of Tab's comment 22:53:15 TabAtkins: but if there is, then we need a good syntax for doing so 22:54:39 jcraig: if ... about syntax, then happy to take it to a vote 22:54:59 jcraig: I don't think authors are going to see (prefers-contrast) or even (prefers-contrast: forced) and jump to conclusion of needing to reduce decoration on the page 22:55:09 astearns: Any input from ppl not yet part of the conversation? 22:55:21 ack emilio 22:55:26 Going for a more general "prefers-simple" MQ doesn't sound unreasonable... 22:55:34 emilio: Conversation was we cannot remove 'forced-colors: active' 22:55:36 emilio: Convo started with "we can't remove (forced-colors) 22:55:47 emilio: I don't see 'prefers-contrast: forced' adding a lot of value 22:55:49 emilio: I dont' see (prefers-contrast: forced) having a lot of value here 22:56:04 emilio: prefers-contrast and forced-colors are technically unrealted and they should be separate MQs 22:56:37 florian: On the one hand, I don't think this is a breaking point; I'd be willing to yield if necessary. 22:57:01 florian: But I feel like fantasai and TAb and I are making an argument for it being useful, but y'all keep saying "i dont' see why it's useful" - we just *said* why it was useful 22:57:15 florian: I don't think we're wrong that the syntax is convenient, but are we wrong about the use-case? 22:57:31 astearns: Is the user-case enabled by (forced-colors)? 22:57:44 florian: No, it's not about responding to forced colors specifically. 22:58:08 q+ 22:58:15 florian: In the case of an author that has a low and high contrast mode, it seems reasonably likely they'd have some bit of the code specific to those modes, and a shared chunk applied to both high and low modes that, for example, disables backgrounds. 22:58:34 florian: The way they'd write that code is with the common code in (prefers-contrast), then specific ones in (prefers-contrast: more)/etc 22:59:05 (prefers-contrast) versus (prefers-contrast or forced-colors) 22:59:18 florian: Assuming they do that sort of code organization, should we allow that to still work when the user has HCM set to a middlign contrast, or should we say that authors should know to pay attention to the (forced-colors) MQ as well specifically to handle these cases? 23:00:03 fantasai: And more complexity here - the people using HCM will get those shared styles *if* their chosen colors are high-contrast or low-contrast. And users in the middle have the same *needs* as high and low, but without 'forced' they wont' get it 23:00:51 zcorpan has joined #css 23:00:53 fantasai: And from a dev POV, devs will very likely test HCM with a high-contrast theme, and they'll assume their page is working in a particular way when forced-colors is on and in a high-contrast mode. But users not matching that case won't get hit. 23:01:00 FWIW I agree with @fantasai's latest comment; authors will not expect the block to turn off 23:01:06 q+ 23:01:07 fantasai: So having pages fall into codepaths that aren't tested is a great way to have a broken page 23:01:12 ack jcraig 23:01:20 jcraig: I see the point, and the mild syntax convenience 23:01:21 zakim, close queue 23:01:21 ok, astearns, the speaker queue is closed 23:01:35 jcraig: Potentially could match something that might provide a convenience in the interface to an author that wants to reduce complexity. 23:01:43 jcraig: If we assume that authors will know that and respond to it. 23:01:51 jcraig: But I think the risk is that authors will conflate different things 23:02:04 jcraig: Recent years, authors conflate small viewport widths to mean it's on mobile 23:02:16 jcraig: Or check the user agent and see iOS and assume it's a phone and not an iPad 23:02:32 jcraig: Apple had to do a lot of work to make sure iPads get desktop sites, for example 23:02:46 The reason authors are conflating those things is because they had no other way to detect the things they were interested in 23:02:55 jcraig: So even tho these are somewhat conflated, risk of conflating them 23:02:59 e.g. knowing you're on a touchpad is important consideration in design, but there was no ability to query that directly 23:03:10 so authors made a lot of assumptions 23:03:23 emilio: I get fantasai's point, but we can solve it without ahving to expose the 'forced' value 23:03:25 We don't have that problem here because we already have the individual options available to query 23:03:33 s/somewhat conflated/somewhat related/ 23:03:35 emilio: You can just say if you're forcing colors you *must* match high or low 23:03:46 emilio: When forcing colors you most can't override system colors 23:04:01 emilio: I think having two MQs mean the same thing isn't amazing either 23:05:07 topic: end 23:06:14 fantasai: so florian started with the premise that we couldn't do that. If we can, I don't particularly object. Though I think `@media (forced-colors) or (prefers-contrast)` is not significantly worse than what you're proposing, and it's way more clear on when it can match 23:06:54 emilio, yeah, it's possible 23:07:04 problem is that (prefers-colors) will match almost all but not all users of forced-colors 23:07:07 fantasai: having media queries that have different keywords like `(prefers-contrast)` is a bit confusing I suspect, and I'd avoid it, though... 23:07:23 Notes for posterity (I think it's clear to attendees) that fantasia's comment "deprecate the old one and move to the new one" is the opposite of what Emilio suggested: "deprecate the new one since we have to keep the old one for interop and the new one does not provide enough additional benefit" 23:07:32 Right 23:07:42 s/fantasia/fantasai/ 23:09:46 zakim, end meeting 23:09:46 As of this point the attendees have been emilio, alisonmaher, Rossen_, miriam, fremy, rego, plh, astearns, oriol, lajava, heycam, dlibby, faceless, cbiesinger, TabAtkins, TYLin, 23:09:49 ... Morgan, fantasai, tantek, myles, Guest, GameMaker, jensimmons, bkardell_, brandonferrua, hober, chris, drousso, leaverou, dbaron, (intermittently), James_Craig, plinss 23:09:49 RRSAgent, please draft minutes 23:09:49 I have made the request to generate https://www.w3.org/2020/10/19-css-minutes.html Zakim 23:09:51 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 23:09:52 fantasai: if we take the path that I was suggesting (just keep `forced-colors`, don't ship `prefers-contrast: force`), and we realize that pages are just using `(prefers-contrast)` and hurting `(forced-colors)` users with non-high/low-contrast colors, the UA could pretty easily choose one of the `high` / `low` variants I suspect... 23:09:55 Zakim has left #css 23:10:07 fantasai: all this discussion reminds me of the `(prefers-color-scheme)` discussion fwiw 23:10:15 emilio, I don't think you want to trigger high/low in middling cases 23:11:06 fantasai: but if you're forcing colors you can't use non-system colors anyways (well I guess if you use force-color-adjust), so I don't think it'd be a meaningful difference in most cases... 23:11:11 fantasai: but anyhow fair 23:11:25 that's not true, emilio 23:11:29 images aren't affeted 23:11:31 affected 23:11:49 you can use any colors you want in an image 23:11:55 fantasai: true, that 23:12:01 or in a `forced-color-adjust: none` subtree 23:13:42 fantasai: I guess you could always match the boolean query even though you don't match `high` nor `low` nor `no-preferecence`... But I still think that contrast preference and forced colors are two different things 23:13:53 That would be really confusing :) 23:13:58 fantasai: right 23:14:00 It has to match one of the keywords to match the boolean 23:14:16 forced colors was invented for people who wanted a particular contast preference 23:14:28 yeah, the current model requires *some* value to match, and I don't think it's worthwhile to break that 23:15:17 I mean, my preference is to not have forced and not match the boolean in middling color schemes, just keeping them separated 23:15:24 we could have named the middle value "middle", but "forced" more accuratelly communicates "you have no idea what they're wanting, please use the system colors rather than your own colors" 23:15:58 I guess lacking that fantasai / florian's alternative is the best. I'm not convinced that `forced` provides a lot of value 23:16:41 I guess in the end depends on how authors end up using it. Ideally people would advocate just `@media (forced-colors) or (prefers-contrast)`, then specific high/low settings 23:17:30 But I guess for that WebKit / Blink would need to implement `or` in media queries ;) 23:17:55 oooh, snap 23:49:20 dbaron has joined #css 23:49:39 plinss has joined #css