00:00:09 <TabAtkins> ChrisL: what we want is a term for "entire rendered content of the element"
00:00:26 <TabAtkins> florian: Might be a term for that already, just don't know it
00:00:30 <TabAtkins> q+
00:00:30 <astearns> ack emilio
00:00:47 <TabAtkins> emilio: I don't think... overflow-clip-margin doesn't apply to scrollable boxes generally
00:00:55 <TabAtkins> emilio: but the rest i think is correct, and we should agree on this behavior
00:01:04 <astearns> ack TabAtkins
00:01:27 <emilio> TabAtkins: I think all that's necessary is defining when scrollbars are painted in the CSS stacking model
00:01:42 <emilio> florian: so we'd monkey-patch that algorithm from the scrollbars spec?
00:01:55 <emilio> TabAtkins: no, that's on another spec but yeah
00:02:01 <emilio> q+
00:02:08 <astearns> ack emilio
00:02:14 <TabAtkins> emilio: I agree, but the specifics of where they're painted is maybe a bit weird...
00:02:18 <TabAtkins> emilio: need to dig into it
00:02:54 <TabAtkins> emilio: might be some cases where we'd intentionall put scrollbars over content they aren't usually over
00:02:54 <TabAtkins> emilio: will need to check
00:02:54 <TabAtkins> emilio: but i agree we need to define the right stacking order of scrollbars
00:03:02 <TabAtkins> astearns: so florian, you ahve a way forward
00:03:18 <TabAtkins> florian: yes, details TBD, but can agree that behind a transparent scrollbar you'll see the entire underlying content
00:03:30 <TabAtkins> florian: not just showing you one specific layer of the element
00:04:05 <emilio> q+
00:04:13 <astearns> ack emilio
00:04:14 <TabAtkins> astearns: proposed: specify that transparent scrollbars show thru whatever's underneath them
00:04:36 <TabAtkins> emilio: checking, i think gecko puts classic and overlay scrollbars at a different stacking position
00:04:45 <TabAtkins> emilio: wrt element contents at least
00:04:57 <TabAtkins> astearns: so back to issue now
00:05:04 <TabAtkins> github-bot, end topic
00:05:04 <emilio> https://searchfox.org/mozilla-central/rev/0b189f017bc9d48b62012205c5b9f8a8b560497b/layout/generic/ScrollContainerFrame.cpp#3854,3873
00:20:12 <jensimmons> jensimmons has joined #css
01:00:53 <ydaniv> ydaniv has joined #css
01:37:51 <ydaniv> ydaniv has joined #css
02:21:41 <jensimmons> jensimmons has joined #css
03:00:59 <jensimmons> jensimmons has joined #css
03:07:47 <ydaniv> ydaniv has joined #css
03:31:07 <Linux_Kerio> Linux_Kerio has joined #css
03:58:20 <jensimmons> jensimmons has joined #css
04:21:53 <jensimmons> jensimmons has joined #css
08:06:01 <jfkthame_> jfkthame_ has joined #css
09:01:47 <jfkthame_> jfkthame_ has joined #css
13:25:54 <Zakim> Zakim has left #css
14:23:27 <zrhoffman> zrhoffman has joined #css
14:32:23 <projecto-> projecto- has joined #css
14:32:54 <leaverou_> leaverou_ has joined #css
14:33:54 <Rossen-> Rossen- has joined #css
14:34:01 <zrhoffman> zrhoffman has joined #css
14:34:25 <shans_> shans_ has joined #css
14:34:55 <sylvaing_> sylvaing_ has joined #css
14:53:03 <zrhoffman> zrhoffman has joined #css
15:48:45 <TabAtkins> I'll be a few minutes late
15:51:58 <astearns> The WebEx link from yesterday has expired. New link incoming
15:55:46 <nigel> nigel has joined #css
15:57:01 <astearns> csswg members should have a message from our group list. You can also DM me for the link if needed
15:58:45 <Zakim> Zakim has joined #css
15:58:51 <astearns> zakim, start meeting
15:58:51 <Zakim> RRSAgent, make logs Public
15:58:53 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:59:18 <kizu> kizu has joined #css
16:00:11 <kbabbitt> kbabbitt has joined #css
16:02:49 <miriam> present+
16:03:29 <kbabbitt> present+
16:04:27 <fantasai> present+
16:05:06 <jfkthame> jfkthame has joined #css
16:06:03 <jfkthame> is there fresh dial-in info for today? the webex link from yesterday says it is cancelled/ended
16:06:20 <r12a> r12a has joined #css
16:06:21 <astearns> jfkthame: sent you a PM
16:06:35 <astearns> Yes, there is a new link for today
16:07:06 <schenney> schenney has joined #css
16:07:11 <schenney> present+
16:07:14 <dbaron> where should I find the new link?
16:07:22 <dbaron> oh, the i18n thread
16:07:22 <oriol> oriol has joined #css
16:07:29 <oriol> present+
16:07:44 <jfkthame> present+
16:08:13 <r12a> present+
16:08:35 <dbaron> Present+
16:08:51 <smfr> smfr has joined #css
16:08:55 <alisonmaher> alisonmaher has joined #css
16:09:16 <kizu> present+
16:09:33 <romain> romain has joined #css
16:09:40 <ydaniv> ydaniv has joined #css
16:09:41 <alisonmaher> present+
16:09:45 <romain> present+
16:09:54 <ydaniv> present+
16:10:19 <emeyer> emeyer has joined #css
16:12:01 <weinig> present+
16:12:23 <rachelandrew> present+
16:12:36 <emeyer> present+
16:12:37 <bramus> present+
16:13:09 <github-bot> Topic: [css-fonts-5][css-inline-3] Text Edge Metrics Registry
16:13:50 <stepheckles> stepheckles has joined #css
16:14:06 <vitorroriz> vitorroriz has joined #css
16:14:11 <castastrophe> castastrophe has joined #css
16:14:29 <emilio> fantasai: we've created a new feature, text-box-trim, that relies on knowing the strong top/bottom edges of the font
16:14:34 <bramus> ScribeNick: emilio
16:14:46 <emilio> ... we only have metrics for some writing systems
16:15:01 <emilio> ... e.g open type gives you cap height, but the top might or might not be it
16:15:11 <emilio> ... we've requested this 8 years ago
16:15:39 <emilio> ... and they still have not done anything about it, but maybe they don't know what it might look like
16:15:51 <emilio> ... so in order to get things moving somebody needs to collect this info
16:15:58 <emilio> ... so I propose it to be a joint effort
16:16:07 <emilio> ... w3c has the concept of registry
16:16:22 <emilio> ... we can create one where each metric is a writing system
16:16:40 <emilio> ... where we can have what the top / bottom are
16:16:52 <emilio> ... and if they don't correspond with latin then we need more metrics
16:16:56 <emilio> ... also examples and pictures
16:17:08 <emilio> ... and optionally how to derive that metric if you don't have it
16:17:11 <emilio> ... that's basically the idea
16:17:25 <emilio> astearns: if we could collect this info, what would we use it for?
16:17:35 <emilio> fantasai: one, tell opentype so that they can add metrics
16:17:48 <emilio> ... also we need to add keywords in text-box-trim to reference those edges
16:18:04 <florian> q+
16:18:06 <r12a> q+
16:18:25 <emilio> astearns: but if OT hasn't provided a metric in the format and fonts for that writing system aren't consistent there's nothing we can do with that keyword
16:18:31 <astearns> ack florian
16:18:37 <emilio> fantasai: well we could derive it from heuristics / existing metrics
16:18:53 <emilio> florian: agree it'd be useful, and someone needs to do this
16:19:15 <lea> lea has joined #css
16:19:21 <emilio> ... the keywords won't be super useful until fonts get there but they're also not useless
16:19:42 <emilio> ... in terms of who gives us info for the registry, there's 2 groups
16:19:50 <emilio> ... people givin examples
16:20:05 <emilio> ... on this language the top matches x other language or what not
16:20:11 <emilio> ... that could be anyone
16:20:17 <emilio> ... but then there needs to be a second group
16:20:24 <emilio> ... that reviews the former
16:20:37 <emilio> ... and as soon as their line is different from other line and we just collect
16:20:42 <emilio> ... that might give us too many lines
16:20:50 <emilio> ... and some of them might be the same
16:21:06 <emilio> ... so there's an interest on getting as many people as possible to contribute to adding data
16:21:08 <astearns> ack r12a
16:21:13 <emilio> ... but then we need another group to triage
16:21:31 <emilio> r12a: if we had these labels, how is it useful if OT has them?e
16:21:35 <emilio> s/e//
16:21:44 <emilio> ... we have hanging/roman/alphabetic baseline
16:22:12 <florian> q+
16:22:16 <emilio> ... I had the impression that you'd have those baselines defined but also you have the height right? But not sure how that would look on languages that have both upper and lowercase
16:22:20 <emilio> ... is it script-specific?
16:22:25 <ntim> present+
16:22:28 <emilio> ... e.g. x-height is not the same in many script
16:22:36 <emilio> ... those are questions I have about what this is for
16:22:38 <astearns> ack florian
16:22:41 <emilio> florian: 2 examples
16:22:56 <emilio> ... initial-letter, you align the top of the enlarged letter with the top of the regular text
16:23:13 <emilio> ... what is it? cap height? x height? hebrew top? thai top?
16:23:28 <emilio> ... if the language has a top that doesn't match cap / x height we need to know
16:23:44 <emilio> ... same if you're vertical-aligning to any line that isn't latin / cjk
16:24:02 <emilio> ... same for text trimming, and you're dealing with a metric that isn't cap / x height
16:24:06 <emilio> ... e.g. hebrew
16:24:12 <r12a> qq+
16:24:15 <emilio> ... so we need either opentype to tell us where that line is
16:24:21 <emilio> ... or have a way of compute it
16:24:31 <emilio> fantasai: or adding a font descriptor that tells you
16:24:31 <astearns> ack r12a
16:24:31 <Zakim> r12a, you wanted to react to florian
16:24:39 <emilio> ... I know where the line is even though
16:25:08 <emilio> r12a: so absolute or average line? In my ??? notes I have some diagrams and it really varies by font
16:25:22 <emilio> ... so question is would we be wanting per font metrics rather than per-script metrics?
16:25:33 <emilio> ... there's wide differences even within the same script
16:25:46 <emilio> ... the extent to which ascenders go up and down
16:26:24 <emilio> fantasai: which is why we want the font or font descriptor to provide it, but the line has a name which in latin might be the cap height, but in hebrew might be the aleph line...
16:26:32 <astearns> q+
16:26:44 <emilio> ... if we didn't have a cap height on designers would need to tweak the alignment to match it
16:26:54 <emilio> ... and same in hebrew or thai
16:26:56 <noamr> noamr has joined #css
16:27:05 <emilio> ... we need to know the name of the line and whether it matches an existing metric
16:27:11 <emilio> florian: so the position of the line is per font
16:27:19 <emilio> ... but the existence of the line is per script
16:27:42 <emilio> astearns: the writing system might have a traditional design line but how different fonts deal with that might or might not match with that line
16:27:45 <r12a> q+
16:27:53 <florian> q+
16:28:04 <emilio> ... so in order for this to be effective we'd need a way of matching the design line with particular font metrics from the font descriptor or so
16:28:11 <emilio> ... so that in one font they get the right line
16:28:13 <ChrisL> present+
16:28:21 <astearns> ack astearns
16:28:27 <emilio> ... which wouldn't be in regular CSS but on the font-face descriptor
16:28:47 <ChrisL> q+
16:28:49 <emilio> florian: yeah but in order to allow a descriptor to tell us where the line is we need to agree on the existance and name of the line
16:29:00 <emilio> ... in english we have x/cap height
16:29:03 <ChrisL> rrsagent, here
16:29:03 <RRSAgent> See https://www.w3.org/2025/01/30-css-irc#T16-29-03
16:29:15 <emilio> ... a design for a particular font the os might be higher and not really respect those lines
16:29:26 <emilio> ... yet in latin scripts there's an x and cap height and they're typically relevant
16:29:31 <florian> q-
16:29:31 <emilio> ... and in some scripts those are not defined
16:29:33 <astearns> ack r12a
16:30:15 <emilio> r12a: I'm starting to think that what we're hoping to do here is to define generic lines for fonts or possibly define generic lines per script and once we have defined what lines are appropriate we can start using those
16:30:33 <emilio> ... it might be better to start with "what are the functions for which we want to use these"
16:30:37 <ChrisL> q-
16:30:43 <emilio> ... e.g. what is the line to use to align first-letter?
16:30:58 <emilio> ... what is the the line to align with a particular point of the page
16:31:20 <emilio> ... rather than trying to create some generic repository of lines, start from the use
16:31:21 <lea> present+
16:31:36 <emilio> fantasai: that's why I think we need to look at the line for alignments
16:31:42 <emilio> r12a: didn't see that reflected on the discussion
16:32:24 <emilio> astearns: we have things people would want to use lines for today, but for some scripts we don't yet have the places where they'd like to use their own layout-affecting lines
16:32:27 <ChrisL> q+
16:32:38 <emilio> ... so I think in creating this registry we will find things that need to be added
16:32:48 <emilio> ... to create layout in less popular writing-systems
16:33:08 <emilio> fantasai: if we focus on the thing that everybody needs to do (align things to other things and spacing) I think we'd get most of the answers we need
16:33:13 <astearns> ack ChrisL
16:33:33 <emilio> ChrisL: Is this registry a temporary thing while we propose it to ?? or are we going on our own direction
16:33:44 <emilio> astearns: this was discussed, we want to nag opentype to do this thing
16:33:58 <emilio> fantasai: and we're not defining a technical feature, just collect this information
16:34:09 <emilio> ... which would provide info on what keywords we add and metrics we need
16:34:32 <emilio> ChrisL: once we have it would be good to give a heads up to the right people, even if it's not really ready yet
16:35:18 <emilio> astearns: so proposal is to start collecting these layout affecting lines in various typographical systems
16:35:27 <emilio> ... and that'd be a joint effort between CSSWG andf i18n?
16:35:30 <Di> Di has joined #css
16:35:34 <ChrisL> q+
16:35:40 <r12a> pretty picture: https://r12a.github.io/scripts/arab/ug.html#baselines
16:35:41 <emilio> r12a: I think sounds fine if people can find the time
16:35:45 <emilio> fantasai: florian and I can find the time
16:35:46 <astearns> ack ChrisL
16:35:55 <noamr> In hebrew the equivalent of the x height is the Mem height (ם). I think this information is openly available for some languages?
16:36:05 <emilio> ChrisL: I was thinking that the various gap analysis for different languages would be useful
16:36:21 <emilio> ... so that collects the experts from one language and [missed]
16:36:22 <fantasai> noamr, awesome. I've been wondering about what it's called. :)
16:36:38 <emilio> r12a: I think it'd be cool to collect an initial set of what we need first
16:36:43 <emilio> ChrisL: agreed
16:37:12 <emilio> RESOLVED: Start a shared registry on layout-affecting lines as a joint effort between CSS and i18n
16:37:33 <noamr> fantasai:  I think my grandpa defined some of this stuff for Hebrew decades ago :)
16:38:20 <dbaron> s/fantasai:/fantasai,/
16:38:22 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/5421
16:38:22 <github-bot> Topic: [css-fonts-4] Privacy and I18n issues around user-installed fonts, and user selection of them
16:38:22 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5421.
16:38:24 <ChrisL> q+
16:38:36 <ChrisL> https://github.com/w3c/csswg-drafts/issues/4055#issuecomment-536169515
16:38:41 <astearns> ack ChrisL
16:38:59 <emilio> ChrisL: 7 types of users if you follow that line
16:39:06 <emilio> s/line/link
16:40:00 <emilio> [rephrases from linked comment]
16:40:09 <vitorroriz> vitorroriz has joined #css
16:40:22 <argyle> present+
16:40:39 <emilio> r12a: do you have that ??? example? Can't find it r/n
16:40:55 <emilio> s/r12a:/ChrisL: r12a
16:41:36 <ChrisL> s/???/Adlam example
16:42:08 <r12a> chris https://typo.social/@webi18n@w3c.social/112530275400316307
16:42:12 <emilio> ChrisL: was talking about Adlam, so ~45 million speakers, and the system font is just completely unreadable
16:42:25 <emilio> ... the correct version
16:42:26 <r12a> oh, no, not that one
16:42:50 <emilio> ... the screenshot is taken on firefox which prefers system fonts
16:42:51 <Karan> Karan has joined #css
16:43:15 <r12a> this one: https://typo.social/@webi18n@w3c.social/111489082833818738
16:43:17 <emilio> ... we don't want user fonts to be shadowed by system fonts, just wanted to be aware of that category
16:43:42 <emilio> ... at tpac we had some discussion that it became more apparent that in general we don't want to expose every font the user has by default to the web
16:44:09 <kschmi> kschmi has joined #css
16:44:22 <emilio> ... as non-technical users are not aware of how much data they're leaking
16:44:28 <r12a> s|chris https://typo.social/@webi18n@w3c.social/112530275400316307||
16:44:33 <r12a> q+
16:44:40 <weinig> q+
16:44:44 <emilio> ... but we don't want to do it at the expense of users that need local fonts to browse the web
16:44:47 <florian> q?
16:44:47 <r12a> s/oh, no, not that one/
16:44:56 <florian> q+
16:45:40 <emilio> ChrisL: so talked about one language family that "only" has 45m users, but let's talk about mandarin
16:45:48 <emilio> ... there are a lot of new characters
16:46:18 <emilio> ... where users need to install fonts because 2yo fonts don't have them
16:46:23 <emilio> ... font-face doesn't work for that
16:46:33 <emilio> ... the font for these characters is like 3 families with 30mb
16:47:03 <emilio> ... so we need to figure out a solution for the privacy issue without breaking the experience of minority (and non-minority) languages
16:47:08 <emilio> ... various existing proposals
16:47:13 <weinig> q-
16:47:13 <emilio> ... lea did some
16:47:17 <emilio> ack r12a
16:47:18 <astearns> ack r12a
16:47:44 <emilio> r12a: I'm aware of the ???, but I'm concerned about... Is peter here?
16:47:45 <emilio> no
16:48:13 <emilio> r12a: so in the recent formal objection says they want users to control what happens
16:48:18 <emilio> ... the spec says roughly that
16:48:26 <emilio> ... so it's unclear what's being objected to
16:48:47 <emilio> ... so I don't know if the spec is not clear enough or what's needed is for implementors to agree on a solution
16:49:15 <emilio> astearns: don't want to speak for peter but my read is that the objection is that the spec only allows browsers to do this, doesn't require it
16:49:34 <emilio> r12a: do you also agree that the intention is that the user should be able to modify the behavior of the browser
16:49:38 <emilio> astearns: not sure about
16:49:41 <ChrisL> this is the correctly rendered Adlam example (with user installed font) https://w3csocial.files.fedi.monster/media_attachments/files/112/530/273/895/812/226/original/9d7c24263466c1d3.png
16:49:44 <emilio> r12a: it's a bit hidden
16:50:06 <emilio> ... would be good to know what the beef is about exactly
16:50:37 <emilio> astearns: I think the objection is asking us to take this seriously, which I think we've been doing, and unfortunately he hasn't been part of the latest discussions
16:50:48 <ChrisL> Couple more links on Adlam that I was trying to find erlier
16:50:48 <ChrisL> https://www.unicodeconference.org/presentations-41/S7T1-Barry-Barry.pdf
16:50:48 <ChrisL> https://unlocked.microsoft.com/adlam-can-an-alphabet-save-a-culture/
16:51:02 <emilio> r12a: I do have a list of issues which rely on pre-installed fonts
16:51:06 <emilio> ... can paste on IRC
16:51:13 <emilio> ... lmk if you want me to expand on any
16:51:44 <dholbert> dholbert has joined #css
16:51:46 <emilio> ... one of my worries is that e.g. I don't use safari for my work, but most of the work I do is from my localhost or my local harddrive
16:51:49 <dholbert> present+
16:51:57 <emilio> ... in those situations there's no issue about fingerprinting
16:52:09 <emilio> ... those measures shouldn't be applied to file:// or localhost
16:52:30 <emilio> ... I've said it many times but hasn't be picked up
16:52:35 <ChrisL> Agree that fingerprinting needs to be partitioned by domain
16:52:41 <r12a> Reasons pre-installed fonts don't always work, or why fallback to system fonts may not work:
16:52:41 <r12a> - Fonts are not kept up to date in a timely fashion (many examples of this!)
16:52:41 <r12a> - Many non-supported scripts, even though they are in Unicode (see https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-594521142), eg. all of Unicode 16 scripts
16:52:43 <r12a> - Characters that are not in Unicode yet (eg. Klingon)
16:52:44 <emilio> ... shouldn't be fingerprinting protection for local stuff
16:52:45 <r12a> - No support for fonts during development
16:52:47 <r12a> - No support for scripts being added to Unicode (eg. Tolong Siki, Beria Erfe, etc.)
16:52:49 <r12a> - Not even support for scripts already added to Unicode (eg. Todhri, Garay, Gurung Khema, Kirat Rai, Ol Onal, etc.) and recent additions to existing Unicode blocks (numerous examples)
16:52:51 <r12a> - No support for bleeding edge script work, such as new Unicode submissions
16:52:53 <r12a> - Insufficient support for preferred font styles — eg. Javanese, no ruq'a or kano font styles for Arabic, no Mool fonts for Khmer
16:52:55 <r12a> - Insufficient support for opentype options — eg. Kashmiri
16:52:57 <r12a> - Inability to mediate between or fall back to appropriate font styles for certain scripts — eg. Syriac, Tai Tham, etc.
16:53:17 <astearns> ack florian
16:53:20 <emilio> r12a: You also can't rely on web fonts in many situations either
16:53:50 <emilio> florian: it seems that the dilemma is that we have optional measures that need to be optional because they disrupt stuff too much
16:54:24 <emilio> ... the categorization breaks a bit, depending on the OS, whether a font is system installed or user installed isn't super clear
16:54:35 <emilio> ... this distinction is not always clear
16:54:58 <emilio> ... e.g. on windows the japanese package install fonts... are those user or system fonts
16:55:03 <emilio> ... many linux distros have the same issues
16:55:14 <emilio> ... the way users install packages is the same way the os is built
16:55:19 <emilio> ... e.g. debian
16:55:25 <lea> q?
16:55:38 <emilio> ... the entirety of the OS is made of packages you can or can not install
16:55:44 <ChrisL> qq+
16:55:51 <emilio> ... all or none of the fonts might be user installed
16:56:08 <emilio> ... the more our solution depends on user or system fonts the more we hit this
16:56:08 <astearns> ack ChrisL
16:56:08 <Zakim> ChrisL, you wanted to react to florian
16:56:38 <emilio> ChrisL: we had this discussion and we went to try to collect that information and quickly became intractable to maintain
16:56:38 <weinig> q+
16:56:46 <astearns> ack weinig
16:56:47 <emilio> ... so if we can avoid relying on it it'd be nice
16:57:13 <emilio> weinig: you can easily work around that problem by instead considering the browser a closed unit
16:57:25 <emilio> ... the "system fonts" might be bundled with the browser or not
16:57:29 <florian> q?
16:57:33 <emilio> ... you don't need to define the environment in which a browser runs
16:57:42 <emilio> florian: it's a bit more than a terminology problem
16:57:52 <emilio> ... e.g. on macOS all users have helvetica, all users have helvetica
16:58:02 <emilio> ... there's no font that all users of debian have
16:58:09 <emilio> weinig: that sounds like a browser problem
16:58:22 <emilio> ... a browser on debian could come with a bunch of preinstalled fonts
16:58:29 <emilio> ... the dependence on OS is mostly historical
16:58:39 <emilio> florian: to the extent browser rely on the builtin fonts
16:58:48 <r12a> q+
16:59:12 <emilio> weinig: yeah I'm just saying there's a way to describe this in terms of an immutable and a mutable set of fonts
16:59:20 <emilio> ... and not getting into what they come from
16:59:20 <kbabbitt> q+
16:59:27 <emilio> ... and then you don't have that problem
16:59:44 <kbabbitt> q-
16:59:44 <emilio> astearns: suggest we don't spend too much time on this terminology issue of what a system font is
16:59:45 <astearns> ack fantasai
16:59:47 <ChrisL> q?
16:59:48 <jensimmons> jensimmons has joined #css
16:59:53 <emilio> fantasai: wanted to focus back on the main issue
16:59:54 <astearns> ack r12a
17:00:06 <smfr> smfr has joined #css
17:00:14 <smfr> present+
17:00:19 <emilio> r12a: great to see the same thing, the issue is not so much what is a system font but the fact that system fonts don't provide a practical solution right now
17:01:11 <ChrisL> s/practical/complete
17:01:20 <r12a> s/system fonts don't provide a practical solution right now/system fonts don't always provide a practical solution right now
17:01:22 <emilio> astearns: ok, let's try to discuss concrete solutions now
17:01:42 <bts> bts has joined #css
17:02:07 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/11571
17:02:07 <github-bot> Topic: [css-fonts] Exploring better ways to balance privacy, i18n, design tradeoffs for local fonts
17:02:07 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11571.
17:02:50 <emilio> lea: for background we've been discussing this in #5421, but the issue is not only i18n, but there's also issues for authors on regular locales
17:02:59 <emilio> ... web fonts are not always viable for type settings
17:03:16 <emilio> ... even in locales where they are, it increases bandwidth
17:03:25 <emilio> ... so it some sense it also privileges western locales
17:03:59 <emilio> ... so proposal is 'what if we cap the access to a very small number of local fonts per origin'
17:04:16 <emilio> ... that'd also mitigate fingerprinting, which depends on a small number of fonts
17:04:22 <emilio> s/small/large
17:05:00 <emilio> ... it's been brought up that for some minority languages a single font can pinpoint a user a lot
17:05:24 <emilio> ... but the accept-language header does the narrowing already in those cases
17:05:32 <emilio> ... so what counts as font access?
17:05:41 <emilio> ... ideally system font access doesn't count
17:05:56 <emilio> ... fonts after the used font don't count
17:06:08 <emilio> ... but if I have font 1, font 2, font 3 and we use 2, does 1 count?
17:06:21 <emilio> ... we could go either way but if we make them count
17:06:32 <emilio> ... then the limit needs to be bigger
17:06:46 <emilio> ... the data should be managed by the UA
17:07:01 <emilio> ... much like cookies or what not
17:07:07 <emilio> ... the other question is what about iframes?
17:07:34 <emilio> ... in theory there could be even fingerprinting as a service, where it loads tons of iframes of different origins that detect ~8 fonts
17:08:12 <emilio> ... I think only toplevels could get access to fonts, and other contexts would only have access if the top has access
17:08:22 <astearns> q+ to ask about other context’s ability to ask the top-level context for access
17:08:26 <r12a> q+
17:08:49 <emilio> ... which means if you're iframe google login, google would have access to fonts it obtained as a toplevel
17:08:53 <emilio> ... I think that's basically all
17:08:55 <jfkthame> q+
17:09:26 <emilio> astearns: I like the idea of only allowing the toplevel context
17:09:59 <emilio> ... is it possible for an iframe/canvas to request for the toplevel frame to get a font?
17:10:04 <astearns> ack astearns
17:10:04 <Zakim> astearns, you wanted to ask about other context’s ability to ask the top-level context for access
17:10:10 <emilio> lea: haven't thought of it before but ideally you want to limit permission prompts
17:10:31 <emilio> ... if you genuinely allow this you provide a link with `target="parent"`
17:10:40 <astearns> ack r12a
17:10:50 <emilio> ... that still prevents the malicious iframe case
17:11:04 <emilio> r12a: I think the less the user needs to be involved the better
17:11:10 <r12a> Felipe's proposal: https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971
17:11:26 <emilio> ... but I think there are some exceptions
17:11:54 <florian> q?
17:11:56 <astearns> ack jfkthame
17:12:00 <emilio> ... felipe's proposal could be useful
17:12:32 <lea> q?
17:12:41 <emilio> jfkthame: one concern I have with this proposal of a per-site budget is that it seems it could lead to situations where the site ends up behaving differently depending on the particular path the user gets to the page
17:12:45 <florian> q+
17:12:46 <lea> q+
17:12:52 <astearns> ack florian
17:12:52 <emilio> ... that can be very confusing and difficult to understand and diagnose
17:13:13 <emilio> florian: re. whether we should count misses, I think we need to
17:13:24 <emilio> ... otherwise it'd be pretty effective to build a giant font list
17:13:38 <emilio> ... where you have one hit but 300 very specific misses
17:13:49 <emilio> lea: I think you're right
17:13:51 <astearns> ack lea
17:13:54 <dbaron> s/giant font list/giant font list and go through starting from the rarest/
17:13:59 <emilio> ... the idea is that most fingerprinting is about the ones you do have rather than not
17:14:22 <emilio> ... but if you get access to 8 narrow / niche fonts that gives you ton of behavior
17:14:49 <emilio> lea: re. jfkthame's question, the website shouldn't behave differently because the site manages the data
17:14:50 <emilio> q+
17:15:04 <smfr> q+
17:15:04 <kbabbitt> q+
17:15:13 <bramus> scribe+
17:15:15 <astearns> ack emilio
17:15:16 <emilio> ... the idea is that fingerprinting needs a lot of fonts and websites would not hit the limit
17:15:34 <bramus> emilio: i dont agree that users would sually hid that, even manageed by the browser
17:15:47 <bramus> … eg pages with things which happen to have glypsh that I dont ahve installed
17:16:00 <bramus> … now the 6th page or 8th page that I visit hits that limit, and i would not see it
17:16:01 <ydaniv> s/hid/hit/
17:16:08 <bramus> … which i think is what jonathan is concerned about
17:16:15 <bramus> … disagree that its an unrealistic situation
17:16:38 <bramus> … imagine i visit one of richards pages and hit the limit, and then it suddenly stops working when i hit the limit
17:16:39 <lea> s/ the idea is that fingerprinting needs a lot of fonts and websites would not hit the limit/ I tend to agree with florian. The idea was that fingerprinting is more around which fonts you _do_ have, but indeed, knowing about 8 niche fonts does give you a lot of bits of entropy. To reply to jfkthame's concern, the idea is that the limit is designed is such a way that the vast majority of legit websites would not hit the limit
17:16:42 <bramus> … seems relatively common
17:16:47 <lea> s/ the idea is that fingerprinting needs a lot of fonts and websites would not hit the limit/ I tend to agree with florian. The idea was that fingerprinting is more around which fonts you _do_ have, but indeed, knowing about 8 niche fonts does give you a lot of bits of entropy. To reply to jfkthame's concern, the idea is that the limit is designed is such a way that the vast majority of legit websites would not hit the limit/
17:16:49 <bramus> … also, q about the persistence thing
17:17:05 <bramus> … reason is to avoid case where page navigates and you hit differen tnumer of fonts –annoying
17:17:12 <bramus> … making the budget persistent feels …
17:17:20 <bramus> astearns: you make it persistent over a certain time frame
17:17:26 <lea> q+
17:17:28 <bramus> … so dipping into a list takes too long
17:17:33 <bramus> emilio: leads to less determinism
17:17:43 <bramus> … do they rememember that i visited the page x months ago?
17:17:52 <astearns> ack smfr
17:18:01 <emilio> smfr: I disagree that you need a lot of user installed fonts to get a fingerprint
17:18:08 <emilio> ... fonts are a very high signal vector
17:18:18 <kbabbitt> q-
17:18:27 <astearns> ack dbaron
17:18:28 <florian> q+
17:18:30 <emilio> ... so a single font might identify it as a minority user that might be very high value signal for some people
17:19:11 <lea> qq+ to reply to dbaron
17:19:13 <emilio> dbaron: two comments, wasn't clear to me how much this proposal is targetting font stacks or values of font-family vs. fonts you actually use even if you use them by last-resort-fallback when you fail to find stuff in the font-family list
17:19:19 <emilio> ... I think it's worth being clear about that
17:19:47 <emilio> ... the other comments is it's not clear how a privacy mitigation imposing specific limits interacts with things like bounce tracking
17:19:54 <emilio> ... and whether it's been solved at this poing
17:19:59 <emilio> s/poing/pont
17:20:10 <astearns> ack lea
17:20:10 <Zakim> lea, you wanted to react to dbaron to reply to dbaron
17:20:10 <emilio> s/pont/point
17:20:19 <emilio> lea: a font would only count only when accessed
17:20:26 <emilio> ... so only when the font is being queried
17:20:35 <smfr_> smfr_ has joined #css
17:20:42 <emilio> ... if you have a stack of 5 fonts and you use font # you've used 3 fonts not 5
17:20:54 <emilio> ... same with font-face, each local() lookup
17:21:10 <emilio> dbaron: I think it's worth noting font fallback is per char
17:21:47 <emilio> ... but one character might go through the whole list and then fall back to a system search
17:21:47 <bramus> emilio: except you want it to be a user font
17:22:04 <emilio> lea: yeah a system fallback is usually a system font
17:22:20 <emilio> ... I think these would be handled fine with a well defined limit
17:22:26 <astearns> ack lea
17:22:38 <emilio> lea: I didn't quite understand the wikipedia argument from emilio
17:22:46 <emilio> ... what about a website that has a lot of languages
17:22:54 <emilio> ... is kind of the same argument
17:23:07 <emilio> ... you usually get one or two languages
17:23:13 <dbaron> I think displaying a language selector may be a common case.
17:23:16 <emilio> ... I don't think going through all languages is common
17:23:21 <emilio> r12a: some of us do that
17:23:21 <emilio> q+
17:23:43 <bramus> emilio: yeah, wikipedia hits a lot of font fallback because of their sidebar with all fonts
17:23:54 <bramus> … the characters are there on the page, even if i dont speak it
17:24:03 <bramus> … wikipedia would hit the reasonable limit
17:24:09 <dholbert> (^in the choose-your-language dropdown in particular)
17:24:13 <bramus> lea: webfonts dont count in this case
17:24:20 <bramus> emilio: i dont think they use that
17:24:47 <lea> q?
17:24:49 <bramus> … using the webfont is what they not want to happen
17:25:07 <bramus> … a lang selector is a use case where you may have chars from many langs
17:25:25 <bramus> … even when reading wikipedia in your language, there can be names with other chars
17:25:38 <bramus> lea: are you sure wikipedia is not using system installed fonts?
17:25:51 <bramus> emilio: i think its easy to hit the case that jonathan mentioned
17:26:07 <bramus> florian: lets refocus on trying to solve the i18n problem
17:26:15 <bramus> s/florian/fantasai
17:26:27 <astearns> ack florian
17:26:27 <bramus> … lets try and solve the worst part of the problem
17:26:45 <emilio> florian: in a way I agree and in a way I don't
17:27:15 <emilio> ... we want a mandatory solution
17:27:26 <r12a> q+
17:27:27 <emilio> ... so we need to make it work not only for the i18n use case
17:27:46 <emilio> ... if it's mandatory and breaks other use cases is not good enough
17:28:11 <emilio> ... we need to keep the web functional
17:28:21 <emilio> fantasai: I don't think loading ?? is a requirement to keep the web functional
17:28:29 <bramus> s/??/hoefler
17:28:34 <fantasai> s/??/a local copy of Hoefler/
17:28:47 <bramus> q+
17:28:52 <emilio> florian: if we make it work for minority languages but the wikipedia language selector doesn't work that's wrong
17:29:24 <emilio> ... re smfr comment, yeah minority communities are easy to target
17:29:31 <emilio> ... but it goes both ways
17:29:48 <emilio> ... the best way to preserve their privacy would be to not get websites in their language, which would be unfortunate
17:29:58 <ChrisL> Exactly
17:30:02 <astearns> unacceptable, not unfortunate
17:30:28 <emilio> jensimmons: it feels a large part of this is debating whether fingerprinting or i18n is more important
17:30:34 <r12a> qq+
17:30:41 <emilio> ... I think we should just discuss about solutions instead
17:30:45 <emilio> florian: was not my intent
17:30:47 <lea> jensimmons: I thought that's exactly what we were doing?
17:31:03 <emilio> florian: but current solutions favor one over other
17:31:07 <emilio> ... agreed we need to fix both
17:31:18 <astearns> ack r12a
17:31:18 <Zakim> r12a, you wanted to react to florian
17:31:48 <emilio> r12a: re. jensimmons's comment I don't think anybody is framing things in those terms
17:32:01 <emilio> ... that sets up the principle that we should have both
17:32:12 <emilio> ... I think we've established that on the spec already
17:32:41 <emilio> ... and I'm wondering why we're discussing these solutions... are we going to put them in the spec?
17:32:53 <emilio> astearns: I think the idea is to put them in the spec
17:33:00 <ChrisL> q+
17:33:03 <florian> s/the best way to preserve their privacy would be to not get websites in their language, which would be unfortunate/A very effective way to preserve privacy for a minority group would be to let them use the web at all, which is effectively what happens when their language doesn't work, but that's not a real solution
17:33:07 <r12a> q-
17:33:11 <noamr> I wonder if we can do something about limiting this on the measuring side
17:33:13 <astearns> ack ChrisL
17:33:39 <emilio> ChrisL: yeah we're specifically looking for things that are going to be in the spec because what we have right now is too vague and too optional
17:33:40 <florian> s/would be to let them use /would be to not let them use
17:33:53 <astearns> ack fantasai
17:34:17 <emilio> fantasai: before we continue, do we agree that allowing user installed fonts is necessary to solving i18n?
17:34:19 <ChrisL> qq+
17:34:26 <emilio> ... because maybe the solution is for the OS to ship more fonts
17:34:29 <astearns> ack ChrisL
17:34:29 <Zakim> ChrisL, you wanted to react to fantasai
17:34:33 <fantasai> s/maybe/I've heard people assert/
17:34:39 <emilio> ChrisL: it cannot be solved by shipping good fonts, it's not just char coverage
17:34:50 <emilio> ... it's also rendering and per script differences
17:34:56 <r12a> qq+
17:35:00 <emilio> ... one good font to rule them all is not going to solve it
17:35:07 <weinig> q+
17:35:12 <emilio> fantasai: that's your position, is that the working group position?
17:35:28 <emilio> ... are there people that this is solved by the OS shipping the correct amount of fonts?
17:35:37 <fantasai> s/that this/that believe this/
17:35:53 <emilio> astearns: I think I've been convinced by the examples that we need local font access in some cases
17:36:01 <emilio> smfr: there are no user installed fonts on many mobile OSes
17:36:30 <emilio> ... e.g. iOS doesn't have the concept of user installed fonts
17:36:35 <ChrisL> qq+
17:36:36 <emilio> ... not sure what the situation is on android
17:36:39 <astearns> ack r12a
17:36:39 <Zakim> r12a, you wanted to react to ChrisL
17:37:01 <emilio> r12a: the long list on IRC earlier list situations where you might not be able to get away with the fallback to system fonts
17:37:25 <emilio> ... the browsers currently don't support the need of users around the world
17:37:45 <emilio> ... maybe because there's no system fonts, or because they're not diverse enough
17:38:02 <noamr> q+
17:38:10 <romain> Would it be sufficient to place severe limits on local fonts on offscreen content?
17:38:11 <romain> Seems that any finger printing technique would prefer to do this without the user noticing and will use non-visible text.
17:38:11 <romain> Only allowing local fonts for visible and in viewport content might be an acceptable compromise?
17:38:28 <emilio> ... e.g. safari with the kashmiri font is not present, and if you downloaded the noto font
17:38:47 <emilio> ... you can still don't have access to the right script
17:39:02 <emilio> ... I work with minority scripts a lot and I don't think system fonts cover the long tail
17:39:06 <florian> q+
17:39:26 <astearns> ack ChrisL
17:39:26 <Zakim> ChrisL, you wanted to react to ChrisL
17:39:43 <ChrisL> q?
17:40:00 <emilio> ChrisL: responding to simon, the point is not that some have user fonts, on the platforms that do users shouldn't be penalyzed by not using them
17:40:16 <emilio> ... for OSes that don't have user fonts we need some other solution
17:40:20 <jamesn> jamesn has joined #css
17:40:38 <astearns> ack florian
17:40:43 <emilio> ChrisL: Is it worth putting a question of whether local font access is the group position?
17:40:50 <emilio> florian: to me what safari does should not be forbidden
17:40:57 <emilio> ... but it can't be required of everyone
17:41:11 <emilio> ... but do we want to require that all browsers must give access to local fonts? I don't think so
17:41:20 <emilio> ... can we mandate that nobody does?
17:41:25 <emilio> ... probably not either
17:42:13 <emilio> ... it's a UA tradeoff, the web as a whole can't choose for which users you prioritize
17:42:30 <florian> s/browsers must give access /browsers must deny access
17:42:46 <emilio> ChrisL: seems to weak to be actionable. My preferred solution I would rather peek one or the other that seems very exclusionary
17:42:55 <emilio> ... implementations that do that should be non-compliant with the spec
17:43:39 <emilio> astearns: I think we table this because the exact framing is important
17:43:44 <astearns> ack emilio
17:43:59 <bramus> emilio: i dont think this framing is ???
17:44:05 <noamr> exclusionary
17:44:09 <bramus> … lets say we dont want to give access to random fonts
17:44:13 <astearns> s/???/necessarily exclusionary/
17:44:14 <bramus> … firefox bundles emoji fonts
17:44:21 <bramus> … so could bundle fonts for minority scripts and langs
17:44:30 <bramus> … agree to not exclude users by restricinting thing
17:44:31 <noamr> I think I have an actionable direction idea, hope I get an opportunity
17:44:35 <bramus> … but there might be other solutions
17:44:59 <bramus> … in the apple case they can install a bunch of fonts in the OS but would not fix every page ever but that would be a decent tradefoff
17:45:16 <astearns> ack bramus
17:45:31 <ChrisL> s/rather peek/rather not pick/
17:45:51 <emilio> bramus: one of the things I like about iOS is that whenever an app needs the camera roll I can choose which photos
17:45:58 <dbaron> (Android does that too)
17:46:00 <emilio> ... could we do something like that for fonts?
17:46:28 <florian> +1
17:46:33 <emilio> ... where basic fonts are fine but you don't over share, and you can handle r12a's use case
17:46:35 <romain> +1
17:47:04 <emilio> iank_: there's problems with that apparoach
17:47:09 <r12a> qq+
17:47:15 <emilio> ... [missed]
17:47:17 <Ragvesh> Ragvesh has joined #CSS
17:47:26 <emilio> astearns: the design of an opt in is a different feature from a budget
17:47:37 <emilio> bramus: it could be an alternative for a magic budget number
17:47:41 <emilio> astearns: or it could be both
17:47:53 <emilio> florian: details can be discussed or not
17:48:08 <astearns> ack dbaron
17:48:11 <emilio> ... but the existance of opt in changes the equation of whether budget needs to deal with all sites
17:48:15 <ChrisL> q?
17:48:22 <emilio> dbaron: florian made a list of requirements of a solution should be
17:48:24 <florian> s/discussed or not/discussed separately
17:48:28 <emilio> ... wanted to add one
17:48:46 <emilio> ... if we're going to have a solution in the spec we need to do enough analysis that it's really blocking some amount of entropy that's real
17:48:50 <Ragvesh> Ragvesh has joined #CSS
17:48:54 <emilio> ... and not just making it harder to get those bits
17:49:02 <emilio> ... this requires some detailed analysis
17:49:14 <emilio> ... the concern is that we say we found an answer and we don't do that analysis
17:49:26 <emilio> ... we're asking implementors to spend time implementing something that doesn't meet the goals
17:49:27 <bramus> s/where basic fonts are fine but you don't over share, and you can handle r12a's use case/where basic fonts are fine but you don't over share, and you can handle r12a's use case. sharing fonts could even be limited to a per-site or per-origin basis.
17:49:37 <ChrisL> dbaron ++
17:49:41 <astearns> ack r12a
17:49:41 <Zakim> r12a, you wanted to react to bramus
17:49:50 <emilio> ... we should make sure that this solution meets the privacy goals in addition to the i18n requirements
17:50:03 <emilio> r12a: I want to be wary about the "this is probably good enough" approach
17:50:17 <emilio> ... we are discussing scripts for which they are not system fonts
17:50:28 <emilio> ... people would be designing fonts and see how they look like on the browser
17:50:36 <emilio> ... can't use safari anymore for that sort of work
17:50:49 <astearns> ack weinig
17:51:27 <emilio> weinig: This seems like litigating thigns that are not usually what the WG works on. Wonder if there's similar privacy issues that have been solved in similar ways
17:51:46 <emilio> ... we don't even define past the UA so I wonder if there's a good parallel to take inspiration
17:52:28 <bramus> emilio: the ?? mitigation stuff comes to mind, where all browsers implement an interoperable pricacy mitigations, like :visited where we all lie in gCS
17:52:34 <kbabbitt> s/??/:visited/
17:52:58 <emilio> florian: we also allow but not require the browser to lie about window / screen / position
17:53:08 <emilio> weinig: that'd be in favor of the current status quo
17:53:24 <emilio> astearns: a number of features that impact privacy that we rely on wide review
17:53:33 <emilio> ... we don't have that much privacy expertise
17:53:51 <emilio> ... but we run into these issue and deal with them with the privacy groups that do
17:54:07 <emilio> ... while you're right that the OS bits are not our usual domain, fonts are
17:54:20 <emilio> weinig: would be good to set bounds on what potential solutions would look loike
17:54:37 <emilio> ... lots of options from prompting on any use to budget to UI in browser preferences
17:54:44 <emilio> ... setting those bounds would help
17:55:03 <astearns> q?
17:55:05 <r12a> s/we are discussing scripts for which they are not system fonts /for example, in the Unicode committee meeting i will be attending in a few minutes we are discussing scripts for which we are a long way from having pre-installed fonts
17:55:32 <emilio> ... e.g. would be an issue if safari allowed the user to explicitly use these fonts in an advanced preference
17:55:39 <emilio> ... would that be a solution that's reasonable?
17:55:55 <smfr> q+
17:55:59 <r12a> s/people would be designing fonts /also people would be designing fonts /
17:56:02 <astearns> ack noamr
17:56:59 <emilio> noamr: Another mitigation could be to treat local font as if they were webfonts but still allow them to load would work perhaps
17:57:27 <emilio> ... delaying the local font availability or what not, the tracking page can't tell if it was downloaded as a web font vs it was a local font
17:57:42 <emilio> ... maybe the issue is that this is explicitly a local font that might not need to be?
17:57:53 <emilio> astearns: that might have merit
17:58:05 <emilio> ... would be good to discuss in a different issue
17:58:14 <ChrisL> and we already have, in the spec "Web Fonts shadow Installed Fonts, so if an Installed Font has the same family name as a Web Font, the Installed Font is not accessible." which would cover that case
17:58:19 <astearns> ack smfr
17:58:22 <emilio> ... I don't think this would be sufficient because the page knows if it has requested a @font-face
17:58:44 <florian> s/it's a UA tradeoff, the web as a whole can't choose for which users you prioritize/it's OK as a UA tradeoff to prioritize the experience of some users at the expense of not serving everyone, but the web as a whole cannot, it has to serve everyone
17:58:50 <emilio> smfr: imagine we fix this by having the ua download a web font when it sees glyphs in a particular unicode range
17:59:06 <emilio> ... maybe there are solutions that aren't about user installed fonts
17:59:09 <noamr> I think we suggested a similar thing smfr :)
17:59:18 <emilio> ... but UAs solving it in creative ways
17:59:33 <Adam_Page> Adam_Page has joined #css
17:59:45 <emilio> astearns: I think separate issues for separate proposals would be good
17:59:49 <emilio> ... anything else?
18:00:04 <Francis_Storr> Francis_Storr has joined #css
18:00:16 <ChrisL> topic: break
18:00:26 <r12a> thankyou CSS WG for the discussion
18:07:16 <zrhoffman> zrhoffman has joined #css
18:13:56 <joshtumath> joshtumath has joined #css
18:24:08 <castastrophe> castastrophe has joined #css
18:24:21 <TabAtkins> ScribeNick: TabAtkins
18:24:23 <Di> Di has joined #css
18:24:43 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/4573
18:24:43 <github-bot> Topic: [css‑fonts‑4] Create keywords for `unicode‑range`
18:24:43 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/4573.
18:25:06 <alisonmaher> alisonmaher has joined #css
18:25:17 <TabAtkins> ChrisL: I put this on the agenda because i thought i18n people would be here. We ahve a reoslution to do it but it's not enough to evne produce a candidate spec text.
18:25:23 <TabAtkins> ChrisL: propose we push it, since they're no longer here
18:25:46 <kbabbitt> TabAtkins: ChrisL do you want to arrange something with i18n wg?
18:25:49 <kbabbitt> ChrisL: yes
18:26:03 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9392
18:26:03 <github-bot> Topic: [css-fonts] Specifying a direction without a specific angle
18:26:03 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9392.
18:26:10 <smfr1> smfr1 has joined #css
18:26:57 <TabAtkins> florian: this isn't an isolated issue, a bunch of issues with related use-cases
18:27:05 <TabAtkins> florian: tyring to isolate, but it might bring the whole convo
18:27:21 <TabAtkins> florian: one thing we're trying to talk about is, it's more frequent in some languages than others to have italics and obliques go either way
18:27:25 <TabAtkins> florian: right or left leaning
18:27:32 <TabAtkins> florian: at the moment this is invisible to the platform
18:27:46 <ChrisL> q+
18:27:51 <TabAtkins> florian: a user could try and pick the right font that goes the way they want, and it looks right, but the font stack has no awareness of whether it's learning left or right
18:27:54 <TabAtkins> florian: and thus can't help you
18:28:05 <TabAtkins> florian: so if you have chosen - say you're in Arabic it makes more sense to lean left
18:28:26 <TabAtkins> florian: but we have some font fallback, browser will pick another font or synthesize one. it knows you're using italic, but it might italic rightwards
18:28:37 <TabAtkins> florian: it knew you were italic, but didn't know you were left-leaning
18:28:47 <TabAtkins> florian: so i think there should be this information
18:29:13 <TabAtkins> florian: when you specify "italic", or providing an italic font, shoudl be possible to specify it's "left-leaning" italic. or be able to *request* a left-leaning italic
18:29:20 <TabAtkins> florian: some discussion about what fallback's allowed.
18:29:31 <TabAtkins> florian: seaprate issues about those, not currently quite ideal
18:29:53 <TabAtkins> florian: but the fact that you can't express the lean direction needs to be addressed
18:30:02 <astearns> ack ChrisL
18:30:06 <TabAtkins> florian: so i propose a left/right keyword optionally allowed in italic and oblique specifications
18:30:44 <TabAtkins> ChrisL: something that has improved since this was raised, it used to be you could ask for an italic angle at, say, -5 degrees, and if there was a -20 and +8, it would choose the +8 becuase it was closer. Now we require you to search the same direciton first.
18:31:03 <TabAtkins> florian: for obliques you can specify the angle and it has a sign, so you have the lean direction (and more than that)
18:31:16 <TabAtkins> florian: but for italic there's no angle at all
18:31:26 <TabAtkins> florian: you just say "italic", no direction
18:31:49 <ChrisL> q+
18:31:51 <TabAtkins> florian: so arguably you could say this is solved in oblique fonts since you can say an angle (but it shoudl be possible to omit the angle), but italic doesn't have it
18:31:59 <TabAtkins> florian: in variable fonts there's a bit of this but not in non-variable
18:32:07 <TabAtkins> ChrisL: disagree. in opentype ther'es SLNT axis
18:32:16 <TabAtkins> ChrisL: also ITAL, which is a bool
18:32:26 <TabAtkins> ChrisL: this may involve the SLNT axis, but doesn't have to
18:32:33 <TabAtkins> ChrisL: you just can't say "i want 30% italic"
18:32:46 <TabAtkins> florian: you say there is variable information about angle, is that only variable fonts?
18:32:53 <TabAtkins> ChrisL: don't know if non-variables have such information
18:33:05 <TabAtkins> florian: Okay, two bits. One is expressing what the font does, the other is requesting.
18:33:20 <TabAtkins> florian: expressing might already be int he data, might be augmentable by @font-face
18:33:34 <TabAtkins> florian: but on request, there's just no way to express "i want a left-leaning font"
18:33:52 <TabAtkins> weinig: I think italic is a variation axis from 0-1, not just a bool
18:34:14 <TabAtkins> astearns: there's also a question of if we're just talking about left/right, or also add forwards/backwards as crissov suggested?
18:34:23 <TabAtkins> florian: ltr/rtl dependent keywords? possibly.
18:34:36 <ChrisL> https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_ital
18:34:43 <TabAtkins> florian: So, my primary demand would be to add left/right (and maybe logicals) to font-style property. in some fonts we'll have sufficient information to pick this.
18:35:03 <TabAtkins> florian: And secondarily, once we can express the request, do we want to complement with a descriptor in @font-face to let you specify the direction if the font doesn't specify.
18:35:11 <ChrisL> "An italic font should not be characterized in the STAT table as being italic and also having some slant, unless the font family includes multiple italic designs with different amounts of slant."
18:35:19 <TabAtkins> astearns: Can we resolve to add this info to the property and to a describptor?
18:35:37 <TabAtkins> astearns: Do people need more discussion?
18:35:47 <TabAtkins> (sounds good to me, but I'm weakly opinionated here)
18:35:55 <TabAtkins> astearns: we could add it and see fi people complain?
18:36:11 <TabAtkins> proposed: Add these keywords to font-style and to the @font-face descriptor.
18:36:14 <TabAtkins> astearns: objections?
18:36:31 <TabAtkins> RESOLVED: Add left/right (and maybe logical variants) to font-style, and to @font-face
18:36:42 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9390
18:36:42 <github-bot> Topic: [css-fonts] font-synthesis-style is too blunt
18:36:42 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9390.
18:36:57 <TabAtkins> florian: font-synthesis-style isn't quite doing what most poeple want to use it for (i claim)
18:37:15 <TabAtkins> florian: general notion is that some of the time, when you say italic, you kinda just mean "slanted", and italic is a pretty type of slanted
18:37:29 <TabAtkins> florian: if it's not there, you're okay with oblique, which is the normal letter shape but slanted, rather than a different letter shape
18:37:42 <TabAtkins> florian: but sometimes you really want to insist on italic and not fall back to oblique
18:37:49 <TabAtkins> florian: we say to use font-synthesis-style for that, but it doesn't work
18:38:12 <TabAtkins> florian: as currnetly specified, if you ahve a non-synth'd oblique font, the system *will* fall back to oblique even if you say synthesis:none, which i argue is almost never what they want
18:38:15 <TabAtkins> florian: that's first problem
18:38:37 <TabAtkins> florian: a lesser problem is i think it's extremely rare for someone who's explicitly requested oblique to not want a synthesized oblique when a natural isn't available
18:38:55 <TabAtkins> florian: difference between synthesized and manual italic can be big, but between synthesized and real oblique is pretty small
18:39:03 <TabAtkins> florian: so rare to care much about the differnece
18:39:22 <TabAtkins> florian: so i think it shoudl be possible for authors to epxress "don't fall back from italic to oblique" and also "if you fall back from oblique, it's okay to synthesize"
18:39:41 <TabAtkins> florian: I think a solution for this is to just add some more values to font-synth-style. we already have auto and none
18:39:59 <TabAtkins> florian: maybe shoudl add no-oblique that prevents italic->oblique fallback
18:40:11 <TabAtkins> florian: arguably a bit weird since it's fallback rather than synth, but this property is kinda doing that
18:40:37 <ChrisL> q+
18:40:38 <TabAtkins> florian: alternative is to change 'none' to do the "right thing", and add a new keyword oblique-only, allowing synthesizing oblique but not synthesizing italic *from* oblique
18:40:53 <astearns> ack ChrisL
18:40:54 <TabAtkins> florian: so proposal is "auto | none | oblique-only", and people should be advised to use oblique-only
18:41:06 <TabAtkins> ChrisL: I agree with that last one, emilio also proposed that. i think it makes the most sense.
18:41:11 <TabAtkins> astearns: me too
18:41:20 <TabAtkins> astearns: so proposed is to add oblique-only to font-synth-style
18:41:26 <TabAtkins> ChrisL: can i explicitly ping jfkthame ?
18:41:46 <TabAtkins> jfkthame: I guess this is reasonable. Not sure how big of a need there really is.
18:42:11 <TabAtkins> jfkthame: if the properties call for italic and there's no italic face, and oblique-only, what's the user gonna get? Is that really what they want? I'm not sure it is.
18:42:20 <TabAtkins> jfkthame: I'm not opposed, but also not particualrly convinced it's a big deal.
18:42:39 <TabAtkins> florian: that's generally a problem with synth; if the font isn't there, and you've turned off synthesis, you don't get what you're asked for.
18:42:39 <astearns> s/Is that really/They get regular. Is that really/
18:42:56 <TabAtkins> florian: at the moment the way we give you "not what you asked for" is almost certainly not what you expect, in some cases.
18:43:27 <TabAtkins> astearns: so jonathan is not opposed. anyone need more discussion? objections?
18:43:56 <TabAtkins> RESOLVED: Add oblique-only to font-synthesis-style, which synthesizes oblique but prevents using oblique as italic fallback.
18:44:07 <github-bot> Topic: [css-fonts] avoid fallback from oblique to italic
18:44:24 <TabAtkins> florian: currently we define that if the user requests eitehr italic or oblique, and you dont' have one, you give them the other
18:44:51 <TabAtkins> florian: unless you've opted out like we've just discussed, i think falling back from italic to oblique is reasonable. less convinced falling back from oblique to italic is reasoanble. but we do both ways.
18:45:19 <TabAtkins> florian: because italic has the fallback, and it's what people usually know about, they'll usually ask for italic. And if there's no italic they'll get oblique, which is what they wanted anyway.
18:45:31 <TabAtkins> florian: But if you specifically asked for oblique, I think you should get oblique, not fall back to italic.
18:45:53 <TabAtkins> florian: and unless I'm confused, we have two levels of falling back - we try this first, and if it doesn't work we use the font stack
18:46:05 <ChrisL> q+
18:46:14 <TabAtkins> florian: result is if you ask for oblique, find the font, it has normal and italic, you get italic. you dont' search further for an oblique.
18:46:27 <TabAtkins> jfkthame: i'd argued we shoudl be synthing an oblique from the regular at that point.
18:46:37 <TabAtkins> florian: agree. synth oblique instead of natural oblique is reasonable.
18:46:54 <ChrisL> So we would delete "For the purposes of font matching, User agents may treat italic as a synonym for oblique."
18:46:54 <TabAtkins> florian: currently we dont' do that if italic is avaialbe. we should jsut synth oblique instead as you asked.
18:46:57 <astearns> ack ChrisL
18:47:03 <TabAtkins> ChrisL: I agree we shoudl synth oblique
18:47:11 <TabAtkins> ChrisL: we have language in the spec that says [quote above]
18:47:18 <TabAtkins> ChrisL: that's a stupid thing to say, we shoudl delete that sentence
18:47:52 <TabAtkins> astearns: i'm looking nthru the issue, we had a previous proposed resolution to not allow fallback between italic and oblique, and that failed to get consensus. what does that mean?
18:48:34 <TabAtkins> florian: Chris, you mentioend resistence, but cited my comment and I wasn't resisting
18:48:37 <ChrisL> https://github.com/w3c/csswg-drafts/issues/9389#issuecomment-2049382909
18:48:47 <TabAtkins> ChrisL: it was domenic that had the objection
18:48:55 <TabAtkins> s/domenic/drott/
18:49:36 <TabAtkins> astearns: in my reading, part of his problem is the proposed reoslution only removed the fallback oblique->italic, and didn't mention we shoudl be synthing oblique rather than doing stack fallback
18:50:03 <TabAtkins> astearns: so a resolution that says "if you ask for oblique and the first matching font doesn't have it, synthesize it" and not allowing fallback from oblique to italic
18:50:12 <TabAtkins> astearns: jfkthame, that make sense?
18:50:14 <TabAtkins> jfkthame: i think so
18:50:22 <TabAtkins> astearns: shall we try that resolution?
18:50:29 <TabAtkins> proposed resolution: above
18:51:09 <TabAtkins> RESOLVED: Disallow fallback from oblique to italic. Also, unless synthesis is prevented, synthesize oblique from normal font when oblique is requested.
18:51:52 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11430
18:51:52 <github-bot> Topic: [css-fonts] Should `font-style: oblique 0deg` serialize as `font-style: normal`?
18:51:52 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11430.
18:52:30 <TabAtkins> weinig: When animating from 'normal' to 'oblique' thru 'oblique 0', should we serialize that as 'normal' or not?
18:52:54 <TabAtkins> weinig: It seems more straightforward to always serialize oblique as 'oblique 0', but shortest-serialization does suggest we shoudl serialize it as 'nromal'
18:53:00 <emilio> q+
18:53:01 <TabAtkins> weinig: tests are inconsistent
18:53:28 <florian> q?
18:53:29 <florian> q+
18:53:37 <astearns> ack emilio
18:53:38 <TabAtkins> weinig: rather, they were inconsistent. now they always serailize 'nromal' as 'oblique 0' when animating, but as 'nromal' otherwise
18:53:53 <TabAtkins> weinig: there was a decision a while back to animate 'normal' as 'oblique 0'
18:54:20 <TabAtkins> ChrisL: fantasai had suggested we treat the *computed value* of nromal as oblique 0, but should serialize as normal
18:54:31 <TabAtkins> weinig: we could do that, so oblique 0 always serializes as normal
18:54:38 <ChrisL>  normal computes to oblique 0deg and oblique 0deg serializes as normal.
18:55:21 <TabAtkins> emilio: question is if normal and oblique 0 are same value or not. if they're the same, we shoudl serialize consisntently. and for compat 'nromal' has to serialize as 'normal', so we shoudl do the same with 'oblique 0'
18:55:27 <TabAtkins> weinig: totally doable, jsut need to state it
18:55:28 <astearns> ack florian
18:55:37 <TabAtkins> florian: i agree with that, and it's not just compat arguing for it, also SSP
18:55:47 <TabAtkins> florian: so multiple args to serialize them both as 'normal'
18:56:15 <TabAtkins> emilio: fwiw right now in gecko they're not the same value, but when you animate you turn 'normal' into 'oblique 0'. it's kinda a special case, would be fine to remove it
18:56:33 <astearns> ack dbaron
18:56:48 <TabAtkins> dbaron: trying to remember chris's points about font matching earlier
18:57:12 <TabAtkins> dbaron: is the idea that 'oblique .001' you'll search for an oblique closest to that slant, but 'oblique 0' you won't search? is there that discontinuity?
18:57:15 <TabAtkins> ChrisL: i think so, yes
18:57:23 <TabAtkins> dbaron: given the discontinuity exists, the serialization seems reasonable
18:57:35 <TabAtkins> (clearly need to distinguish oblique 0 from oblique -0)
18:57:49 <TabAtkins> astearns: if we agree on this, it'd be a WPT change and impl chnage?
18:57:49 <astearns> closest to that slant direction
18:57:52 <TabAtkins> weinig: yes, but trivial
18:58:02 <TabAtkins> emilio: yeah relatively little compat impact
18:58:19 <TabAtkins> astearns: so for parsimony, resolution is 'normal' and 'oblique 0' are the same value, and serialize as 'normal'
18:58:38 <TabAtkins> jfkthame: imagine a font family that contains a fixed regular face and a variable oblique face
18:58:45 <TabAtkins> jfkthame: the slant might be zero
18:58:56 <TabAtkins> jfkthame: it seems liek saying they're the same we're losing the ability to differentiate between those two faces
18:59:05 <TabAtkins> jfkthame: they might look different at the 0deg angle
18:59:08 <TabAtkins> astearns: that's correct
18:59:12 <emilio> q+
18:59:37 <TabAtkins> astearns: is there utility in being able to pick the new version with a 0deg slant that we're locking out with this decision?
19:00:05 <astearns> ack emilio
19:00:07 <TabAtkins> weinig: i don't know how to interpret the slnt table, it says 0 is required to be the "regular" value. i don't think it's even a meaningful disinction then in opentype
19:00:41 <TabAtkins> emilio: you already lose that distinction when you animate. since we do want to allow the animation from normal to oblique values, it would feel weird if you animate back and forth and you end up with a different font.
19:01:08 <TabAtkins> emilio: I don't think that edge case (which might nto even matter in practice, given sam's comment) i don't think it's worth reintroducing the distinction
19:01:24 <TabAtkins> astearns: do you have specific fonts in mind, jfkthame ?
19:01:27 <ChrisL> q+
19:01:30 <TabAtkins> jfkthame: no, just trying to envision what it means
19:01:53 <TabAtkins> astearns: is this enough to object to the resolution, or would you be okay with us taking the resoltuion since we dont' have evidence of the problem being an author issue?
19:01:57 <TabAtkins> jfkthame: not going to object
19:02:10 <TabAtkins> jfkthame: i think if it exists at all it's a niche thing, just wanted to bring the question up
19:02:10 <astearns> ack ChrisL
19:02:22 <TabAtkins> ChrisL: i read the opentype spec as trying to prevent that conflict from happening
19:02:39 <TabAtkins> ChrisL: they're tyring to make sure that if you have "regular" in your face, you shoudl be using that for 0 SLNT
19:02:44 <TabAtkins> ChrisL: so it shoudln't happen for well-behaved fonts
19:03:04 <TabAtkins> RESOLVED: 'normal' and 'oblique 0deg' are the same value, and serialize as 'normal'
19:03:13 <TabAtkins> jfkthame: minor followup, how does 'oblique 14deg' serialize
19:03:36 <TabAtkins> ChrisL: I think it should be oblique 14deg
19:03:50 <TabAtkins> ChrisL: at one point the default was 20deg, we changed it. would prefer to avoid that ambiguity.
19:03:59 <TabAtkins> fantasai: that's not backwards compatible tho
19:04:12 <joshtumath> joshtumath has joined #css
19:04:15 <TabAtkins> weinig: other way around, should oblique 14deg serialize as oblique
19:04:27 <TabAtkins> fantasai: can a font have a preferred oblique angle?
19:04:31 <florian> q?
19:04:31 <TabAtkins> weinig: the spec says ti's always 14deg
19:05:03 <TabAtkins> florian: the spec says that if you synthesize, you use 14deg; does it say that omitting *uses* 14deg?
19:05:08 <TabAtkins> weinig: yes. [gives quote]
19:05:10 <TabAtkins> florian: okay
19:05:35 <TabAtkins> emilio: having `oblique` mean something different from a specific angle woudl also make interpolation harder
19:05:44 <TabAtkins> florian: maybe we should have `oblique from-font`?
19:05:48 <TabAtkins> weinig: I'll file a new issue.
19:06:01 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10674
19:06:01 <github-bot> Topic: [css-fonts][css-values][css-viewport] UAs inconsistent in how OS font settings affect the default font-size `medium`
19:06:01 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10674.
19:06:26 <TabAtkins> dgrogan: this is about authros needing access ot the OS default font size
19:06:35 <TabAtkins> dgrogan: they can do it today but it's hacky, should have more standardized way
19:06:40 <TabAtkins> dgrogan: have talked aobu thtis a few times
19:06:49 <TabAtkins> dgrogan: settled on either an env() or a new unit
19:07:06 <TabAtkins> dgrogan: I think new unit has some good arguments for it. A few abbrevs suggested in the issue
19:07:37 <TabAtkins> dgrogan: we also talked to some authors. they're fine with the new unit, but also interested in having something that's exposed as a %, so they can apply it to the zoom property or text-size-adjust
19:07:45 <TabAtkins> dgrogan: so in last discussion, proposal in the issue is both.
19:07:54 <TabAtkins> dgrogan: env() would expose a scale factor
19:08:17 <TabAtkins> iank_: did we want a % or jsut a raw number?
19:08:36 <TabAtkins> TabAtkins: we'll want a raw number so it's more usable in calc()
19:08:42 <kizu> q+
19:08:47 <TabAtkins> dgrogan: yeah, and they can use calc() to turn it into a %
19:08:52 <astearns> ack kizu
19:09:20 <TabAtkins> kizu: if we have a separate value which is in px, given that in calc we can divide by 1px and get proportional, is that enough that we dont' need an extra unit value?
19:09:34 <TabAtkins> dgrogan: you can't do unit division in browsers today
19:09:40 <TabAtkins> kizu: you can in Safari, at least
19:09:50 <emilio> q+
19:09:51 <dbaron> (I think there's ongoing work to do it in Chrome, too.)
19:10:05 <TabAtkins> iank_: I think it's still easier on devs to have the value directly, rather than dividing by a magical number to produce the scale factor
19:10:19 <TabAtkins> iank_: It's more fragile than just exposing an env() that's 1.5
19:10:20 <astearns> ack emilio
19:10:47 <TabAtkins> emilio: Exposing a particular size is weird, because there might be different OS font sizes. the common denomatinor is some text scale factor that OSes have.
19:11:09 <TabAtkins> TabAtkins: proposal was a unit that gives you the size directly, and a scale factor
19:11:19 <TabAtkins> emilio: If the browser already applies a scale, doesn't using the uint double scale
19:11:42 <TabAtkins> emilio: on windows you have text-scale factor of 2. browsers interpret that as scaling the whole website, effectivley the device pixel ratio
19:11:56 <TabAtkins> emilio: if i give you a size that's 32px, that wouldn't be what you wanted, it's 4x size
19:12:05 <TabAtkins> iank_: looking at what windows actuallyd oes
19:12:13 <jensimmons> jensimmons has joined #css
19:12:25 <TabAtkins> iank_: i thought there was a factor that just scales text but not the whole thing?
19:12:44 <TabAtkins> emilio: we have a *pref* to do that but by default we all interpret the scale as a pixel scale
19:12:50 <florian> q+
19:13:00 <TabAtkins> iank_: at minimum we do seem to need the env(). we can optionally offer the unit.
19:13:02 <TabAtkins> q+
19:13:03 <astearns> ack florian
19:13:12 <TabAtkins> florian: i'm not sure that works, i think you need that *and* an opt out
19:13:25 <TabAtkins> florian: to say "dont' double the dpx of my site" so then the unit is useful
19:13:47 <TabAtkins> florian: otherwise you don't need to know the font size is doubled, becuase the 'medium' value is actually already correct
19:14:05 <TabAtkins> iank_: we do have an opt out on mobile, initial-scale-factor in mobile viewport
19:14:19 <TabAtkins> iank_: don't think we do it on Mac because settings are slightly different
19:14:32 <TabAtkins> iank_: maybe we just file a separate issue for a window opt out
19:14:43 <TabAtkins> emilio: i don't think mac has a global text scale
19:14:54 <TabAtkins> iank_: it does, but there's two toggles, one scales text the other is a global scale
19:15:16 <TabAtkins> iank_: you can probe this value on mobile, where people care a lot. it doens't matter quite as much on desktop, but not sure if people can probe for it
19:15:23 <TabAtkins> iank_: we'd hook that pref into this
19:15:35 <TabAtkins> iank_: we're not currnetly using that pref at all
19:15:58 <TabAtkins> iank_: so the question is do we need an opt out on windows and linux?
19:16:12 <TabAtkins> astearns: can we close off the discussion of this extra functionality?
19:16:27 <TabAtkins> emilio: but if we do this scaling, the scale factor for env() is always 1.
19:16:48 <astearns> ack TabAtkins
19:17:04 <emilio> TabAtkins: given this info, what is the issue actually about if it is the case that we already scale the page based on this factor
19:17:07 <emilio> iank_: we don't
19:17:10 <emilio> ... most of the time
19:17:12 <emilio> ... on mobile
19:17:27 <emilio> ... web devs, per browser, they try to find out the boosted text paragraph way
19:17:38 <emilio> ... on safari I think they probe the specific font thing
19:17:46 <emilio> ... they'd store the value and boost their text
19:17:47 <emilio> q+
19:17:57 <emilio> ... I don't necessarily want to boost the whole text
19:18:12 <emilio> TabAtkins: so the page is not fully scaled, but sometimes it is
19:18:23 <emilio> iank_: for us on android this toggle would do nothing
19:18:33 <emilio> ... it's very difficult
19:18:40 <emilio> ... so most sites disable the text auto-sizer
19:18:47 <emilio> ... they know how to boost and how much
19:19:03 <emilio> ... and they want this value and apply it fine-grained
19:19:14 <emilio> ... so this is why we want to expose this as an env()
19:19:20 <emilio> ... there's a good explanation on the thread
19:19:41 <emilio> TabAtkins: with the information that a lot of time fully scaling the page, but in the times we're fully scaling the page it'd be 1
19:20:10 <emilio> iank_: then there's the question of whether we want to have an opt out on windows
19:20:22 <florian> q+
19:20:22 <emilio> ... would need more research
19:20:27 <emilio> ... but that is a separate issue
19:20:36 <astearns> ack emilio
19:20:44 <TabAtkins> emilio: isn't the main issue that you do nothing with this on android?
19:21:01 <TabAtkins> iank_: boosting the page wholesale isn't usually what devs want
19:21:18 <TabAtkins> iank_: users want their text boosted, but not in a way that breaks the page
19:21:35 <argyle> q+
19:21:40 <TabAtkins> iank_: devs want to do the right thing a11y-wise, but boosting the whoel page or using our text auto-sizer heuristics aren't good
19:21:48 <TabAtkins> emilio: we do effectively zoom-to-page, changing the dpr
19:21:57 <TabAtkins> emilio: a lot of websites taht don't think about it actually get the right behavior
19:22:10 <TabAtkins> emilio: impossible to tell if they're on a high-dpr small screen or low-dpr big screen
19:22:25 <TabAtkins> iank_: yeah on desktop it's less of an issue since ther'es more real estate, but on mobile you want to be careful with limited space
19:22:37 <TabAtkins> emilio: yeah, don't want a mobile site with only half the nromal pixels
19:22:51 <TabAtkins> iank_: so this is why devs turn off text autosizing, but they do want to do the right thing for users
19:22:52 <florian> q- later
19:23:11 <TabAtkins> emilio: i haven't seen much bugs filed from our users against the full-page resizing, but i understand ti
19:23:19 <TabAtkins> emilio: even if we expose the scale factor i'd like some opt-in from the page
19:23:34 <TabAtkins> emilio: scaling the page when the web author hasn't put in any thought is generally better behavior
19:23:37 <TabAtkins> iank_: no
19:23:38 <TabAtkins> emilio: yes
19:23:41 <TabAtkins> iank_: no
19:23:44 <astearns> ack argyle
19:23:55 <TabAtkins> argyle: most common case for me is a chat app on a mobile device
19:24:07 <joshtumath> present+
19:24:09 <joshtumath> q+
19:24:18 <TabAtkins> argyle: you want the font-size boosted to max for readability, but not touch areas, or margin, or padding, etc
19:24:34 <TabAtkins> argyle: i see both young and old massively boosting their font size for chats, and i'd like my site to read as easily
19:24:35 <astearns> ack dbaron
19:24:37 <Zakim> dbaron, you wanted to comment on text autosizing
19:24:48 <TabAtkins> dbaron: there were refs to turning off text autosizing
19:25:00 <TabAtkins> dbaron: it exists int he first place to make pages designed for desktop sizes usable on mobile
19:25:29 <TabAtkins> dbaron: it exists in that context, ot basically say when you have a block of text, mobile user will want to pan in to read it, and you want to avoid them hving to then pan side to side to read it
19:25:47 <TabAtkins> dbaron: and that notion is tied to the system preference, which is why it can be used to detect the system pref sometimes
19:26:01 <TabAtkins> dbaron: but i don't think text autosizing is really designed for mobile-design cases
19:26:04 <TabAtkins> iank_: yup
19:26:04 <astearns> ack florian
19:26:22 <TabAtkins> florian: i think ideally what Adam is talking aobut should work ideally, but we're not in ideal world
19:26:28 <TabAtkins> florian: lot of sites would break if you just scale text
19:26:39 <TabAtkins> florian: web is in theory capable of doing this, but many sites not designed for it
19:26:50 <TabAtkins> florian: so maybe just don't do anything and expose the "good" scale factor
19:27:08 <TabAtkins> florian: when authors want to do the right thing i think giving that info is the right thing, but not all will think about it
19:27:32 <TabAtkins> iank_: yeah, on mobile zooming or not is a UA decision
19:27:54 <TabAtkins> florian: yeah, can decide to zoom to try and make the right choice for users by default.
19:28:10 <TabAtkins> iank_: yeah, there's way too many sites that'll, say, set an explicit height on something - you boost the text and it gets clipped
19:28:29 <TabAtkins> florian: so it seems that browsers can zoom sometimes, and if you want to do better you need to opt out.
19:28:47 <TabAtkins> florian: if you're opting out, maybe opt out of both zoom and text size, give an env() with the font sacle
19:29:00 <TabAtkins> florian: or might want to just opt out of zoom, but take the font scaling automatically
19:29:20 <TabAtkins> florian: so having a two way opt out which is (1) don't zoom the page, and (2) do or don't change the root font size, but tell me in an env()
19:29:29 <TabAtkins> florian: I think that's tehe complete solution
19:29:56 <TabAtkins> iank_: yes, i think we expose the environment variable, adn provide a meta viewport to opt into the zoom behaviors
19:30:31 <TabAtkins> florian: unsure why can't adjust the 'em' size by default...
19:30:49 <TabAtkins> iank_: so many people using libraries, not sure it's actually common to fully accommodate this
19:30:52 <astearns> ack joshtumath
19:31:01 <TabAtkins> joshtumath: just wanted to thank people for bringing this up
19:31:09 <TabAtkins> joshtumath: bringing this back to the original prompt
19:31:25 <TabAtkins> joshtumath: in BBC we have webviews and apps, there's no means of saying in the browser UI to adjust the font size
19:31:30 <TabAtkins> joshtumath: so authors have to do it
19:31:36 <TabAtkins> joshtumath: the meta viewport values would handle that
19:31:47 <TabAtkins> joshtumath: we want the ability to say "yes we've thought about it, scale the page", etc
19:32:02 <romain> romain has joined #css
19:32:03 <TabAtkins> joshtumath: want rems to scale by user font size, but not px, etc
19:32:43 <emilio> q+
19:32:49 <TabAtkins> astearns: do we resolve on the unit+env() now? or push back to the meta-viewport discussion?
19:32:54 <TabAtkins> astearns: i'm inclined to decide it now
19:33:08 <astearns> ack emilio
19:33:19 <TabAtkins> florian: yes, while there are cases where things are full zoomed (and scale factor would be 1) and others where it's not
19:33:26 <TabAtkins> emilio: i think i'm okay with the scale factor
19:33:33 <TabAtkins> emilio: adding the font unit seems like a lot of overhead
19:33:34 <TabAtkins> q+
19:33:53 <TabAtkins> emilio: seems like there are a lot of issues - setting being respected on browsers, in webviews...
19:34:10 <TabAtkins> emilio: i'm okay with exposing one scale factor, exposing a whole set of font units seems like a lot
19:34:12 <joshtumath> q+
19:34:17 <TabAtkins> iank_: our opinion is env() is needed, unit is nice to have
19:34:32 <TabAtkins> emilio: so i think doing jsut an env() for now and unit later
19:34:45 <astearns> ack TabAtkins
19:35:19 <emilio> TabAtkins: the big reason to supply one unit was brought up was to be able to use it in media query
19:35:43 <emilio> ... because that's intended to be a common case to use in media queries or what not
19:35:53 <dbaron> Is it like an em or like a rem?
19:36:12 <emilio> TabAtkins: one or another, I dunno
19:36:18 <astearns> ack joshtumath
19:36:22 <TabAtkins> dbaron: it's relevant question, ems are scaled again and again
19:36:23 <emilio> dbaron: relevant because one multiplies over and over
19:36:32 <TabAtkins> TabAtkins: sounds like a scaled rem then
19:36:39 <TabAtkins> joshtumath: yeah, ask is mostly for a rem
19:36:53 <emilio> q+
19:37:15 <TabAtkins> joshtumath: when trying to hotfix this with a proprietary apply font property, setting it on the root meant that MQs still didn't work right.
19:37:36 <TabAtkins> joshtumath: thus the need for the unit to always exist, not be dependen ton a property
19:37:45 <astearns> ack emilio
19:38:04 <TabAtkins> emilio: so a bit confused, do we really want a rem?
19:38:43 <TabAtkins> emilio: or just relative to the default font size? (not changed by the actual root font-size)
19:38:48 <TabAtkins> dbaron: I think the latter, yes
19:39:34 <fantasai> pem = preferred font size em
19:39:40 <joshtumath> +1
19:39:40 <TabAtkins> astearns: so let's have a proposed resolution to have the unit (a scaled default font size) and the env() (a scale factor)
19:39:54 <TabAtkins> RESOLVED:  have the unit (a scaled default font size) and the env() (a scale factor)
19:40:21 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11396
19:40:21 <github-bot> Topic: [css-display-4] Initial value of `reading-flow`
19:40:21 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11396.
19:41:14 <TabAtkins> rachelandrew: this bunch of issues... a lot rely on masonry
19:41:23 <TabAtkins> rachelandrew: we have an open PR for the html spec
19:41:40 <TabAtkins> rachelandrew: we're trying to get to whether these outstanding issues are liekly to change the html changes
19:41:46 <rachelandrew> https://github.com/w3c/csswg-drafts/issues/11328
19:42:08 <TabAtkins> rachelandrew: we might just resolve that it's probably not going to change the API shape
19:42:19 <TabAtkins> rachelandrew: for this first one, the initial value fo reading-flow
19:42:32 <TabAtkins> rachelandrew: in general "normal" means behaving as we do now, tab order follows the dom
19:42:54 <TabAtkins> rachelandrew: we ahve automatic layout methods, like grid-auto-flow dense that can fill in gaps, masonry can similarly have funky ordering
19:43:17 <TabAtkins> rachelandrew: with these, it kinda feels like we'd want to go with the visual ordering instead of source as a default
19:43:32 <TabAtkins> rachelandrew: so that's the question here - do we think that's a good idea?
19:43:46 <TabAtkins> rachelandrew: probably means with masonry we'd have a masonry-flow value for the property
19:44:07 <TabAtkins> rachelandrew: dense grid might cause some compat issue, but you probably already don't care abou thte osurce order since you dont' have much control over it
19:44:18 <TabAtkins> rachelandrew: and then we'd need a value to explicitly opt back into source ordering
19:44:21 <astearns> ack fantasai
19:44:48 <TabAtkins> fantasai: i think one of the key questions for html integration is, do we envision cases wher edefault ordering isn't he source order
19:45:04 <TabAtkins> fantasai: html spec is currently written with a binary change - if you do reordering, THIS happens, if not, THAT happens
19:45:15 <TabAtkins> fantasai: if the default behavior reorders, we can't go down the reordering path
19:45:42 <TabAtkins> fantasai: even if you don't actually change the order of anything, the behavior changes
19:46:10 <TabAtkins> rachelandrew: yes, it means if you didn't do any actual reordering you'd be in this slightly changed state
19:46:18 <TabAtkins> rachelandrew: but not sure why that makes a huge difference if it's initial or not
19:46:23 <hober> present+
19:46:29 <TabAtkins> fantasai: there's a scoping of tab navigation that happens if you're in the reordering version
19:46:35 <TabAtkins> fantasai: we can't just turn that on for everything all the time
19:46:59 <TabAtkins> rachelandrew: it's not all the time, the proposal is it only does visual order *for these intrinsically reordered display modes*
19:47:49 <TabAtkins> fantasai: okay, might make sense. right now HTML relies on initial value to know whethe ror not to do the thing; need to isntead rely on a CSS concept of if it *is* reordered.
19:48:14 <TabAtkins> (is being reordered, that is, whether the order actually chages or not)
19:48:29 <TabAtkins> fantasai: I think dense packing might be the trickiest case...
19:48:41 <TabAtkins> fantasai: if you have a collection that's dense packed, most of the time you dont' care about specific order
19:48:59 <TabAtkins> fantasai: but if you're doing a combo layout where parts are epxlicitly and the rest are dense packed, you might really care about where the explicit items are in reading order
19:49:13 <TabAtkins> fantasai: and want them in source order, but not care about the auto placed ones
19:49:23 <TabAtkins> rachelandrew: i think that's bleeding into the next issue
19:49:44 <TabAtkins> rachelandrew: whether we change the default behavior is a different issue
19:49:56 <TabAtkins> rachelandrew: we could decide dense grid has sailed and can't change the default, but that's still separate
19:50:24 <TabAtkins> fantasai: i think it interrelates somewhat. if we ahve a lot of those cases it's a compat issue.
19:50:53 <TabAtkins> fantasai: so like if the order matches the standard order, we treat it as not reordered. maybe that's less problematic
19:51:29 <TabAtkins> rachelandrew: I think we need to make sure this concept that HTML is relying on is defined in CSS, not just looking at the initial value
19:51:42 <TabAtkins> Di: I think that makes sense
19:52:17 <TabAtkins> Di: I think in HTML right now we're only caring about whether or not there is a reading-flow container, so this wouldn't change much on the html side
19:52:33 <TabAtkins> Di: on elika's question about order being the same between stadnard and reordered, cna't think of a way to do that
19:52:47 <TabAtkins> fantasai: i think it would be good to restrict the extra behavior to the parts that are reordered, fi there are any
19:53:04 <TabAtkins> fantasai: currently if you *might* be reordering things, you get it on all the places
19:53:06 <TabAtkins> (i disagree)
19:53:19 <TabAtkins> fantasai: might be better to instead only get the scoping changes on the parts that are reordered
19:53:20 <TabAtkins> q+
19:53:29 <emilio> TabAtkins: I disagree
19:53:42 <emilio> ... I don't think we want to have different behavior on elements in the same reading-flow container
19:53:47 <emilio> ... depending on whether has moved
19:54:18 <emilio> ... moved is confusing, if you swap #2 and #3, which one of them moved?
19:54:22 <emilio> fantasai: both
19:54:43 <fantasai> 1 2 3 4 5 vs 1 2 4 3 5 => 3 & 4 moved (don't match their original positions)
19:54:49 <emilio> TabAtkins: generally having the scoping be different in the same container, where the container is what controls it, seems off
19:55:16 <emilio> ... the specific case where there's a dense grid when some things are placed and others auto-placed
19:55:38 <emilio> ... seems like that could be achieved by having a default reading flow value for grid that achieves that
19:56:18 <TabAtkins> (3&4 being the moved elements is *not* obvious. It's exactly as possible that 3&5 are the ones that moved, just both moved *after* 4 and happened to maintain their releative order)
19:56:28 <TabAtkins> astearns: should we decide on just for masonry?
19:56:32 <TabAtkins> fantasai: that's not defined yet
19:56:40 <TabAtkins> astearns: we already have values that opt you into visual order.
19:56:55 <TabAtkins> astearns: if we dont' have an algo for that, we need that anyway, so we're not adding additional difficulty.
19:57:09 <TabAtkins> rachelandrew: there's a lot that falls out of this that needs to be decided on an individual layout basis
19:57:20 <TabAtkins> rachelandrew: q is jsut whether this is only a css issue, not an html, or both
19:58:08 <TabAtkins> rachelandrew: i think it's just css. html should only be considered with whether there is a reading flow container, regardless of whether that's from an initial value (+ othe rproperties) or an explicitly set reading-flow value
19:58:28 <TabAtkins> rachelandrew: so hopefully we can resolve on that part
19:59:14 <TabAtkins> TabAtkins: so proposed resolution: HTML should depend on teh *presence* of a reading flow container, regardless of how CSS defines that to come aobut
19:59:27 <florian> q+
19:59:31 <TabAtkins> q-
19:59:33 <florian> q-
19:59:46 <TabAtkins> astearns: objections?
20:00:05 <TabAtkins> RESOLVED: HTML should depend on the *presence* of a reading flow container, but defer to CSS about exactly what causes that.
20:00:22 <TabAtkins> github-bot, end topic
20:00:28 <TabAtkins> <br type=lunch dur=1hr>
20:17:08 <projecto-> projecto- has joined #css
20:17:38 <leaverou_> leaverou_ has joined #css
20:18:39 <Rossen-> Rossen- has joined #css
20:19:09 <shans_> shans_ has joined #css
20:19:39 <sylvaing_> sylvaing_ has joined #css
20:54:09 <t1m> t1m has joined #css
21:01:24 <ydaniv> ydaniv has joined #css
21:04:27 <kbabbitt> kbabbitt has joined #css
21:04:31 <alisonmaher> alisonmaher has joined #css
21:04:52 <kbabbitt> scribenick: kbabbitt
21:05:22 <ccameron> ccameron has joined #css
21:06:05 <ChrisL> ccameron https://github.com/w3c/csswg-drafts/issues/11616
21:06:08 <stepheckles> stepheckles has joined #css
21:06:17 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11533
21:06:17 <github-bot> Topic: [css-color-6] How to support color math involving more than one color?
21:06:17 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11533.
21:07:06 <kbabbitt> lea: a while back we resolved to adopt relative color syntax
21:07:07 <kbabbitt> ...
21:07:17 <kbabbitt> ... it's now in every browser, allows for math based on components of colors
21:07:25 <kbabbitt> ... use cases that involve more than one color keep cropping up
21:07:30 <Di> Di has joined #css
21:07:34 <hober> q+
21:07:39 <kbabbitt> ... e.g. mixing certain components from one color and other compionents from another
21:07:57 <kbabbitt> ... had an internal use case using components from one color and alpha from another
21:08:09 <kbabbitt> ... polyfilling other features can require components from multiple colors
21:08:22 <kbabbitt> ... e.g. two color operations like blending modes
21:08:32 <kbabbitt> ... it seems clear that there are use cases for this to be possible in some way
21:08:38 <kbabbitt> ... question is what's the best syntax
21:08:51 <kbabbitt> ... possibly extending color-mix but that could be a more complex syntax
21:08:56 <kbabbitt> ... not extensible to more than 2 colors
21:09:04 <kbabbitt> ... in another issue we resolved to add color-extract function
21:09:24 <kbabbitt> ... security and privacy implications so we might not see that anytime soon
21:09:36 <kbabbitt> ... it seems to me an extension on existing RCS is probably best way
21:09:38 <castastrophe> castastrophe has joined #css
21:09:45 <kbabbitt> ... but still how do we reference components of additional color?
21:09:54 <kbabbitt> ... could kick the ball down to authors and ask them
21:09:59 <kbabbitt> ... would prefer not to
21:10:06 <kbabbitt> ... if there's a user need we could do that later
21:10:14 <kbabbitt> ...ideally there should be default names like there are for first color
21:10:25 <kbabbitt> ... some might be comfortable with functional syntax eg. c(2)
21:10:32 <TabAtkins> q+
21:10:36 <kbabbitt> ... fantasai and I think there re too many parens already
21:10:38 <weinig> q+
21:10:47 <ChrisL> prefer c2 to c(2) or c-2
21:10:48 <kbabbitt> ... auto generating idents like c2 seems nicest way
21:10:57 <hober> q-
21:10:58 <kbabbitt> .... fine for initial vetsion to be limited in # of colors it supports
21:11:00 <emilio> q+
21:11:05 <kbabbitt> ... don't thinkm I've seen a quse case requiring more than 3
21:11:13 <kbabbitt> ... if impls want a pre defined max that's fine
21:11:26 <kbabbitt> ... other details like what if you're ref'ing an ident and you have fewer colors than that, proposals about that
21:11:34 <kbabbitt> ... can iron these out later if there's consensus on general direction
21:11:41 <astearns> ack TabAtkins
21:11:50 <kbabbitt> TabAtkins: agree with this and generally think lea's ideal case is right way to do it. +1
21:11:53 <astearns> ack weinig
21:12:14 <kbabbitt> weinig: one thing I couldn't quite understand: if you want to use channels from 2 different color spaces, would RCS support that?
21:12:21 <lea> qq+
21:12:22 <kbabbitt> ... usually RCS extracts channels in single color space
21:12:28 <kbabbitt> ... would we need to augment to define extraction?
21:12:36 <kizu> q+
21:12:37 <kbabbitt> lea: yes you can nest RCS, each time you convert to color space
21:12:56 <kbabbitt> weinig: so if you want lightness to multiply every rgb channel, extract lightness and thne put it in every channel?
21:13:01 <kbabbitt> lea: each op is done in one color space
21:13:16 <kbabbitt> ... base color can be a relative color
21:13:25 <andreubotella> andreubotella has joined #css
21:13:25 <kbabbitt> weinig: say you have a color you want its lightess from
21:13:38 <kbabbitt> ... and want to multiply every channel of an rgb color by that value
21:13:48 <kbabbitt> .... to brighten its intensity
21:13:55 <kbabbitt> lea: why not operate on lightness itself?
21:13:58 <kbabbitt> weinig: that's fair
21:14:12 <kbabbitt> lea: we can revisit color-extract later which would allow that
21:14:18 <kbabbitt> ... not sure there's enough cases but could revisit
21:14:23 <kbabbitt> weinig: your argument is strong
21:14:42 <ChrisL> In general, doing math on gamma-encoded rgb channel values is almost never useful
21:14:44 <kbabbitt> ... also: are there other areas of CSS where extracting parts of it and using those would be useful?
21:14:51 <kbabbitt> ... so that instead of color-extract we have a more generic form
21:14:56 <kbabbitt> ... to avoid color-mix to mix thing
21:15:07 <kbabbitt> ... if we were to go the extract route are there other potential use cases?
21:15:17 <nicole> nicole has joined #css
21:15:19 <kbabbitt> lea: good question, can't think of any offhand
21:15:36 <kbabbitt> weinig: don't see any downside to adding support for multiple colors
21:15:41 <kbabbitt> ... could do other things if we want
21:15:50 <astearns> ack lea
21:15:50 <Zakim> lea, you wanted to react to weinig
21:15:55 <astearns> ack emilio
21:16:01 <kbabbitt> emilio: my question was similar to weinig's
21:16:09 <kbabbitt> ...what color space is used if you have multiple
21:16:24 <kbabbitt> ...would you get components of each color in its own color space, and ... target?
21:16:31 <kbabbitt> lea: this is already defined for RCS
21:16:38 <kbabbitt> ... color converted to color space you're working in
21:16:50 <kbabbitt> emilio: color space doesn't depend on input, depends on function being used
21:16:52 <kbabbitt> lea: precisely
21:16:57 <kbabbitt> ... that's how RCS works already
21:17:04 <astearns> ack kizu
21:17:09 <kbabbitt> kizu: we need something like this
21:17:21 <kbabbitt> ...while we still want to have this in situ way of doing things
21:17:28 <kbabbitt> ... might also want color-extract
21:17:44 <kbabbitt> ... cases where it's difficult to do this in one function
21:17:55 <kbabbitt> lea: you can use CSS variables
21:18:04 <kbabbitt> kizu: can you assing custom prop with color component and then reuse?
21:18:14 <kbabbitt> lea: yes, doesn't resolve until used but could use custom prop for calculations
21:18:24 <kbabbitt> kizu: if you are not registering them you could do this
21:18:32 <kbabbitt> ... if we are a fan of color-extract for security reasons
21:18:44 <kbabbitt> ...one solution might be to do it only in custom functions that return a color
21:18:45 <lea> e.g. `--lighter: calc(l * 1.2); color: oklch(from var(--color) var(--lighter) c h);` works fine
21:18:51 <kbabbitt> s/are/aren't/
21:19:05 <kbabbitt> [crosstalk]
21:19:12 <weinig> q+
21:19:15 <kschmi> kschmi has joined #css
21:19:21 <astearns> ack weinig
21:19:29 <kbabbitt> weinig: what are the security/privacy concerns with extract color?
21:19:43 <kbabbitt> lea: right now you could paint certaing colors on a canvas and read them but...
21:19:51 <kbabbitt> weinig: could use gCS to read serialization
21:20:00 <kbabbitt> lea: this adds vector to CSS itself
21:20:04 <kbabbitt> ...instead of needing JS
21:20:13 <kbabbitt> ... minor point but could imagine people raising concerns
21:20:28 <kbabbitt> ... e.g. previous meeting accent-color had concerns
21:20:32 <lea> or even `--lighter: calc(l * 1.2) calc(c * 1.05); color: oklch(from var(--color) var(--lighter) h);`
21:20:34 <kbabbitt> weinig: they have to be resolved for gCS anyway
21:20:43 <kbabbitt> ... if we allow that, you can always find out channels yourself
21:20:45 <kbabbitt> lea: fair enough
21:21:02 <kbabbitt> ... fwiw even if we decide that extract-color is useful, in many cases it would be verbose, this is simpler
21:21:15 <kbabbitt> weinig: not objecting just wanted to know what security and privacy concerns were
21:21:24 <kbabbitt> astearns: shall we resolve on adding this to spec>
21:21:33 <kbabbitt> weinig: I feel we need more debate on syntax for getting components
21:21:50 <kbabbitt> ... or maybe a little more thought on if this concept of indexing into an array is something we're creating here
21:21:59 <kbabbitt> ...probably not the last time CSS will need indexing into an array of objects
21:22:06 <kbabbitt> ... coming up with a syntax we're OK with in future is useful
21:22:19 <kbabbitt> astearns: could have this proposal in spec with an issue sayting we need to think about component extraction
21:22:21 <kbabbitt> weinig: ok
21:22:35 <kbabbitt> astearns: Proposed: Yes to this issue, let's get it in a spec and start work on it
21:22:37 <ChrisL> +1
21:22:50 <kbabbitt> RESOLVED: Yes to this issue, let's get it in a spec and start work on it
21:23:10 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11534
21:23:10 <github-bot> Topic: `contrast-color()` MVP should support explicit light/dark colors rather than unspecified "very light/dark colors"
21:23:10 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11534.
21:23:41 <kbabbitt> lea: a while back we resolved to adopt an MVP for contrast-color
21:23:42 <hober> q+
21:23:49 <kbabbitt> ...that returned very light and very dark color, up to UA what they would be
21:23:58 <kbabbitt> ... and max version that returned white and black
21:24:11 <kbabbitt> .. after working with designers more, I've seen they don't want arbtirary dark or light color
21:24:15 <kbabbitt> ... they want specific tokens
21:24:24 <kbabbitt> ... use this dark text color, not some arbitrary decided by browser coor
21:24:35 <kbabbitt> ... in theory they could use max, get white and black, and transform it
21:24:44 <kbabbitt> ... but it seems like an easy win if you could specify your light and dark versions
21:24:51 <kbabbitt> ... ideally start with just providing dark one
21:25:00 <kbabbitt> ... usually white is OK as text color but black isn't
21:25:12 <kbabbitt> ... if you provide colors you can end up in situations with insufficient contrast
21:25:15 <kbabbitt> ... but you can do that already
21:25:21 <kbabbitt> ... so that doesn't make things worse
21:25:39 <kbabbitt> ... it's in Safari but not implemented widely
21:25:56 <kbabbitt> ... I would suggest a syntax that takes args for light and dark color, drop max, and if you don't provide args you get max behavior
21:26:03 <kbabbitt> ... 1 arg is dark color with white as light color
21:26:06 <kbabbitt> ... 2 args use those
21:26:11 <kbabbitt> ... maybe UA can figure out which is which
21:26:16 <kbabbitt> ... or we can be ordered
21:26:24 <kbabbitt> ... pretty small syntax extension
21:26:44 <kbabbitt> hober: really interesting problem, we had ? to talk through it internally
21:26:54 <kbabbitt> ... it's intersting because it turns out contrast-color is something lots of people want
21:27:00 <kbabbitt> ... for different reasons with different constraints
21:27:15 <kbabbitt> ... after we whiteboarded it, we felt best way would be separate CSS functions for different use cases
21:27:19 <kbabbitt> ... filed a new issue to suggest that
21:27:31 <kbabbitt> ... space of desired behaviors & why we think they should be separate functions
21:27:35 <kbabbitt> ... 2 proposals we kicked around
21:27:49 <kbabbitt> ... one is maintainer of small/medium website who realizes that previous designer didn't use sufficient contrast
21:27:59 <astearns> https://github.com/w3c/csswg-drafts/issues/11619
21:28:01 <kbabbitt> ... trying to bring website into modern world but don't have time to redesign it
21:28:12 <kbabbitt> ... make smallest change they can that gives sufficient contrast
21:28:24 <kbabbitt> ... other is designer at a company with well thought out brainding identity
21:28:30 <kbabbitt> ...who really needs colors from a specific set
21:28:33 <kbabbitt> ... use cases all over the place
21:28:40 <kbabbitt> ... given this color, compute a contrasting color
21:28:52 <kbabbitt> ... but ambiguous because color could be used for foreground, background, borders, etc.
21:29:01 <kbabbitt> ... that's teh case we want contrast-color for
21:29:08 <kbabbitt> .. other case, given a starting color and set of colors
21:29:14 <kbabbitt> ... get the color from the set that contrasts most
21:29:23 <kbabbitt> ... guaranteed color you get out is one of the ones you put in
21:29:39 <kbabbitt> ... this also has variations because you might have different thresholds for borders etc
21:29:50 <kbabbitt> ... then there's a case where you have a pair of colors for fg and bg
21:29:52 <lea> q?
21:29:54 <lea> q+
21:29:56 <kbabbitt> ... ask engine, make minimum tweaks to these
21:30:11 <kbabbitt> ... one other that james craig though tof, put text on bg image
21:30:20 <kbabbitt> ... who knows colors of bg image, but you want a color that contrasts sufficiently
21:30:27 <TabAtkins> lea's proposal is more limited than "here's a list, pick the best" - instead you first determine whether white or black would be better, then let authors supply a replacement for white/balck
21:30:29 <kbabbitt> ... all of these are interesting and probably need different functions
21:30:39 <kbabbitt> ... disinclined to make color-contrast more complicated to do all these things
21:30:40 <TabAtkins> q+
21:30:45 <kbabbitt> ... but do want to do all of these things
21:30:51 <kbabbitt> ... using separate functions
21:30:52 <astearns> ack lea
21:30:55 <hober> https://github.com/w3c/csswg-drafts/issues/11619
21:30:56 <astearns> ack hober
21:31:09 <kbabbitt> lea: when we resolved to do contrast-color it was because there was all this complex design space & use cases
21:31:16 <kbabbitt> ... no good algorithm we could use right now
21:31:23 <kbabbitt> ... [gives examples]
21:31:28 <kbabbitt> ... so we resolved to leave it up to UA
21:31:35 <kbabbitt> ... address most common case which is light + dark color
21:31:36 <argyle> 17 use cases outline in my proposal from a couple years ago https://observablehq.com/@argyleink/contrast-color, sharing here to be added to the considerations
21:31:53 <kbabbitt> ... these use cases exist but a lot of this is going back to debates where we got gridlock because it was such a big problem we couldn't move forwards
21:32:06 <kbabbitt> ....we resolved to have this version because it addresses 80% of use cases without complexity
21:32:12 <kbabbitt> ... looking to keep that
21:32:23 <kbabbitt> ... maybe we'll solve others with same fn, maybe with different fns
21:32:31 <kbabbitt> ... it's a matter of syntax
21:32:37 <kbabbitt> ... poit of this proposal is to solve common case
21:32:40 <florian> q+
21:32:49 <kbabbitt> ... don't think others are something we need to solve right now
21:32:55 <kbabbitt> ... proposing a simple tweak over what we have right now
21:33:01 <kbabbitt> ... supplying optional replacements for white & black
21:33:05 <argyle> q+
21:33:10 <kbabbitt> ... it's not responsible for maintaining contrast ratios for you
21:33:18 <kbabbitt> ... if previous proposal could be implemented easily this could be too
21:33:27 <kbabbitt> ... hober's points are valid but lots of design work involved
21:33:40 <astearns> ack TabAtkins
21:33:43 <kbabbitt> TabAtkins: agree with lea
21:33:52 <kbabbitt> ... trying to avoid reopening big design discussions
21:33:58 <kbabbitt> ... this is a minimal edit to what WG decided on
21:34:08 <kbabbitt> ... to address lea's concerns without opening new problesm
21:34:20 <kbabbitt> ... I think we should accept this change, bikeshed syntax later
21:34:22 <astearns> ack florian
21:34:27 <kbabbitt> florian: worried this is a footgun
21:34:41 <kbabbitt> ... yes if the color you get is actual black or white
21:34:48 <kbabbitt> ... even if contrast function isn't perfect it will be good enough
21:34:50 <lea> q?
21:34:54 <kbabbitt> ...but here you allow user to supply something else
21:34:55 <lea> q+
21:35:03 <kbabbitt> ... sometimes they'll be surprised what's picked because contrast won't be good
21:35:15 <kbabbitt> ... sometimes what we have makes bad decisions but you know it's black or white
21:35:16 <hober> qq+ to riff on florian's footgun
21:35:34 <kbabbitt> ... if you're almost entirely black maybe not but depending on how far off you are, sometimes it will give you the wrong one between the two
21:35:40 <astearns> ack hober
21:35:40 <Zakim> hober, you wanted to react to florian to riff on florian's footgun
21:35:45 <kbabbitt> hober: thats exactly my worry
21:35:55 <kbabbitt> ... if we had a separate fn that solved, given set of colors give me one that contrasts
21:36:02 <kbabbitt> ... that would be a simple change of syntax that would address that
21:36:13 <TabAtkins> q+ to respond to tess
21:36:15 <kbabbitt> ... while it's still a footgun, if you always have one color and it returns that regardless of contrast
21:36:25 <kbabbitt> ... that's less of one because you're providing a set of colors
21:36:35 <kbabbitt> ... this is areduced version of that where you're only providing 1 or 2
21:36:41 <kbabbitt> ... this is a guess because all we have to go on is intuition
21:36:45 <florian> q?
21:36:51 <kbabbitt> ... but I think authors are less likely to screw up in that case
21:37:02 <kbabbitt> ... this isn't as good as a separte function but think we should try to solve the problem
21:37:07 <astearns> ack argyle
21:37:24 <kbabbitt> argyle: lea mentioned... I don't know any designers okay with partial color choice that didn't come from their palette
21:37:30 <kbabbitt> ... most people I've talked to is the opposite
21:37:36 <kbabbitt> ... they open palette and lcick around the pool
21:37:55 <kbabbitt> ... if you have a set and want to pick from it, good feature, but not all designers explicitly want it
21:38:04 <kbabbitt> ... we leave tasks up to browser a lot, sometimes it's not the right answer
21:38:12 <kbabbitt> .... contrast prefs of user should be taken into account
21:38:19 <kbabbitt> ... in high contrast mode this fn should return something relevant
21:38:33 <kbabbitt> ... I've tried all algos, we should punt on forcing one
21:38:49 <kbabbitt> ... we shouldn't be waiting for better algo
21:38:59 <kbabbitt> ... enhancing what we have is good, white black or from a list
21:39:04 <florian> q+
21:39:09 <kbabbitt> .... bad contrast is one of biggest a11y problems on web
21:39:10 <astearns> ack lea
21:39:20 <kbabbitt> lea: agree with argyle on taking HC into account
21:39:36 <kbabbitt> ... re: footgun - I think people are comparing to ideal fn which we don't know how tyo build
21:39:36 <weinig> q+
21:39:44 <kbabbitt> ... but without this, designers are specifying these manually
21:39:47 <astearns> zakim, close queue
21:39:47 <Zakim> ok, astearns, the speaker queue is closed
21:39:53 <kbabbitt> ... we can be absolved of responsibility, they picked it
21:40:07 <kbabbitt> ... re: having UA pick, there's not enough info in a tint to give you other tints of that color
21:40:15 <kbabbitt> ... varying lightness is not sufficient in any color space
21:40:18 <kbabbitt> ... even oklch
21:40:24 <kbabbitt> ... still have to vary chroma to get tints
21:40:33 <kbabbitt> ... if starting from a light color you can't derive darker variants
21:40:36 <kbabbitt> ...without having accent color
21:40:38 <kbabbitt> ...missing information
21:40:43 <nicole> q+
21:40:44 <kbabbitt> ...I don't think UA can come up with a good color
21:40:52 <kbabbitt> ...not a terrible result to get black & white if nothing provided
21:41:08 <kbabbitt> ... I think for the people picking madly around a color picker, they can deal with black & white
21:41:16 <kbabbitt> ... I don't think UA generating dark color would help them very much
21:41:18 <astearns> ack TabAtkins
21:41:18 <Zakim> TabAtkins, you wanted to respond to tess
21:41:24 <fantasai> scribe+
21:41:43 <fantasai> TabAtkins: Responding to Tess, the big thing that blocked us last time was the idea of having a function that could pick from a list of colors *because* we know our current contrast algo sucks
21:42:07 <kbabbitt> TabAtkins: our existing algo sucked and we didn't have a good replacement
21:42:16 <kbabbitt> ... that's why we subsetted down to 2 color case
21:42:23 <kbabbitt> ... white and black can go a little wrong but hard to go very wrong
21:42:32 <kbabbitt> ... going back on that will reopen every problem we had before deadlock was resolved
21:42:44 <kbabbitt> ...it is possible to footgun by supplying dark color instead of black
21:42:50 <kbabbitt> ... don't do that, we'll tell them not to do it in spec
21:42:50 <argyle> just sharing this again, as this lets you see returned colors from any contrast algo, from a list, or max white/black OR it can discover a color. all of these options we're sharing here are in this demo, and you can see how totally decent the results are https://observablehq.com/@argyleink/contrast-color
21:42:59 <kbabbitt> ... can supply own colors, they should be very dark very light
21:43:12 <kbabbitt> ... still gets us to a defensible spot even if we're stuck with ? as contrast algo
21:43:17 <kbabbitt> s/?/WCAG2/
21:43:23 <astearns> ack florian
21:43:33 <kbabbitt> florian: building on TabAtkins and lea were saying
21:43:45 <kbabbitt> ...thinkinh of it as a footgun compared to doing it manually
21:43:52 <kbabbitt> ... problem case is a light on dark theme where dark isn't very dark
21:44:01 <kbabbitt> ... and you ask for contrast between middle color and give me black or white
21:44:04 <kbabbitt> ... and get kind of gray
21:44:10 <kbabbitt> ... to contrast on kind of gray
21:44:20 <kbabbitt> ... and this fn which is supposed to give you good contrast, doesn't
21:44:33 <kbabbitt> ... on one hand, don't do this, on the other hand this is the fn that ghives me contrasty
21:44:41 <kbabbitt> ... so the only thing I can put in there is gray
21:44:47 <kbabbitt> lea: isn't that a problem with current version?
21:44:53 <kbabbitt> florian: no because it returns black
21:44:56 <kbabbitt> ... it won't return middle gray
21:45:02 <kbabbitt> ... if you can't use black, you won't use function
21:45:11 <kbabbitt> ... you won't supply it middle gray, you won't use it at all
21:45:12 <astearns> ack weinig
21:45:13 <fantasai> +1
21:45:26 <kbabbitt> weinig: second time I've impled this function, shipped it behind a flag
21:45:28 <TabAtkins> as lea pointed out earlier, you can *turn* white/black into chosen colors via RCS, fwiw
21:45:54 <fantasai> that's more explicit though. The author won't think they're getting an actual contrast computation
21:45:55 <kbabbitt> ... how do we get to the point where this is good enough and get user feedbacl?
21:46:06 <kbabbitt> ... can we resolve on this version and try it out, see feedback
21:46:08 <lea> If we can't reach consensus on this, I wonder if we can just drop `max` (and do white/black by default) so that we can extend the function later with something like this
21:46:13 <fantasai> +1 lea
21:46:16 <kbabbitt> ... seems unnecessary to keep iterating if it's contentious
21:46:24 <kbabbitt> astearns: not hearing consensus for any particular resolution
21:46:29 <kbabbitt> ... let's take back to issue
21:46:38 <kbabbitt> ... we may decide to extend as lea suggests
21:46:44 <kbabbitt> ...  might need different version
21:47:10 <kizu> kizu has joined #css
21:47:16 <miriam> +1
21:47:17 <lea> (fwiw I think that's a better design *anyway*)
21:47:18 <TabAtkins> i'm fine with that
21:47:19 <kbabbitt> Proposed: drop `max`, do white/black by default and allow extension points later
21:47:19 <kizu> +1
21:47:26 <fantasai> +1
21:47:32 <lea> 🎉
21:47:42 <kbabbitt> RESOLVED: drop `max`, do white/black by default and allow extension points later
21:47:44 <argyle> +1 that's how my proposal works in that observable
21:48:15 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11532
21:48:15 <github-bot> Topic: [css-color-5] Make interpolation method optional in `color-mix()`?
21:48:15 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11532.
21:48:44 <kbabbitt> lea: a while back we resolved to have mandatory interpolation color space in color-mix()
21:48:58 <kbabbitt> ... because we worried ,what if a better color space comes along?
21:49:03 <kbabbitt> ... for interpolation
21:49:10 <kbabbitt> ... reality is that this has become noise in the fn
21:49:12 <ChrisL> q+
21:49:17 <kbabbitt> ... authors do not make informed decisions we expected
21:49:23 <astearns> zakim, open queue
21:49:23 <Zakim> ok, astearns, the speaker queue is open
21:49:32 <kbabbitt> ... they specify srgb not because they want to interpolate there but htat's the color space they're familiar with
21:49:37 <astearns> q+ ChrisL
21:49:40 <weinig> q+
21:49:41 <kbabbitt> ... or they think they have to because colors are srgb
21:49:46 <kbabbitt> ... we can make a more informed choice for this default
21:49:57 <kbabbitt> ... even if there's a better default later, this is better than what authors are currently doing
21:50:05 <kbabbitt> ... we also resolved lab should be default for gradients
21:50:15 <kbabbitt> ... we do have in gradients you don't have to specify interpolation space
21:50:19 <kbabbitt> ... so this would harmonize
21:50:35 <kbabbitt> ... I was in favor of not having a default, I think it would be a net gain to have a default now
21:50:37 <emilio> q+
21:50:43 <emilio> ack ChrisL
21:50:43 <astearns> ack ChrisL
21:50:50 <kbabbitt> weinig: I wanted us not to have a default
21:50:53 <astearns> ack weinig
21:50:55 <kbabbitt> ... I still think it's the right choice
21:51:05 <kbabbitt> ... in general I think the places where we've not been explicit about color spaces
21:51:09 <kbabbitt> ... have by and large been a mistake
21:51:12 <kbabbitt> ... and hard to claw back
21:51:29 <kbabbitt> ... if we live in a world where there are color spaces and people writing code for our platforms, they need to be aware of them
21:51:32 <lea> q+
21:51:35 <kbabbitt> ... I don't think hiding them has been an effective strategy
21:51:36 <ChrisL> qq+
21:51:42 <kbabbitt> ... in the engines, or the APIs we produce
21:51:53 <kbabbitt> ... people using srgb as default feels like educational problem which is solvable
21:51:59 <kbabbitt> ... not necessarily reason to force different default
21:52:01 <astearns> ack ChrisL
21:52:01 <Zakim> ChrisL, you wanted to react to weinig
21:52:08 <kbabbitt> ChrisL: you've exactly captured my viewpoint from 6 months ago
21:52:18 <kbabbitt> ... we give them that, they make good choices, they make terrible choices
21:52:31 <kbabbitt> weinig; I don't think people will make good choices to begin with, they make bad choices all the time
21:52:49 <kbabbitt> ... but I think in the expanse of time as more articles come out and more people come to understand what these concepts mean
21:52:52 <kbabbitt> ... that is a net positive
21:53:02 <kbabbitt> ... giving people the runway to learn these concepts is useful
21:53:12 <kbabbitt> ... slipping them under covers is useful in short term but not long term
21:53:15 <ChrisL> q?
21:53:17 <astearns> ack emilio
21:53:22 <kbabbitt> emilio: 2 questions
21:53:38 <kbabbitt> ... presumably if you mix with transparent the result is what you expect regardless of color space
21:53:42 <kbabbitt> ... or are there weird things there/
21:53:47 <florian> q+
21:53:49 <kbabbitt> ... I want to make this color semi transparent
21:53:59 <kbabbitt> weinig: if all you do is augment alpha that's same for all color spaces
21:54:03 <kbabbitt> emilio: right
21:54:11 <kbabbitt> ... does result color space depend on interpolation method?
21:54:21 <kbabbitt> weinig: there's not a concept of result color space
21:54:28 <kbabbitt> ... colors are colors and how you use them enforces color space
21:54:33 <kbabbitt> emilio: but you need to serialize ...
21:54:43 <kbabbitt> weinig: it serializes as what you mixed as i.e. output
21:54:52 <kbabbitt> ... in this proposal, output of color-mix will be by default oklab()
21:54:55 <kbabbitt> emilio: could be surprising
21:55:05 <kbabbitt> ... you omit color space, mix red + transparent and get some oklch value
21:55:10 <kbabbitt> ... have mixed feelings about this
21:55:26 <kbabbitt> ... if colors wouldn't be read so much from script I'd be happy to do this
21:55:30 <kbabbitt> ... maybe it's fine anyway
21:55:36 <kbabbitt> ... and people will ditch their old script
21:55:51 <kbabbitt> ... it's common to mix srgb colors, call gCS, and parse an rgba value
21:55:56 <kbabbitt> ... which would no longer work
21:56:07 <kbabbitt> weinig: it would already no longer work because modern syntax
21:56:09 <lea> q?
21:56:16 <kbabbitt> emilio: I think you get legacy syntax given legacy input
21:56:22 <astearns> ack fantasai
21:56:22 <Zakim> fantasai, you wanted to ask stupid question about color-interpolation property
21:56:23 <kbabbitt> ... not objecting, just curious about surprising behaviors
21:56:49 <kbabbitt> fantasai: why dont we make color interpolation methods optional
21:56:56 <kbabbitt> ... and have color-interpolation properthy that sets default?
21:57:10 <ChrisL> you don't get the result in a legacy colorspace, see https://drafts.csswg.org/css-color-5/#serial-color-mix
21:57:17 <kbabbitt> lea: even if down the line a better color space comes along
21:57:29 <kbabbitt> .. I think it would be good to give authors a way to set default color interpoliation space
21:57:35 <kbabbitt> ... not as simple as providing a property
21:57:45 <kbabbitt> ... because different use cases need different interpolation spaces
21:57:49 <kbabbitt> ... but I think that's right direction
21:58:01 <kbabbitt> ... also there was a concern we shouldn't try to protect authors from bad choices
21:58:16 <kbabbitt> ... ironic because we were worried in color-contrast about protecting authors from bad choices
21:58:26 <kbabbitt> ... in general I think we give sensible defaults to reduce author cognitive overhead
21:58:28 <fantasai> lea+++++++++
21:58:40 <kbabbitt> ... e.g. layout has many smart defaults so people don't ahve to understand grid intricacies
21:58:47 <kbabbitt> ... taht's why sensible defaults are a design principle
21:59:09 <kbabbitt> ... re: emilio - good point, it might be unexpected if authors did not define color space, to get oklab after specifying srgb
21:59:18 <kbabbitt> ... interpolation color space and result color space do not beed to be the same
21:59:22 <fantasai> ChrisL, why is that a problem? you opted into it
21:59:28 <kbabbitt> .. coud define color returned in color space of first arghument
21:59:36 <kbabbitt> ... we can do these things, but it's a separate decision\
21:59:41 <kbabbitt> ... e.g. what color space result is in
21:59:47 <kbabbitt> ... interpolation can still be in oklab
21:59:47 <ChrisL> qq+
21:59:54 <astearns> ack ChrisL
21:59:54 <Zakim> ChrisL, you wanted to react to fantasai
21:59:56 <astearns> ack lea
22:00:06 <kbabbitt> ChrisL: emilio - the thing you said was wrong, quoted spec
22:00:13 <kbabbitt> ... [missed]
22:00:28 <kbabbitt> emilio: if you do color-mix in oklab, red 50%, blue
22:00:31 <kbabbitt> ... you get an oklab color
22:00:41 <kbabbitt> ... that's expected since you mix in okalb
22:00:42 <lea> s/... [missed]/lea: but in color-mix() without an interpolation space, it's implicit/
22:00:49 <kbabbitt> ... but if you omit and do color mix red blue
22:00:55 <kbabbitt> ... it might be unexpected to get back oklab
22:01:05 <kbabbitt> ... if the color space was dependent on inputs this wouldn't be an issue
22:01:09 <astearns> ack florian
22:01:20 <kbabbitt> florian: agree with lea that we should separate question of serialization and interpolation color space
22:01:26 <kbabbitt> ... they don't have to be the same
22:01:36 <kbabbitt> ... we can have separate rules for serialization
22:01:46 <kbabbitt> ... if we don't want to be silent on main point because authors should think about this
22:01:50 <kbabbitt> ... and it's a point of education
22:01:53 <lea> We could even specify that before 50% you use the color space of the first color and >= 50% the color space of the second color :P
22:02:02 <kbabbitt> ... but also want to allow authors to not worry about it
22:02:02 <fantasai> :P
22:02:07 <kbabbitt> ... could give them an auto keyword
22:02:14 <kbabbitt> ... which is more inviting when you don't want to do than oklab
22:02:35 <kbabbitt> ... possibly we don't want to do that either and instead have separate value
22:02:43 <kbabbitt> ... but auto might be more discoverable
22:03:02 <kbabbitt> astearns: re: auto value - it would only make sense to add auto if there were different defaults to be used in various circumstances
22:03:15 <kbabbitt> ... if there's a single thing we're going to use in auto case, makes more sense to express it as omittable parameter
22:03:17 <kbabbitt> q+
22:03:20 <emilio> q+
22:03:25 <astearns> ack kbabbitt
22:03:33 <TabAtkins> kbabbitt: one thing just occurred to me about auto value
22:03:44 <TabAtkins> kbabbitt: if in the future we discover a color space we want to use isntead, authors dont' have to change their code
22:03:51 <TabAtkins> kbabbitt: tho i suppose that's true with the omitted vlaue too
22:03:53 <astearns> ack emilio
22:04:07 <kbabbitt> emilio: another q is, if we do this, do we want to serialize color-mix itself
22:04:18 <kbabbitt> ... if you specify color mix in oklab that may be what happens in gradients now
22:04:29 <lea> q+
22:04:33 <kbabbitt> ... do we make omission special or do we change color-mix in oklab to omit oklab as well
22:04:38 <astearns> ack lea
22:04:49 <kbabbitt> lea: I think it should be special so that down the line when we have a separate property that gets automatically applied
22:04:58 <kbabbitt> ... otherwise when they read value back they start relying on it
22:04:59 <fantasai> +1
22:05:03 <kbabbitt> ... and it's harder to change down the line
22:05:10 <kbabbitt> emilio: that's an issue regardless
22:05:18 <kbabbitt> ... if result is in oklab then you know what you used manually
22:05:19 <lea> q+ to say roundtripping
22:05:22 <kbabbitt> fantasai: [missed]
22:05:42 <kbabbitt> emilio: I don't think that makes it harder to change it, harder to rely on oklab by default
22:05:52 <kbabbitt> lea: another reason not to include color space is roundtripping
22:06:02 <kbabbitt> ... it should be easy to read value and plug back in without chaning what you have
22:06:09 <weinig> q+
22:06:10 <kbabbitt> ... once interpolation space becomes independent it becomes coupled in the value
22:06:13 <astearns> ack lea
22:06:13 <Zakim> lea, you wanted to say roundtripping
22:06:17 <kbabbitt> ... if you read it and write it back you override what was in value
22:06:28 <kbabbitt> emilio: what we would do now if we say oklab is defauklt
22:06:34 <kbabbitt> ... if you specify oklab we'd omit it
22:06:43 <kbabbitt> lea: if someone explicitly spercifies it htat's author intent
22:06:46 <kbabbitt> ... we should not just drop it
22:06:55 <kbabbitt> weinig: we would by current serialization rules
22:07:12 <kbabbitt> emilio: I don't mind either way but I think TabAtkins had strong opinions about having special values by omiision
22:07:21 <kbabbitt> ... maybe we should ahve a keyword for this even if we omit by default
22:07:30 <kbabbitt> ... don't think dropping in oklab as long as it's a default is aproblem
22:07:38 <kbabbitt> ...doesn't make it hard ot change down the line
22:07:44 <astearns> ack weinig
22:07:59 <kbabbitt> weinig: in terms of taking this idea that at some point in future we might define interpolation space property
22:08:06 <kbabbitt> ... I think that's a good reason to put this on hold until then
22:08:18 <kbabbitt> ... because if we want to do something where color mix takes on the inherited color interpolation space
22:08:18 <lea> q+
22:08:27 <TabAtkins> especially in a case like this, where the keyword is preceded by anotehr keyword, it's important to have every value explicitly writeable. Otherwise you can't write `color-mix(in var(--color-space), ...)` and have all options available
22:08:27 <kbabbitt> ... that would be just as surprising to other people
22:08:38 <kbabbitt> ... that suddenly color mixes that set interpolation space are suddenly changed
22:08:48 <kbabbitt> ... if we are going to change it and change defaults, or remove/add efaults
22:08:57 <kbabbitt> ... doing them together as a unified piece would make sense
22:08:59 <TabAtkins> (you'd have to instead write `color-mix(var(--color-space))`, and write `--color-space: in oklab`, which is awkward)
22:09:05 <kbabbitt> ... still don't think having a default here is necessaty
22:09:13 <astearns> ack lea
22:09:15 <kbabbitt> ... especially given that colort spaces evolve
22:09:32 <kbabbitt> lea: a lot of history in having knobs that people can control through CSS properties
22:09:41 <kbabbitt> ... transition-behavior; allow-discrete was one
22:09:48 <kbabbitt> ... same argument could be made about that
22:09:52 <kbabbitt> ... or size interpolation
22:09:58 <kbabbitt> ... property that tweaks how that works
22:10:05 <kbabbitt> ... that's how we frequently do things
22:10:13 <bramus> q?
22:10:20 <kbabbitt> ... if you take the effort to specify this property, anything that deoesn' have an interpolation space gets default seems reasonable
22:10:26 <bramus> q+
22:10:32 <kbabbitt> ... I don't think we should continue same current situation for a number of reasons mentioned
22:10:38 <kbabbitt> ... not just one, authors are making poor choices
22:10:51 <kbabbitt> ... potential for errors, even myself I forget to specify and am unsure why it doesn't interpolate
22:10:53 <kbabbitt> ... it's verbose
22:10:58 <kbabbitt> ... many reasons to omit this
22:11:00 <argyle> +1 lol, i've forgotten to put the colorspace in there multiple times
22:11:06 <kbabbitt> ... there should be a way to specify default
22:11:14 <kbabbitt> ... but unless you're using a var like that you shouldn't have to specify
22:11:22 <kbabbitt> ... but there should aloso be a way to specify to use a fallback
22:11:44 <kbabbitt> weinig: if we're going to add that thing, doing both changes simultaneously so authors learn would be preferred
22:11:51 <kbabbitt> astearns: in interest of time, let's take back to issue
22:11:56 <kbabbitt> ... hearing reservations
22:11:59 <lea> is anyone else actually objecting?
22:12:29 <bramus> https://github.com/w3c/csswg-drafts/issues/9109 could solve this
22:12:45 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11558
22:12:45 <github-bot> Topic: [css-color-hdr] auto value of dynamic-range-limit
22:12:45 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11558.
22:13:02 <kbabbitt> smfr: this is about dynamic-range-limit
22:13:07 <kbabbitt> ... spec has 3 values currently
22:13:17 <kbabbitt> ... allow author control over how bright an hdr video or image will be
22:13:21 <kbabbitt> ... I think current default in spec is high
22:13:24 <kbabbitt> ... we have concerns about that
22:13:38 <kbabbitt> ... general concern is that we don't think we want to allow web content to get max hdr in all contexts
22:13:47 <kbabbitt> ... could be source of annoyance, e.g. high hdr ad
22:13:53 <kbabbitt> ... but there are uses such as photography
22:13:57 <kbabbitt> ... we think UA should have control
22:14:04 <kbabbitt> ... with result combination of author and user control
22:14:10 <kbabbitt> ... constrained in Safari in normal use case
22:14:16 <kbabbitt> ...  but allow fullscreen video to be full HDR
22:14:25 <kbabbitt> ... we think there are case where UA should make choices
22:14:27 <ChrisL> initial value is indeed high https://drafts.csswg.org/css-color-hdr/#the-dynamic-range-limit-property
22:14:34 <kbabbitt> .... so there should be author vlue that specifies default
22:14:45 <kbabbitt> ... if specified, UA doesn't necessarily provide it, but its used as hint or suggestion to UA
22:14:46 <florian> q+
22:14:50 <astearns> ack bramus
22:14:58 <kbabbitt> ... not saying there should bec omplicate dheuristics
22:15:08 <kbabbitt> ... where UA should compute how much HDR an element gets based on surroundings
22:15:17 <kbabbitt> ... but rather fullscreen gets HDR, others don't
22:15:21 <astearns> ack florian
22:15:23 <ccameron> q
22:15:26 <kbabbitt> florian: sympathize with use case entirely
22:15:34 <kbabbitt> ... wonder if we can do it by doing less than what you suggest
22:15:34 <ChrisL> q+ ccameron
22:15:38 <kbabbitt> ... instead have ? be default
22:15:44 <kbabbitt> ... give room to UA to interpolate values
22:15:56 <kbabbitt> ... if Safar thinks full hdr is not reasonable behave as constrained instead
22:16:05 <kbabbitt> ... but still give author ability to start in constrained context
22:16:15 <kbabbitt> ... at this point I think auto kind of does the same as constrained anyway
22:16:23 <kbabbitt> smfr: I think that's a reasonable sugestion
22:16:31 <kbabbitt> ... question of what we consider author value to mean in CSS
22:16:34 <hober> qq+
22:16:41 <kbabbitt> ... I do feel it's slightly magical
22:16:49 <kbabbitt> florian: maybe auto ais a replacement name for constrained hdr
22:16:54 <kbabbitt> ... don't feel we need both
22:17:03 <kbabbitt> ... but maybe auto is a replacement
22:17:15 <kbabbitt> smfr: I do think we need to distinguish between no hdr and constrained hdr
22:17:23 <astearns> ack hober
22:17:23 <Zakim> hober, you wanted to react to florian
22:17:32 <kbabbitt> hober: I do prefer a distinct auto value vs changing default to constrained
22:17:35 <ChrisL> I don't think that auto and constrained-hdr are the same
22:17:45 <kbabbitt> ... because I can't predict future and don't know what a sensible default will be in 20 years
22:17:50 <weinig> q+
22:17:51 <kbabbitt> ... auto feels more future proof
22:18:05 <astearns> ack ccameron
22:18:12 <kbabbitt> ccameron: there's an issue of compat with behjavior that browsers currently ship
22:18:19 <kbabbitt> ... which is every browser supports hdr video today
22:18:22 <kbabbitt> ... and has for severaql years
22:18:30 <kbabbitt> ... all browsers provide no way to do anything but high right now
22:18:31 <smfr> q+
22:18:45 <kbabbitt> ... so to change that is to change the behavior of every application, every site that hosts hdr video
22:19:00 <kbabbitt> ... when we discussed this about a year ago, that seemed like a reason that we can't change this default behavior
22:19:04 <kbabbitt> ... that's why high was chosen
22:19:12 <kbabbitt> .. . if this were coming from a position of no hdr anywhere
22:19:17 <kbabbitt> ... id be fine with standard as default
22:19:20 <kbabbitt> ... and all hdr being opt in
22:19:23 <fantasai> so maybe 'auto' means 'constrained-high' except on videos where it means 'high'?
22:19:30 <kbabbitt> ... towards the topic of auto vs constrained high
22:19:46 <kbabbitt> ... a constraint that the author is specifying on top of ? will determine whats on page
22:19:55 <kbabbitt> ... right now it's acceptablef or UA to behave as smfr suggests
22:20:04 <kbabbitt> ... unless fullscreen video, UA restricts
22:20:16 <kbabbitt> ... that's acceptable and perhaps constrained-high and high might have only small difference
22:20:45 <kbabbitt> ... so I think there's an issue where this is about content not saying " I want this to be extra bright" but "this is defined to be in full brightness"
22:20:52 <kbabbitt> ... I want to pull it back and let UAs be free to do other things
22:21:00 <kbabbitt> ... if page goes background, lose HDR
22:21:07 <kbabbitt> ...battery saver. lose hdr
22:21:25 <kbabbitt> ... page says I don't have a lot of HDR content I want this to show up please don't restrict me might be a separate proposal
22:21:35 <kbabbitt> ... sympathetic to idea of approaching from different direction but time machines are in short supply
22:21:47 <kbabbitt> smfr: first one is about hdr video
22:21:52 <kbabbitt> ... and maintaining current behavior
22:21:57 <kbabbitt> .. we haven't ruled out constraining more
22:22:03 <kbabbitt> ... get feedback that hdr is annoying sometimes
22:22:08 <kbabbitt> ... and leads to more power usage
22:22:25 <kbabbitt> ... your other point was re: css property allowing author to impose additional constraints
22:22:32 <kbabbitt> ... I think it's easy to forget that in the values that's the case
22:22:40 <kbabbitt> ... maybe unconstrained value should be none instead of ?
22:22:48 <astearns> s/?/high/
22:23:13 <kbabbitt> ... maybe we should rethink name of properties and values so it's obvious author is imposing limits on UA
22:23:21 <kbabbitt> ... instead of high, make it none since theres no limit
22:23:28 <kbabbitt> ... maybe constrained should be medium
22:23:38 <astearns> ack weinig
22:24:00 <kbabbitt> weinig: to clarify: in your version of this, would expllicitlyu putting high on something actually change the behavior in non fullscreen?
22:24:02 <fantasai> I had texted "hdr: none | some | all" to smfr mostly as a joke...
22:24:22 <kbabbitt> .... yo mentioned default auto meaning high in non fullscreen, would that change anything?
22:24:37 <kbabbitt> smfr: ccameron just touched on this, I think we're getting confused on what this property means
22:24:46 <kbabbitt> ... ccameron said, maybe that would be a separate property, to ask for momre HDR
22:24:59 <kbabbitt> weinig: I'm asking, in your mental model, would high do anything for any element?
22:25:03 <kbabbitt> smfr: not sure we know yet
22:25:12 <fantasai> 'dynamic-range: normal | extended | high' ?
22:25:18 <kbabbitt> weinig: that's the confusing thing to me, it sounds like what you are trying to describe is an upper bound of headroom
22:25:20 <kbabbitt> ... in different scenarios
22:25:28 <kbabbitt> ... so i fullscreen one upper bound, not fullscreen another
22:25:37 <kbabbitt> ... but all that really means is high constrained terms are just relative
22:25:41 <fantasai> 'dynamic-range: small | medium | large'
22:25:42 <kbabbitt> smfr: yes they shift
22:25:49 <kbabbitt> weinig: which seems reasonable
22:25:57 <kbabbitt> ... tyring to semantically mark up what position is
22:26:08 <kbabbitt> ... ccameron explained in comment, you're tyring to say something wehre I think this should alwasy be HDR
22:26:12 <ccameron> q+
22:26:13 <fantasai> 'dynamic-range: low | medium | high'
22:26:14 <kbabbitt> .. this is something tha can be mixed in other context
22:26:19 <kbabbitt> ... this can never be HDR
22:26:34 <kbabbitt> ... not sure there' sanything in spec currently that would preclued UA from redefining based on context
22:26:47 <astearns> ack ccameron
22:26:50 <kbabbitt> ccameron: return to one thing, issu eof hdr content bein gbad
22:26:58 <kbabbitt> ... there are roughly 3 sources of hdr content
22:27:00 <fantasai> 'dynamic-range: local | limited | express' wait, no wrong scale...
22:27:03 <kbabbitt> ... still photos taken on recent phones
22:27:11 <kbabbitt> ... those photos genereally coexist well without limits
22:27:17 <kbabbitt> ... graded to look good next to SDR content
22:27:21 <kbabbitt> .. profesionally made video
22:27:25 <kbabbitt> .. that too coexists quite well
22:27:34 <kbabbitt> ... netflix and watch something doesn't need to be pulled down
22:27:44 <kbabbitt> ... one thing which is terrible which is hdr video shot on phone not a samsung
22:27:47 <kbabbitt> ... it's bad everywhere
22:27:58 <kbabbitt> ... it's just let's make everything 4x brighter and maybe people will like it
22:28:10 <kbabbitt> ... I can be draconian about it, given my druthers I would reinterpret that as SDR
22:28:22 <kbabbitt> ... some people took their SDR colors and made 4x as bright
22:28:28 <kbabbitt> ... we need to assume HDR content will not look like that
22:28:41 <kbabbitt> ... lot of work towards fixing user generated content
22:28:56 <kbabbitt> ...assumption needs to be that HDR coexists reasonably well except for one bad thing we're tyrin to stamp out
22:29:02 <kbabbitt> ... in terms of shifting down that's what I had in mind
22:29:11 <kbabbitt> ... could be that constrained-high and high become the same
22:29:16 <kbabbitt> ... sympathetic to idea of no limit
22:29:21 <kbabbitt> ... limit none sgmt
22:29:23 <weinig> q+
22:29:41 <kbabbitt> ... in that case it sounds like we're ... how would you feel about changing name to be more accurate
22:29:48 <kbabbitt> ... and then starting discussion sabout page giving hints to UA
22:29:49 <fantasai> 'dynamic-range: standard | auto | unlimited'
22:29:55 <kbabbitt> ... because UA is going to do all sorts of stuff
22:30:17 <kbabbitt> ... so we might just stick with that for now and see if UAs implement hweuristics they want more input on
22:30:21 <kbabbitt> smfr: im happy with that
22:30:28 <kbabbitt> ccameron: suggestion for middle thing?
22:30:51 <astearns> ack smfr
22:30:53 <jensimmons> jensimmons has joined #css
22:30:54 <astearns> ack weinig
22:30:56 <fantasai> 'dynamic-range: standard | auto | high'
22:31:06 <kbabbitt> weinig: it would be great if instead of ... wherever we come up with default, instead use UA stylesheet to only apply to video and image
22:31:11 <kbabbitt> ... where it's actually required
22:31:17 <fantasai> 'dynamic-range: standard | extended | high'
22:31:22 <kbabbitt> ... we don't have a agoo under standing of what HDR conytrast values mean outside of those contrasts
22:31:48 <ccameron> q+ ... do we have a moment to discuss the topic of HDR colors
22:31:48 <ccameron> https://github.com/w3c/csswg-drafts/issues/11616
22:32:01 <kbabbitt> ... we don't currently have headroom for CSS values even if they have lots of brightness
22:32:07 <kbabbitt> ... finding some way to constrain this property to things it applies do
22:32:12 <kbabbitt> s/do/to
22:32:17 <ChrisL> we currently have headroom==0 for css colors (SDR)
22:32:43 <kbabbitt> astearns: would it make sense to have an hdr only breakout session in next week or tow?
22:32:56 <kbabbitt> ChrisL: I think so especially since there's a new issue from ccameron
22:33:01 <kbabbitt> ... which actually addresses directly that
22:33:05 <kbabbitt> ... how to get CSS colors in HDR
22:33:14 <kbabbitt> ... it would be great to have more tie on these isseus
22:33:17 <schenney> Background images?
22:33:20 <kbabbitt> ... nicely themed breakout, in favor
22:33:30 <alisonmaher> alisonmaher has joined #css
22:33:33 <kbabbitt> astearns: if we do that, can we take this back to the issue for now and have this be part of agenda for breakout?
22:33:40 <kbabbitt> [agreement]
22:33:52 <kbabbitt> astearns: let's do that, email me if you'd like to be part of breakout session
22:35:15 <ydaniv> ydaniv has joined #css
22:35:25 <kbabbitt> topic: break
22:39:56 <dholbert_> dholbert_ has joined #css
22:56:06 <Di> Di has joined #css
22:56:58 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11208
22:56:58 <github-bot> Topic: [css-display-4] reading-flow and mix of auto-flow and explicit items
22:56:58 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11208.
22:57:20 <nicole> Reading flow and the mix of outflow and explicit items
22:57:30 <ydaniv> ydaniv has joined #css
22:57:44 <nicole> asterns: limit to necessary for HTML folks to progress
22:58:17 <nicole> Rachel: Some items you want to choose position and mix of autoplaced items. How does reading flow work with that
22:58:39 <nicole> Rachel: probably by applying it to the container and children. Which we originally discussed and decided not to do
22:58:40 <ydaniv> s/asterns:/astearns:/
22:59:03 <nicole> rachelandrew: a bit like order, but only affects reading flow
22:59:25 <nicole> fantasai: works find for explicit source order
22:59:37 <astearns> s/find/fine/
23:00:01 <nicole> fantasai: simple example of mixed - a masonry layout with a sidebar. Title, nav, etc. Positioned on right aesthetically
23:00:17 <nicole> fantasai: would be 5th rather than 1st
23:00:34 <florian> q+
23:01:04 <nicole> rachelanderew: do we fix it now or in the future. Are we leaving the door open to other solutions. How does it impact the HTML spec? Otherwise not urgent, but necessary
23:01:24 <nicole> rachelandrew: would reading flow container also encompass this situation?
23:01:25 <astearns> ack florian
23:01:54 <nicole> florian: we want this now. Removed because we started with only explicit ordering, was a bad solution. Overall solution combo of 2
23:02:02 <nicole> florian: general scheme on container
23:02:08 <nicole> florian: override on children
23:03:05 <nicole> florian: design of thing that applies to container should account for being able to override children
23:03:12 <nicole> florian: so both pieces work together
23:03:21 <fantasai> s/so both/design both together so both/
23:04:04 <nicole> rachelandrew: reasonable, can bring this back. Identified use cases they hadn't considered before. Good to bring it back to spec. Also bike shed name. Does it affect HTML implementation
23:04:31 <astearns> ack fantasai
23:04:35 <nicole> rachelandrew: Probably doesn't, since it is just a different way of doing ordering
23:05:03 <Di> q+
23:05:16 <nicole> fantasai: set of items, here is order, tells HTML to do the rest. HTML spec shouldn't change. Reading flow, reading order, and ____ will provide input to HTML
23:05:32 <astearns> ack Di
23:05:35 <fantasai> s/___/things like dense packing/
23:06:07 <nicole> di: HTML side is reading flow container, shouldn't override it. Should be fine for the hTML spec
23:06:29 <nicole> asterns: design as a whole rather than piecemeal
23:06:33 <nicole> di: agree
23:07:25 <nicole> astearns: Resolution to restore previous reading order property and use it as a starting point for reading order flow.
23:08:02 <astearns> ack fantasai
23:08:15 <TabAtkins> +1
23:08:17 <nicole> fantasai: as a starting point, define that if the reading order of 2 items is equivalent, reading flow breaks the tie
23:08:43 <nicole> RESOLVED: Resolution to restore previous reading order property and use it as a starting point for reading order flow.
23:09:14 <nicole> RESOLVED: as a starting point, define that if the reading order of 2 items is equivalent, reading flow breaks the tie
23:09:15 <dbaron> is there a new condition that it only works in reading order containers?
23:10:06 <nicole> astearns: David can you raise an issue?
23:11:05 <nicole> fantasai: does the reading order prop only impact reading order containers or does attempting to use reading flow or order cause it to become a reading order container
23:11:27 <nicole> rachelanderew: masonry is an exception, but for everything else you'd need to say on the container
23:12:17 <dbaron> (I was just asking that to try to ensure the resolutions capture stuff that was said earlier in the discussion.)
23:12:20 <dbaron> Present-
23:12:26 <nicole> fantasai: default order is source order. HTML needs a concept of is it a reading order container, must be yes to do reordering. If it has a non initial value on any child than the container needs to be a reading flow container. From css user perspective, either do it auto or make them change something else
23:12:41 <nicole> racheandrew: prefers explicit, like flexbox
23:13:12 <nicole> rachelandrew: always positive, this is a reading flow container, so they know they are reordering. Doing it by accident without thinking would be bad
23:13:29 <astearns> notes that the explicit container may not only be due to reading-flow being set explicitly, if the default value creates reading flow containers for some layout modes
23:13:33 <nicole> fantasai: not sure. Cases where we do want to double opt in. Other cases where the child can decide on their own
23:13:36 <dbaron> (from my own perspective I might ask whether we want a more complicated name so it doesn't look like reading-order is a simpler thing than reading-order-items)
23:13:48 <nicole> fantasai: for example z index is just the child
23:13:55 <fantasai> we renamed reading-order-items to reading-flow
23:13:58 <fantasai> dbaron: ^
23:14:04 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/2923
23:14:04 <github-bot> Topic: [css-multicol] Overflow in the block direction for continuous media
23:14:04 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2923.
23:15:20 <nicole> rachelandrew: speccing overflow in block direction for multicol
23:15:48 <nicole> rachelandrew: partially becuases of the carousel work, and partially because it can go in different directions. Rachel put proposed spec in the issue as a starting point
23:15:53 <nicole> rachelandrew: modeled after flex
23:16:03 <astearns> proposal: https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2566448417
23:16:14 <nicole> rachelandrew: modeled after logical container. Instead you could opt to use column wrap
23:16:23 <fantasai> +1 for a row-height property
23:16:28 <astearns> florian's: https://github.com/w3c/csswg-drafts/issues/2923#issuecomment-2620334162
23:16:30 <nicole> rachelandrew: has a different proposal. what should we do, which looks best?
23:16:33 <florian> q+
23:16:39 <astearns> ack florian
23:17:17 <nicole> florian: want to have this ability. multicol having overflow columns in inline dir isnt' what people want most of the time. Having multiple rows of multicol is extremely desirable.
23:17:36 <nicole> florian: constrain height, overflow in block direction rather than inline direction
23:17:50 <kizu> q+
23:18:00 <nicole> florian: are they simply overflowing. Will they clash? Or whether you simply grow the multicol despite the constrained height
23:18:12 <nicole> florian: should the rows add height?
23:18:45 <nicole> florian: proposes a new prop to constrain the height of the row of the multicol. column-height or column-row-height would work well.
23:18:52 <nicole> florian: column-row-height: 10em
23:19:13 <nicole> florian: if you also set the multicol height, you use all the css tools to deal with how to lay them out
23:19:15 <TabAtkins> yup, +1 to column-row-height
23:19:34 <nicole> florian: not sure what short hands should be
23:19:44 <astearns> ack fantasai
23:19:49 <nicole> florian: how to make it work with gap and other properties needs to be worked out
23:20:01 <florian> q+
23:20:41 <nicole> fantasai: doesn't want an overflow model for this feature (in flow content). Don't conflate sizing the box with content inside the box. Prop that sets column height is the right thing to do
23:20:50 <astearns> ack kizu
23:20:52 <TabAtkins> ah yeah, column-height is shorter and just as right
23:20:52 <astearns> q+
23:20:55 <nicole> fantasai: likes column-height
23:21:51 <nicole> roman: wants this feature. Could imagine automatically fragmenting so that each item goes into the overflow container
23:22:08 <astearns> ack florian
23:22:08 <nicole> roman: use case to fit everything in viewport so it paginates properly
23:22:24 <nicole> florian: not incompatible with having a property
23:22:29 <TabAtkins> (i do think it would be nice to have a `column-height: auto` that matches the height of the nearest scroller)
23:22:30 <fantasai> s/use case/but more common is use case of having it in-flow,/
23:22:44 <nicole> florian: if you set it to auto it would go in the block direction otherwise inline
23:23:24 <nicole> florian: row-height instead of column-height because we might want to use column-row-count later, but won't insiste
23:23:57 <rachelandrew> q+
23:24:00 <nicole> fantasai: column-height and column-width as a pair seems better
23:24:13 <nicole> fantasai: authors won't think about columns as explicitly as rows
23:25:09 <florian> q+
23:25:12 <nicole> astearns: florian mentioned overflow in inline dir, but thinks it is the wrong way to talk about it. We are fragmenting in the inline direction or block direction. As you fragment columns now they can overflow in inline direction.
23:25:29 <nicole> astearns: when we add this you will be able to fragment in the block direction
23:25:50 <nicole> astearns: but it also might overflow, to put the content in the new contents
23:26:40 <nicole> florian: agree overflow isn't quite the right word. Neither is fragmentation. Fragmenting the content of the multicol, and deciding where to place them. Whether they overflow depends where you place them and what else is there.
23:27:15 <nicole> florian: rachelandrew proposed column wrap, whatever we call it, they describe where the extra content goes (block or inline direction)
23:27:36 <astearns> ack rachelandrew
23:27:39 <astearns> ack astearns
23:27:41 <astearns> ack florian
23:27:46 <nicole> astearns: doesn't agree with fantasai that ___ will be rare, he thinks authors will want to do it at the outset
23:28:18 <nicole> rachelandrew: what happens if you have set a height on multicol and then you set column height and row height. And then you have too many things to fit in the container. Answer could be that it overflows
23:28:20 <nicole> florian: yes
23:28:32 <astearns> s/___ /choosing how many rows of columns you want/
23:28:39 <florian> q+
23:28:58 <astearns> ack florian
23:28:59 <nicole> rachelandrew: are we bringing in too much extra complexity? Is it getting to be like regions. Not against direction, just concerned about complexity.
23:29:14 <nicole> florian: yes it would overflow, like any content that doesn't fit would
23:29:30 <nicole> florian: doesn't matter how many rows cols you put in there
23:29:43 <nicole> florian: if it is too big, you have other tools to deal with extra space
23:29:44 <TabAtkins> I definitely think tying this explicitly to overflow *is* making it too complex. Just adding more columns to the content seems like the most straightforward way
23:30:06 <nicole> astearns: proposed resolution to start specifying this using column-height
23:30:12 <nicole> rachelandrew: happy with that
23:30:36 <kbabbitt> 👍
23:30:41 <nicole> RESOLVED: start specifying column-height
23:31:22 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11379
23:31:22 <github-bot> Topic: [css-overflow] Web compat issue when hiding abspos after the line-clamp point
23:31:22 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11379.
23:32:10 <nicole> emilio: I implemented line-clamp model so you don't paint lines that are clamped. Including abs pos if static position is after clamp point
23:32:46 <nicole> emilio: had to revert behavior change, so need a new solution
23:33:12 <nicole> emilio: most sensible, keep painting abs pos whose containing block is at or above the line clamp container
23:33:23 <nicole> emilio: not counting abs pos contained in an inline element
23:33:36 <florian> q+
23:33:38 <nicole> emilio: only abs pos that hang off of clamped container or above
23:33:46 <astearns> q+
23:34:01 <nicole> emilio: could restrict it more, main issue is you still need to dig through arbitrary content to find abs pos elements
23:34:08 <nicole> iank_: you need to do that anyway
23:34:20 <nicole> iank_: abs pos still has geometry
23:34:29 <nicole> emilio: still need to lay it out
23:34:32 <nicole> iank_: yes
23:34:37 <andreubotella> q+
23:34:51 <nicole> emilio: in gecko after layout, build display list, if you don't paint, just keep the subtree
23:35:08 <nicole> emilio: abspos, painting order depends on in flow position
23:35:42 <astearns> ack florian
23:36:23 <nicole> florian: could we not do it, not paint, not bother with complexity. Can't from a webcompat perspective. They use the abs. pos to add a button to expand the clamped area
23:36:34 <nicole> florian: Emilio's proposal is probably the best
23:37:07 <nicole> florian: people may move it and it will pop up out of there. If they put it somewhere reasonable the behavior will be reasonable. If they want to be sure it isn't visible, overflow hidden
23:37:21 <nicole> iank_: relpos can affect the painting
23:37:51 <kizu> q+
23:37:57 <nicole> emilio: the way gecko paints abs pos: traverse layout tree, end up in inflow pos of abs pos, then build display list for the abs pos
23:38:08 <nicole> iank_: oh, we don't do that, I'm not concerned
23:38:21 <nicole> astearns: is this just abs pos or other things too? ex. anchor positioning
23:38:33 <dholbert> (rel-pos and sticky-pos are worth considering too)
23:38:41 <dholbert> (but hopefully can be disregarded)
23:38:46 <kizu> q-
23:38:54 <nicole> TabAtkins: currently have the ability to do that
23:39:01 <astearns> ack astearns
23:39:08 <nicole> astearns: does position relative to anchor make a difference
23:39:22 <nicole> TabAtkins: it is absolutely pos
23:39:43 <nicole> iank_: if potential anchor is past line clamp, we don't consider that a potential anchor
23:39:44 <astearns> ack andreubotella
23:40:24 <nicole> andreubotella: not great to have text that is hidden but not abspos. One option to limit this to ____
23:40:48 <florian> s/____/the -webkit- prefixed version
23:40:49 <florian> q+
23:40:53 <nicole> andreubotella: but would cause a difference in layout between line-clamp and webkit-line-clamp. Not desirable.
23:40:56 <dholbert_> dholbert_ has joined #css
23:41:02 <emilio> q+
23:41:12 <nicole> andreubotella: should authors be told to use overflow hidden? We were hoping to avoid this with web components
23:41:31 <andreubotella> s/with web components/with this redefinition of (-webkit-)line-clamp
23:41:34 <nicole> iank_: for the 99% case, this doesn't matter. For the cases with combat challenges, people do want the abs pos to be painted
23:41:47 <nicole> iank_: I think that's fine
23:41:55 <florian> s/combat/compat/
23:42:11 <nicole> iank_: we should minimize differences between webkit-line-clamp and line-clamp for autoprefixer's sake
23:42:13 <astearns> ack florian
23:42:27 <nicole> florian: also thinks this is fine, don't restrict to webkit prefix
23:42:40 <nicole> florian: kind of handy to create button to expand clamp
23:42:54 <astearns> ack emilio
23:43:00 <nicole> florian: in the few cases where people didn't want it to paint authors can use clip and other options
23:43:30 <nicole> emilio: weird if we painted arbitrary abspos. ex. an icon but not a button
23:43:52 <nicole> emilio: in this case you are just affecting something inside the line clamp tree, so it seems like a feature
23:44:52 <nicole> Emilio: proposed resolution, do not skip painting for abs pos where the position is at or above the line clamped container
23:46:07 <nicole> holbert: wants to add mentioning containing block
23:46:38 <florian> s/where the position/where the containing block
23:46:44 <nicole> astearns: edit, do not skip painting for abs pos where the containing block for the abs pos is at or above the line clamp
23:47:03 <nicole> RESOLVED: do not skip painting for abs pos where the containing block for the abs pos is at or above the line clamp
23:47:50 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11355
23:47:50 <github-bot> Topic: [css-overflow] Should overflow-clip-margin allow negative lengths?
23:47:50 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11355.
23:48:21 <TabAtkins> emilio: this came about when we were discussing whether o-c-m shoudl apply to scrollable boxes
23:48:27 <TabAtkins> emilio: we ahve values that let you shrink the clip region
23:48:36 <TabAtkins> emilio: so is there a godo reason to not allow negative lengths?
23:48:55 <emilio> TabAtkins: we designed it to allow expanding the region
23:49:05 <emilio> ... wasn't obvious that we needed to make it smaller
23:49:14 <emilio> ... but you're right that the box values allow it to get smaller
23:49:16 <florian> +1
23:49:16 <emilio> ... so may as well
23:49:20 <kizu> +1
23:49:32 <TabAtkins> astearns: so proposed resolution is to allow negative lengths in overflow-clip-margin
23:49:36 <TabAtkins> astearns: objections?
23:49:48 <TabAtkins> RESOLVED: allow negative lengths in overflow-clip-margin, with the obvious effect
23:50:59 <TabAtkins> florian: should we talk about 10745 (applying to scrollable?)
23:51:14 <TabAtkins> emilio: i tabled that part earlier
23:51:28 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10745
23:51:29 <github-bot> Topic: [css-overflow] Should overflow-clip-margin apply to scrollable boxes?
23:51:29 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10745.
23:51:52 <TabAtkins> astearns: proposed resolution: new negative sizes to overflow-clip-margin (from 11355) also apply to scrolalble areas
23:51:56 <TabAtkins> florian: supprot with a question
23:52:11 <TabAtkins> florian: if you ahve content-box with or without negative margins, or padding box + negative margin, yes
23:52:32 <TabAtkins> florian: but if you have border-box (expands) and negative margins (reduces), do we take that into acocunt, or do we stop with just border box
23:52:51 <TabAtkins> emilio: main implication is that with classic scrollbars...
23:52:59 <TabAtkins> emilio: we dont' want to make clipping are larger than the padding box
23:53:15 <TabAtkins> emilio: because it's a scorllable box, that's core to the idea
23:53:38 <TabAtkins> emilio: so if you set border-box with a negative margin, so it's bigger than the scrollbar and shrinks partially, but in a system with bigger scrollbars it doesn't, so you get clipping in one but not the other...
23:53:52 <TabAtkins> florian: i don't think it's a very interesting case, so we could just say that if you set border-box it doesn't apply
23:54:33 <TabAtkins> TabAtkins: how do we handle today content-box + positive margin
23:54:59 <TabAtkins> florian: think it's unspecified
23:55:10 <TabAtkins> TabAtkins: we shoudl specify that it's clamped to padding box, since that seems to be our constraint
23:55:50 <oriol> q+
23:56:35 <TabAtkins> TabAtkins: so proposal: scrolalble boxes can use padding box and negative value, or content-box + any value (but clamped to padding box). border-box can't be used with negative value, because its relation to padding box is possible varyign between impls
23:57:05 <TabAtkins> oriol: i didn't fully udnerstand the reason for not allowing this with border box
23:57:18 <TabAtkins> oriol: if we allow content-box to grow to the padding, seems consistent ot allwo border box to shrink
23:58:28 <TabAtkins> TabAtkins: issue is that we always clamp scrollable down to padding box.
23:58:36 <TabAtkins> TabAtkins: you can grow content box up to that point
23:58:58 <TabAtkins> TabAtkins: if you shrink border box, it either does nothing (because it didn't shirnk enough and our clamp goes further) or it does shirnk to below padding box
23:59:13 <TabAtkins> TabAtkins: but the concern is, with varying scrollbar widths, whether you hit that point or not can be browser dependent
23:59:18 <TabAtkins> TabAtkins: which seems potentially bad for authors
23:59:26 <TabAtkins> astearns: no objections to the resolution