15:59:24 <RRSAgent> RRSAgent has joined #css
15:59:28 <RRSAgent> logging to https://www.w3.org/2023/06/28-css-irc
15:59:28 <Zakim> RRSAgent, make logs Public
15:59:59 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:04 <PaulG> present+
16:00:51 <SebastianZ> present+
16:01:05 <ydaniv> ydaniv has joined #css
16:01:11 <drott> present+
16:01:23 <miriam> present+
16:01:29 <argyle> argyle has joined #css
16:01:35 <munira> present+
16:01:36 <argyle> present+
16:01:51 <jfkthame> jfkthame has joined #css
16:02:03 <flackr> flackr has joined #css
16:02:05 <plinss> present+
16:02:09 <flackr> present+
16:02:49 <bramus> present+
16:03:58 <davidleininger> davidleininger has joined #css
16:04:44 <dbaron> Present+
16:04:51 <vmpstr> present+
16:05:00 <drott> scribenick: drott
16:05:08 <Rossen_> ScribeNick: drott
16:05:31 <dholbert> present+
16:05:39 <ydaniv> present+
16:07:45 <github-bot> Topic: [css-text-4] Don't provide a language parameter for word-boundary-detection
16:07:47 <jensimmons> jensimmons has joined #css
16:07:50 <jensimmons> present+
16:08:19 <drott> topic: rossen_: This was myles's item, requesting it to be added early.
16:08:35 <drott> rossen_: don't see myles on the call, anyone to bring that up?
16:08:59 <drott> topic: https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1587313405
16:09:13 <drott> github: 6530
16:09:24 <github-bot> Topic: [css-animations-2] Should the initial value for animation-duration be auto?
16:10:26 <drott> fantasai: We changed animation-duration initial value to auto
16:10:36 <drott> fantasai: But we need that to return 0 seconds for time based animations
16:10:48 <drott> fantasai: someone? wanted to clarify when that triggers
16:11:04 <fantasai> https://github.com/w3c/csswg-drafts/pull/8952
16:11:07 <drott> fanatasai: drafted a PR for that (triggers when animation timeline is at 0(
16:11:25 <drott> fantasai: if there is only one list value, and that computed value is auto
16:11:50 <Rossen_> q?
16:11:53 <flackr> q+
16:11:58 <drott> fantasai: wanted to confirm with the working group - is the draft suitable? Which version do we want to go with?
16:11:59 <Rossen_> ack flackr
16:12:05 <fantasai> fantasai: alternative is to allow multiple values, but all of them need to be auto
16:12:15 <drott> flackr: the significant use case is: initial value of animation timeline should be covered
16:12:31 <drott> flackr: proposed PR is good in that regard, unless developer changes animation timeline
16:12:53 <drott> flackr: reason we didn't want to expose multiple values was: didn't want to expose the duration (?)
16:13:27 <flackr> s/?/duration repeat behavior
16:13:28 <drott> rossen_: any reasons for concern?
16:13:39 <drott> rossen_: proposal to stick with single value?
16:13:48 <fantasai> Options were:
16:14:03 <fantasai> 1. auto values individually convert to 0s, can have a mixed list
16:14:13 <fantasai> 2. check for only the initial value (one list item, being auto)
16:14:21 <fantasai> 3. check for the entire list being auto (but multiple values ok)
16:15:24 <drott> rossen_: no objections heard to go with single value?
16:15:38 <drott> rossen_: based on that clarification, anyone changed their mind?
16:16:24 <drott> RESOLVED: Go with option 2, "check for only the initial value (one list item, being auto)"
16:16:31 <github-bot> Topic: [css-backgrounds-4] Split CSS Backgrounds into separate specs?
16:16:44 <fantasai> scribenick: fantasai
16:17:24 <fantasai> SebastianZ: Suggestion is to split up the CSS Background 4 spec into 3
16:17:39 <fantasai> SebastianZ: initial suggestion was to split into 2, but this didn't turn out very well
16:17:50 <fantasai> SebastianZ: idea is to focus each spec on one thing
16:18:00 <fantasai> SebastianZ: because backgrounds covers backgrounds, borders, and box shadow
16:18:10 <fantasai> SebastianZ: and we want to edit separately, and also make progress separately
16:18:31 <fantasai> SebastianZ: suggestion is into css-background-4 related to backgrounds
16:18:33 <davidleininger> davidleininger has joined #css
16:18:38 <fantasai> SebastianZ: Borders 4 cover everything border-related
16:18:55 <fantasai> SebastianZ: and CSS box-decorations-4 which covers box shadow and its longhands and anything else related to box decorations
16:19:10 <ntim> ntim has joined #css
16:19:17 <Rossen_> ack fantasai
16:19:24 <fantasai> https://www.w3.org/TR/css-box-3/
16:19:25 <drott> fantasai: we also have a spec called box-model
16:19:32 <drott> fantasai: spec that covers margins and paddings
16:19:41 <drott> fantasai: that would put us into quite a lot of spec
16:19:59 <drott> fantasai: backgrounds is fairly self evident, other splits are less evident
16:20:28 <drott> fantasai: divisions not super clean, border-... applies kinda a background
16:20:43 <drott> fantasai: might make it hard for people to look for - if we have it spread across 4 specs
16:21:06 <drott> SebastianZ: bringing in the box model, which wasn't covered in that issue
16:21:25 <drott> SebastianZ: idea was to have clear concepts borders, backgrounds, decorations
16:21:44 <drott> fantasai: border-image has a background to it - concerned as to: What's what?
16:22:13 <drott> fantasai: i like the idea of splitting it, but uncertain about how to do it cleanly, making it so it's obvious
16:22:32 <drott> SebastianZ: counter proposal? atm it's confusion: CSS Backgrounds and Borders, box shadow not mentioned in the title, mixing things
16:22:33 <fantasai> e.g. box-decoration-break affects borders and background also
16:22:50 <drott> fantasai: don't have a good answer atm
16:23:04 <drott> rossen_: evident we have shifted in how borders and backgrounds are becoming more decorative
16:23:29 <drott> rossen_: over time, all of these concepts have progressed - seems reasonable for backgrounds, borders, decorations to be split
16:23:51 <drott> rossen_: to fantasai's point, we have some horizontal concepts in .. box model?
16:24:13 <drott> fantasai: they're interconnected: use case: author: where do i find the corresponding spec?
16:24:33 <drott> fantasai: question is: where do people find things
16:24:51 <drott> fantasai: box-model spec suitable place for box decorations?
16:25:14 <drott> SebastianZ: many new features coming to background and borders - if put in box-spec spec becomes very long
16:25:39 <drott> fantasai: backgrounds and borders being separate is ok, box decoration being a separate spec seems too much
16:25:52 <drott> rossen_: if we split this into only two specs, as a starting point
16:26:27 <castastrophe> castastrophe has joined #css
16:26:29 <drott> rossen_: let's say borders and backgrounds would be split off
16:26:35 <drott> rossen_: Where to put decorations?
16:26:43 <castastrophe> q+
16:27:08 <fantasai> fantasai: I think putting box-shadow into borders makes sense, it outlines the border
16:27:23 <fantasai> fantasai: but box-decoration-break could maybe go into css-box
16:27:26 <Rossen_> ack castastrophe
16:27:30 <fantasai> fantasai: since it also affects margins / padding
16:27:36 <drott> castastrophe: what would be the downside of a long spec?
16:28:00 <drott> castastrophe: we could also do cross-linking, and use it to a sub-specification?
16:28:35 <Rossen_> ack fantasai
16:28:36 <drott> jensimmons: sounds like there might not be enough consensus to resolve?
16:28:53 <drott> fantasai: split into backgrounds 4 and borders 4
16:29:16 <fantasai> fantasai: backgrounds-* into css-backgrounds, borders-* into css-borders
16:29:21 <fantasai> fantasai: box-shadow into css-borders
16:29:28 <fantasai> fantasai: box-decoration-break into css-box
16:29:50 <drott> SebastianZ: If that seems reasonable to you - perhaps we could go ahead with that proposal? Wanna address castatstrophe point?
16:30:00 <fantasai> s/SebastianZ/Rossen/
16:30:13 <drott> SebastianZ: it's box-shadow that does not fit well into one of those specs
16:30:43 <drott> SebastianZ: discussion started with others raising that box-shadow should stand on its own
16:30:52 <drott> fantasai: box-shadow should go into the border spec
16:31:18 <fantasai> fantasai: it's effectively functioning as a border
16:31:35 <fantasai> fantasai: box-decoration-break would go into css-box; it affects margins and padding too
16:31:59 <drott> rossen: would the proposed split into borders 4 and backgrounds 4, with fantasai's described split suitable?
16:32:30 <fantasai> plinss: I'm in favor of fantasai's proposal, but feel like shadows should go into backgrounds
16:32:36 <fantasai> plinss: but I don't feel strongly
16:32:48 <fantasai> plinss: it doesn't affect sizing
16:32:53 <fantasai> fantasai: neither does border-image
16:33:01 <fantasai> Rossen_: [summarizes proposal]
16:33:08 <fantasai> background-* into css-backgrounds
16:33:08 <ntim> sounds good to me
16:33:15 <fantasai> border-* (including border-image) into css-borders
16:33:19 <fantasai> box-shadow into css-borders
16:33:26 <fantasai> box-decoration-break into css-box
16:33:30 <fantasai> Rossen_: any objections?
16:33:55 <fantasai> RESOLVED: Adopt proposal above, background-* into css-backgrounds, border-* and box-shadow into css-borders, and box-decoration-break into css-box
16:34:17 <fantasai> SebastianZ: thanks for resolving
16:34:31 <fantasai> Rossen_: it's important to get to topics that are not everyone's most important, not let them languish
16:34:51 <fantasai> Topic: border-radius adjustment formula
16:34:55 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7103
16:35:44 <fantasai> fantasai: not prepared to present; suggest taking at F2F where we have better visuals
16:35:57 <github-bot> Topic: [css-background-4] add background-layers property to set everything but background-color
16:36:20 <fantasai> SebastianZ: initial proposal was to create background-layers property that is separate from background-color but is otherwise same as 'background' shorhtand
16:36:36 <fantasai> -> summary comment https://github.com/w3c/csswg-drafts/issues/8726#issuecomment-1569020794
16:36:48 <fantasai> SebastianZ: The discussion went on and had different proposal to cover that use case
16:36:59 <oriol> present+
16:37:01 <fantasai> SebastianZ: 1st was new shorthand described above
16:37:14 <fantasai> SebastianZ: another that includes everything except images and color
16:37:32 <fantasai> SebastianZ: third was a ::background() pseudo-element
16:37:39 <SebastianZ> https://github.com/w3c/csswg-drafts/issues/8726#issuecomment-1569020794
16:37:59 <fantasai> SebastianZ: fourth was to add new keyword to skip overwriting the color
16:38:16 <fantasai> SebastianZ: and last was from Oriol to make no change, but teach authors to use background-color: revert-layer
16:38:26 <Rossen_> q?
16:38:33 <fantasai> SebastianZ: My personal opinion is to have something like the original proposal
16:38:41 <fantasai> SebastianZ: from my view it's the easiest way to achieve this as an author
16:38:52 <fantasai> SebastianZ: other suggestions have adantages as well
16:39:49 <fantasai> fantasai: agree with SebastianZ
16:39:55 <ntim> q+
16:40:02 <fantasai> fantasai: tackling list-editing cascade is a big project, worth doing, but unnecessary
16:40:14 <Rossen_> ack fantasai
16:40:16 <Rossen_> ack ntim
16:40:19 <fantasai> fantasai: just adding a shorthand is simple and solves the problem, biggest problem is naming the shorthand
16:40:26 <miriam> q+
16:40:30 <fantasai> ntim: Problem is you'll have 3 properties with similar syntax, hard to know the differences
16:41:02 <fantasai> ntim: you can do background: url, url, and then background-image: url, url; and then background-layers: url, url
16:41:09 <fantasai> miriam: I agree with SebastianZ and fantasai
16:41:11 <Rossen_> ack miriam
16:41:15 <fantasai> miriam: I mostly wanted to push against the 'revert-layer' option
16:41:27 <fantasai> miriam: teaching authors to use revert-layer is great! but it has specific cases where that's useful solution
16:41:38 <fantasai> miriam: but it requires adding new layers, and want to do that carefully
16:41:45 <fantasai> miriam: doesn't make sense as a universal solution to this problem
16:42:13 <fantasai> ??: I had a proposal to put positioning into shorthand without image, to avoid confusion of three properties that can take an image
16:42:20 <fantasai> s/??/ntim/
16:42:25 <fantasai> SebastianZ: that was my second option
16:42:52 <drott> fantasai: not a good idea, then you'd have to maintain two lists
16:42:56 <Rossen_> ack fantasai
16:43:05 <drott> fantasai: 1 for images, 1 for positioning
16:44:11 <drott> fantasai: sometimes there's use cases for splitting those things - but images and positioning are cascading together, so they should be declared together
16:44:13 <drott> fantasai: i'd advocate for original proposal, just need a shorthand name that makes sense
16:44:30 <fantasai> Rossen_: sounds like many folks leaning towards original proposal
16:44:44 <fantasai> Rossen_: would there be objections to resolve on the original proposal, and naming later?
16:45:08 <fantasai> RESOLVED: add shorthand for background-* minus background-color, name TBD
16:45:44 <fantasai> Topic: language parameters for word-boundary-detection
16:45:48 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7193
16:45:55 <fantasai> myles: THis is a topic about line-breaking
16:46:04 <fantasai> myles: we're implementing fancy line breaking, and I hear Chrome is doing the same
16:46:14 <fantasai> myles: interesting part is that it's based on words and phrases for CJK
16:46:32 <fantasai> myles: right now opt-in for CSS is word-boundary-detection with auto value
16:46:42 <fantasai> myles: auto value in CSS is actually a function that takes a locale string
16:46:48 <fantasai> myles: this issue is for removing the locale string
16:46:53 <fantasai> myles: 2 reasons we think it's good idea to remove
16:47:18 <fantasai> myles: 1st, we don't have ability to do this in our platform APIs, can't distinguish language
16:47:38 <fantasai> myles: 2nd is, if dictionaries aren't available for a language we fall back to normal rules, and that's fine, not a deal-breaker
16:47:53 <fantasai> myles: so turn it on for some languages and not others, doesn't help authors and doesn't help implementers
16:48:02 <Rossen_> ack flackr
16:48:06 <Rossen_> ack florian
16:48:12 <fantasai> florian: Doing something like this has been on my to-do list for a long time, so thanks for the push
16:48:21 <fantasai> florian: this is the direction I want to go in as well, and i18nWG as well
16:48:32 <fantasai> florian: as for specific PR, I haven't reviewed yet, and will do this week
16:48:36 <fantasai> florian: needs more work
16:48:54 <fantasai> florian: you extracted some bits to put into word-break, and that's fine, but leftover bits don't make sense
16:49:02 <iank_> From my understanding (i'd need to double check with Koji) I believe we support a new separate value for word-break.
16:49:04 <fantasai> florian: we might actually want to remove the rest of word-boundary-detection entirely
16:49:20 <davidleininger> davidleininger has joined #css
16:49:25 <fantasai> florian: and then there's some shared definitions if we're keeping it, and word-break with new value, so it needs more editorial adjustment
16:49:29 <fantasai> florian: but we're getting somewhere
16:49:34 <fantasai> florian: but I have a question, in the new PR
16:49:38 <fantasai> florian: I've heard argued both ways before
16:49:43 <fantasai> florian: so wondering what you had in mind
16:49:51 <fantasai> florian: You said in intro, "this is for phrase detection"
16:50:07 <fantasai> florian: but there was also suggestion of doing phrase grouping for languages like English, which do space separation
16:50:12 <fantasai> florian: this would e.g. group noun with its article
16:50:22 <fantasai> florian: Are you thinking MAY, MUST NOT, or SHOULD for such languages?
16:50:38 <fantasai> myles: first few topics you describe are editorial, don't need to discuss in WG
16:50:49 <fantasai> myles: last question, our linebreakers right now don't affect Latin scripts
16:50:55 <fantasai> myles: in the future we might want to add support
16:51:03 <fantasai> iank_: same here
16:51:22 <fantasai> florian: so even though this is on my back burner, I will be able to within the week
16:51:26 <fantasai> florian: so I certainly like to do this
16:51:32 <iank_> (I believe we are the same - but I might be wrong - and would have to double check with Koji).
16:51:33 <fantasai> florian: I think we probably also want to ask i18nWG for  part you didn't touch
16:51:44 <fantasai> florian: for languages like Thai, effectively this is already baked in
16:52:02 <fantasai> florian: Thai doesn't use spaces, but it uses dictionary-based word detection to find word breaks
16:52:05 <fantasai> florian: that's by default
16:52:18 <fantasai> florian: but the word-boundary-detection had option to turn that off, in case authors wanted to do it manually
16:52:30 <fantasai> florian: maybe because they are e.g. writing a language that's not quite Thai
16:52:51 <fantasai> florian: so question for i18nWG is, do we want to preserve this ability? in which case we might need a keyword for that in word-break as well
16:53:11 <fantasai> Rossen_: Florian, can't tell if you're diverting resolution?
16:53:21 <fantasai> florian: It's going in the right direction, but not ready yet
16:53:39 <fantasai> myles: Proposal is to remove auto() function from word-boundary-detection and add keyword to word-break
16:53:42 <fantasai> florian: fully support
16:53:49 <fantasai> Rossen_: any additional comments or objections?
16:54:03 <fantasai> RESOLVED: remove auto () from word-boundary-detection, add keyword to word-break for this functionality
16:54:24 <fantasai> Topic: Animating font-palette
16:54:27 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/8922
16:54:47 <drott> Slides: https://docs.google.com/presentation/d/1BFi93NfOUyziJRKciq6lnUOOo1hhgtibE10ZuELzCvo/edit#slide=id.g2554d2a7bfc_1_48
16:55:18 <fantasai> -> www-archive@w3.org
16:55:23 <chris> chris has joined #css
16:55:34 <chris> present+
16:56:05 <fantasai> ???: Hi, I'm Monir, software engineer on Chrome team
16:56:11 <dbaron> s/Monir/Munira/
16:56:23 <fantasai> munira: Current way to animate font-palette is by JS
16:56:48 <fantasai> munira: let's say we want to animate between 2 palettes, in order to do that we need to first anually retriefve color records from font
16:56:51 <fantasai> [slide 2]
16:56:57 <chris> rrsagent, here
16:56:57 <RRSAgent> See https://www.w3.org/2023/06/28-css-irc#T16-56-57
16:57:00 <fantasai> after that, we need to interpolate each color
16:57:04 <dbaron> s/???/munira/
16:57:07 <fantasai> s/after/munira:/
16:57:11 <fantasai> munira: then overrid
16:57:19 <fantasai> munira: if someone can consider color nterpolation space
16:57:31 <fantasai> munira: lastly we need to override the colors from the interpolated values
16:57:48 <fantasai> munira: needs to be done once in each frame of animation process
16:58:06 <fantasai> munira: by making font-palette colors animatable we can animate using CSS
16:58:09 <fantasai> [slide 3]
16:58:22 <fantasai> munira: here you can see disrete vs smooth interpolation
16:58:47 <fantasai> munira: between pink and gray palettes
16:58:57 <tantek> tantek has joined #css
16:58:59 <fantasai> munira: when feature is implemented, can do it easily declaratively in CSS
16:59:01 <fantasai> [slide 4]
16:59:11 <fantasai> munira: here is syntax suggestion
16:59:24 <fantasai> munira: font-palette is represented by custom identifier
16:59:28 <fantasai> munira: and then animated
16:59:41 <fantasai> munira: if we wanted computed style in the middle, what would we get?
16:59:46 <fantasai> munira: we can't currently represent this
16:59:52 <fantasai> [slide 6]
17:00:37 <fantasai> munira: for that we introduce palette-mix() function to represent during animation
17:00:37 <fantasai> [slide 7]
17:00:37 <fantasai> munira: here you can see the syntaxes of the new mix function
17:00:37 <fantasai> munira: it's siimlar to color mix
17:00:39 <fantasai> munira: it should use OKLab for interpolation
17:00:49 <fantasai> munira: unless otherwise specified
17:01:01 <fantasai> munira: we also can introduce a new mix() function
17:01:02 <fantasai> [slide 8]
17:01:08 <fantasai> [slide 9]
17:01:31 <drott> s/we also can introduce a new mix() function/we also can introduce a new animation type, by mix() function/
17:01:35 <fantasai> munira: short version is animating font-palette using JS is complicated, but using the new function web authors can animate just using declarative CSS
17:01:52 <fantasai> munira: if you want to find out more, see GH issue
17:02:17 <fantasai> Rossen_: Thanks for the presentation, and for compressing your presentation, was really great
17:02:25 <fantasai> Rossen_: I'm sorry to press you for time like this
17:02:56 <fantasai> fantasai: What's the relation to the mix() function?
17:03:10 <drott> svgeesus: mix() function wouldn't work for this
17:03:31 <dbaron> svgeesus: ... as tabatkins pointed out in the issue
17:03:33 <fantasai> svgeesus: you're interpolating palettes not colors
17:03:51 <fantasai> fantasai: mix() should work, as long as start and endpoints are representable which they are
17:03:53 <drott> Yes, issue is: https://github.com/w3c/csswg-drafts/issues/8922 - feedback is welcome.
17:04:31 <fantasai> Rossen_: OK, wrapping up
17:04:45 <Rossen_> Zakim, end call
17:04:45 <Zakim> I don't understand 'end call', Rossen_
17:04:51 <Rossen_> Zakim, end meeting
17:04:51 <Zakim> As of this point the attendees have been PaulG, SebastianZ, drott, miriam, munira, argyle, plinss, flackr, bramus, dbaron, vmpstr, dholbert, ydaniv, jensimmons, oriol, chris
17:04:55 <Zakim> RRSAgent, please draft minutes v2
17:04:56 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/28-css-minutes.html Zakim
17:05:03 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
17:05:03 <castastrophe> present+
17:05:03 <Zakim> Zakim has left #css
17:05:03 <jfkthame> present+
17:07:59 <drott> Slides archive link: https://lists.w3.org/Archives/Public/www-archive/2023Jun/0004.html
17:10:46 <gtalbot> gtalbot has joined #css
17:12:52 <chris> RRSAgent, draft minutes v2
17:12:53 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/28-css-minutes.html chris
17:48:35 <gtalbot> gtalbot has left #css
18:57:42 <gtalbot> gtalbot has joined #css
18:59:06 <gtalbot> gtalbot has left #css
21:07:35 <antonp> antonp has joined #css
22:26:15 <jfkthame> jfkthame has joined #css
23:16:38 <jfkthame> jfkthame has joined #css