00:03:03 <florian_irc> florian_irc has joined #css
00:03:17 <janina1> janina1 has joined #css
00:12:00 <tantek> tantek has joined #css
00:16:31 <Francis_Storr> Francis_Storr has joined #css
00:21:20 <florian_irc> florian_irc has joined #css
00:24:05 <karlcow> karlcow has joined #css
00:35:33 <janina1> janina1 has joined #css
00:39:59 <florian_irc> florian_irc has joined #css
00:45:16 <hypebea34> hypebea34 has joined #css
00:53:15 <janina1> janina1 has joined #css
00:54:37 <nigel> nigel has joined #css
00:57:45 <florian_irc> florian_irc has joined #css
01:00:50 <nigel> nigel has joined #css
01:04:03 <hypebeatsmagazine> hypebeatsmagazine has joined #css
01:08:23 <hypebeatsmagazine> hypebeatsmagazine has joined #css
01:09:19 <Adam_Page> Adam_Page has joined #css
01:11:16 <hypebea94> hypebea94 has joined #css
01:13:48 <florian_irc> florian_irc has joined #css
01:32:37 <florian_irc> florian_irc has joined #css
01:42:56 <hypebeatsmagazine> hypebeatsmagazine has joined #css
01:49:07 <florian_irc> florian_irc has joined #css
02:01:47 <nigel> nigel has joined #css
02:02:18 <nigel> nigel has joined #css
02:05:36 <florian_irc> florian_irc has joined #css
02:19:26 <Francis_Storr> Francis_Storr has joined #css
02:23:36 <florian_irc> florian_irc has joined #css
02:42:29 <florian_irc> florian_irc has joined #css
02:59:08 <florian_irc> florian_irc has joined #css
03:01:17 <Francis_Storr> Francis_Storr has joined #css
03:02:58 <nigel> nigel has joined #css
03:17:59 <florian_irc> florian_irc has joined #css
03:36:07 <florian_irc> florian_irc has joined #css
03:56:40 <florian_irc> florian_irc has joined #css
03:57:55 <Francis_Storr> Francis_Storr has joined #css
04:03:38 <nigel> nigel has joined #css
04:18:41 <florian_irc> florian_irc has joined #css
04:37:42 <florian_irc> florian_irc has joined #css
04:55:13 <florian_irc> florian_irc has joined #css
05:04:36 <nigel> nigel has joined #css
05:05:11 <nigel> nigel has joined #css
05:21:17 <nigel> nigel has joined #css
05:43:50 <karlcow> karlcow has joined #css
06:05:47 <nigel> nigel has joined #css
06:07:32 <tpac-breakout-bot> tpac-breakout-bot has joined #css
06:07:32 <tpac-breakout-bot> Zakim, bye
06:07:32 <tpac-breakout-bot> RRSAgent, bye
06:07:32 <RRSAgent> I see no action items
06:07:32 <Zakim> Zakim has left #css
06:07:32 <Zakim> leaving.  As of this point the attendees have been noamr, khush, vmpstr, flackr, fserb, +, ydaniv, wendyreid, hdv, mustaq, rachelandrew, oriol, cyns, BrianE, bkardell_,
06:07:32 <Zakim> ... Patrick_H_Lauke, kzms, CurtBellew, aardrian, alisonmaher, kbabbitt, dholbert, gregwhitworth, estelle, JJ, Rain, moonira, zcorpan, miriam
15:51:24 <RRSAgent> RRSAgent has joined #css
15:51:24 <RRSAgent> logging to https://www.w3.org/2024/09/26-css-irc
15:51:30 <Zakim> RRSAgent, make logs Public
15:51:31 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:55:40 <florian_irc> florian_irc has joined #css
15:56:06 <github-bot> github-bot has joined #css
15:57:31 <Francis_Storr> Francis_Storr has joined #css
15:58:05 <florian_irc> florian_irc has joined #css
15:58:39 <romain> romain has joined #css
15:58:53 <hypebeatsmagazine> hypebeatsmagazine has joined #css
16:00:32 <futhark> futhark has joined #css
16:00:37 <TabAtkins> Be there in one second, at the elevators
16:01:30 <kbabbitt> kbabbitt has joined #css
16:02:26 <janina1> janina1 has joined #css
16:02:31 <oriol> oriol has joined #css
16:03:05 <kizu> kizu has joined #css
16:04:15 <masonf> masonf has joined #css
16:05:03 <kizu> kizu has joined #css
16:05:32 <emeyer> emeyer has joined #css
16:05:37 <moonira> moonira has joined #css
16:05:56 <Adam_Page> Adam_Page has joined #css
16:05:57 <Penny> Penny has joined #css
16:06:19 <karlcow> karlcow has joined #css
16:06:33 <emeyer> present+
16:06:35 <moonira> present+
16:06:36 <emeyer> scribe+
16:06:39 <dbaron> Present+
16:06:42 <kizu> present+
16:06:51 <kbabbitt> present+
16:06:57 <bts> bts has joined #css
16:07:02 <bts> present+
16:07:07 <matthieud> matthieud has joined #css
16:07:19 <romain> present+
16:07:21 <Penny> present+
16:07:22 <flackr> present+
16:07:24 <ydaniv> ydaniv has joined #css
16:07:32 <ydaniv> present+
16:07:33 <sgill> sgill has joined #css
16:07:38 <rachelandrew> present+
16:07:41 <matthieud> present+
16:07:42 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9350
16:07:42 <github-bot> Topic: Proposal: Custom CSS Functions & Mixins
16:07:42 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9350.
16:07:45 <oriol> present+
16:07:45 <dholbert> present+
16:07:47 <ethanjv> ethanjv has joined #css
16:08:42 <futhark> present+
16:09:38 <miriam> present+
16:09:43 <sgill> sgill has joined #css
16:09:50 <sgill> present+
16:10:09 <chrishtr> present+
16:10:48 <alisonmaher> alisonmaher has joined #css
16:10:52 <alisonmaher> present+
16:10:54 <masonf> present+
16:11:12 <astearns> topic: intersection observer
16:11:17 <castastrophe> present+
16:11:45 <bkardell_> present+
16:12:34 <emeyer> emilio: In discussion with webapps this week, most topics end up with intersectionobserver not being in the WG
16:12:50 <emeyer> …They ask what we think about adopting another spec
16:13:07 <emeyer> …I’m hoping there’s not too much issue with us taking it on
16:13:26 <emeyer> astearns: I did see an issue where someone raised the question of whether it should be moved here or made a joint deliverable
16:13:36 <TabAtkins> joint deliverables are annoying to work with, if we can avoid it...
16:13:37 <emeyer> emilio: I don’t think anyone there wants it to be a joint deliverable
16:13:48 <emeyer> astearns: Opinions?
16:13:55 <emeyer> chrishtr: I’m in favor
16:13:55 <TabAtkins> +1 to taking it on, the questions are mostly relevant for csswg
16:14:06 <emeyer> fantasai: Makes sense to me, but we probably need a charter amendment for that
16:14:15 <emeyer> astearns: Good point; we are rechartering very soon
16:14:18 <lea> present+
16:14:32 <emeyer> …Let’s resolve that we’ll add intersectionobserver to the new charter that’s being prepared
16:14:39 <emeyer> emilio: Sounds good
16:15:00 <emeyer> astearns: Any concerns about adding to our pile of specs?  Any objections?
16:15:02 <emeyer> (silence)
16:15:04 <bts> bts has joined #css
16:15:20 <emeyer> RESOLVED: Adopt intersectionObserver in our next chartering period
16:15:36 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9350
16:15:36 <github-bot> Topic: Proposal: Custom CSS Functions & Mixins
16:15:36 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9350.
16:15:59 <emeyer> TabAtkins: We agreed to take on functions & mixins specification
16:16:15 <emeyer> …At this point, we have a first-draft spec for functions, but not mixins
16:16:27 <emeyer> …Not looking for resolutions, just a quick runthrough
16:16:40 <kschmi> kschmi has joined #css
16:16:57 <emeyer> …Custom functions are defined using an @function rule with a double-dashed identifier
16:17:21 <emeyer> …Something it resolved, a value is passed in, calculations are done, the result is passed out
16:17:27 <emeyer> …The full syntax is a little larger
16:17:36 <emeyer> …IN addition to a parameter list, there’s a dependency list
16:17:50 <emeyer> …Particularly from Lea’s feedback, it’s common to want to use defined system variables
16:17:59 <emeyer> …Having to pass them to every function is frustrating
16:18:10 <emeyer> …Functions can declare they will implicitly pull in extra variables
16:18:30 <emeyer> …Can also declare its return type
16:18:43 <emeyer> …If the custom function resolves to the wrong thing, we can detect that and act on it
16:19:00 <emeyer> …After the fact, if we see something wrong, we invalidate
16:19:10 <emeyer> …at use time
16:19:11 <tantek> tantek has joined #css
16:19:22 <lea> q+
16:19:31 <akeerthi> akeerthi has joined #css
16:19:33 <emeyer> …Just like in the other descriptor, if there are multiple results, the last one is what resolves to the value
16:19:44 <emeyer> …Conditional rules are permitted
16:19:53 <tantek> present+
16:19:57 <emeyer> …Things like media queries can go inside
16:20:26 <kbabbitt> draft is at https://drafts.csswg.org/css-mixins-1/
16:20:32 <emeyer> florian: Local variables, order doesn’t matter?
16:20:45 <emeyer> TabAtkins: Correct, they’re orderless
16:21:03 <emeyer> florian: I suspect this is correct, but is likely to confuse
16:21:13 <emilio> q+
16:21:21 <emeyer> TabAtkins: We hope that the fact it looks like regular styles will guide people to the right behavior
16:22:21 <emeyer> lea: SSometimes you need to access certain contexts, but the grammar looks to me like it’s easier to pass in by using
16:22:30 <emeyer> TabAtkins: You don’t pass in anything that way
16:22:44 <emeyer> …They’re automatically added to arguments at the call site
16:22:55 <emeyer> lea: It might be useful to have an aggregate syntax
16:23:04 <emeyer> TabAtkins: Please open an issue for that
16:23:57 <emeyer> s/SSometimes/Sometimes/
16:24:11 <astearns> ack lea
16:24:15 <emeyer> TabAtkins: We have a return type for the function itself
16:24:15 <lea> q+
16:24:23 <emeyer> …You can also declare grammars for individual arguments
16:24:31 <emeyer> …If you call with the wrong thing, it will invalidate the functoin
16:24:44 <emeyer> …There’s a syntax that looks like CSS grammar
16:24:55 <florian> q+ to ask what happens if you have multiple return descriptors and only one of them matches the declared type
16:24:57 <emeyer> …Authors don’t like wrapping in a string
16:25:01 <astearns> q+
16:25:13 <emeyer> …Basically, the grammar looks like custom property registrations
16:25:30 <emeyer> …There’s no change in functionality, but you don’t need to wrap in quotes
16:25:32 <lea> q+ to ask about system colors (canvas, canvastext) and currentcolor, relative units
16:25:50 <emeyer> …So you declare functions, they can use conditional queries
16:26:08 <emeyer> …If you rewrite appropriately, this should be equivalent to dropping in a nesting block
16:26:18 <Penny> (There is a noise suppression setting on the Zoom control panel set to enabled, but making changes is password protected. We'll need to engage tech support to disable it.)
16:26:25 <emeyer> …Questions?
16:26:59 <emeyer> emilio: This is a descriptor, not a property?
16:27:01 <emeyer> TabAtkins: Right
16:27:19 <emeyer> emilio: We need to sort out how this operates on the CSSOM
16:27:28 <emeyer> TabAtkins: Yeah, there could be some clashes there
16:27:35 <andreubotella> andreubotella has joined #css
16:27:43 <emeyer> emilio: This should look a lot like a style rule, right?
16:27:52 <emeyer> TabAtkins: Body will be llike a style declaration
16:28:03 <emeyer> emilio: That makes implementation... fun, but okay
16:28:09 <emeyer> s/llike/like/
16:28:28 <emeyer> lea: Making sure, system colors would resolve based on the color scheme when this is used?
16:28:36 <astearns> ack emilio
16:28:38 <astearns> ack lea
16:28:38 <Zakim> lea, you wanted to ask about system colors (canvas, canvastext) and currentcolor, relative units
16:28:40 <emeyer> TabAtkins: Yes, they’re based on the element the function is applied to
16:29:08 <matthieud> q+
16:29:08 <emeyer> …Because of the clash between functions and wider variables, vars in the body are references to (missed by scribe)
16:29:19 <astearns> ack florian
16:29:19 <Zakim> florian, you wanted to ask what happens if you have multiple return descriptors and only one of them matches the declared type
16:29:43 <lea> q+ to say the current grammar for using allows declaring types, is that intentional?
16:29:46 <emeyer> florian: If you have declared integer type and multiple returns, do you check them all against type and return the last valid or only check the last one returned against the type?
16:29:54 <emeyer> TabAtkins: I’m not sure, but I think we have flexibility
16:29:56 <fantasai> I think we want to match the type.
16:30:11 <emeyer> …We want to be consistent with other things so probably the second, but we’re not locked in either way
16:30:38 <emeyer> fantasai: I think we should take the last one that does match the type
16:31:00 <romain> +1
16:31:01 <emeyer> …They might try to do forward opt-in, which would break if we don’t do it that way
16:31:13 <kbabbitt> +1 fantasai
16:31:19 <astearns> ack astearns
16:31:25 <emeyer> astearns: The new non-string representation will also be available for custom property registration?
16:31:28 <emeyer> TabAtkins: Yes
16:31:30 <astearns> ack matthieud
16:31:45 <emeyer> matthieud: Can you only define functions at the root?
16:32:12 <emeyer> …And if it’s allowed, (missed by scribe)
16:32:30 <emeyer> TabAtkins: They are global and we don’t have a way to store the function and use it elsewhere
16:32:40 <astearns> s/(missed by scribe)/(something about closures)
16:32:53 <emeyer> lea: If they’re global only, we should not allow them to nest so we have options later
16:33:03 <emeyer> …Same for mixins, where scope is valuable
16:33:05 <fantasai> s/(missed by scribe)/can we do closures/
16:33:20 <astearns> ack lea
16:33:21 <Zakim> lea, you wanted to say the current grammar for using allows declaring types, is that intentional?
16:33:28 <emeyer> …THe using grammar allows types, is that intentional?
16:33:33 <emeyer> TabAtkins: Yes
16:33:43 <emeyer> lea: How does that work if it’s a registered variable?
16:33:51 <emeyer> TabAtkins: It still has the token representation
16:34:00 <emeyer> lea: So you could recast to a different type
16:34:08 <emeyer> TabAtkins: You can already do that by subbing
16:34:08 <keithamus> q?
16:34:09 <keithamus> q+
16:34:13 <miriam> q+
16:34:45 <astearns> ack keithamus
16:34:47 <emeyer> keithamus: Curious how these translate across shadow boundaries
16:34:48 <fantasai> s/subbing/subbing a registered variable into an unregistered variable and re-subbing into a differently-registered variable/
16:34:53 <emeyer> TabAtkins: It’s a great question
16:35:12 <emeyer> …Been thinking how to expose shadow DOM, and the answer should work but what that means exactly is undefined
16:35:21 <emeyer> …BY the time this ships we should have a reasonable answer
16:35:25 <astearns> ack miriam
16:35:46 <emeyer> miriam: Are we saying the types in the parameter list are not just for validation, they’re actually setting the type of what comes in?
16:35:58 <emeyer> TabAtkins: No, they just validate, they don’t otherwise change behavior
16:36:09 <emeyer> …We don’t have a way to trigger animations from within a function
16:36:26 <emeyer> astearns: Any other questions?
16:36:43 <emeyer> …I’m assuming this mostly spec noodling
16:36:51 <emeyer> TabAtkins: Right, nothing is imminent
16:36:59 <emeyer> astearns: Are there any resolutions you need?
16:37:02 <emeyer> TabAtkins: No
16:37:19 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9359
16:37:19 <github-bot> Topic: [css-fonts] Drop the emoji font-family
16:37:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9359.
16:37:55 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9539
16:37:57 <github-bot> Topic: [css-values-5][various] Better handling of arguments with commas
16:37:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9539.
16:38:33 <emeyer> TabAtkins: We discussed how to deal with argument values that might have commas in them
16:38:42 <emeyer> …We did a straw poll that ended in a tie, and did a runoff
16:39:07 <emeyer> …That resulted in upgradeable commas, where you can replace commas as semicolons
16:39:24 <emeyer> …This works, but upon more thought, we would like revisit this decision and go with the other thing that got first place
16:40:09 <emeyer> …The option we want to go with instead is to use a curly brace wrapper around the values
16:40:46 <emeyer> …So if you write an if with a comma-separated condition, you write it like this (shows syntax from comment on issue)
16:41:18 <emeyer> …So it can either be a single curly brace block containing anything that’s valid, or it’s a sequence of component values
16:41:37 <emeyer> …This way as long as you’re doing anything fancy, you can just write the fuction exactly as you would elsewhere
16:41:52 <emeyer> …An argument with commas gets marked as being a special thing
16:42:14 <emeyer> …In the original version, you use quoted strings separated by commas
16:42:32 <emeyer> …YOu can end up with one thing being valid and one not valid, and you can only fix it with a trailing comma
16:42:46 <emeyer> …This is bad
16:42:51 <emeyer> s/YOu/You/
16:43:09 <emeyer> …It looks bad and it’s inconsistent with other things
16:43:22 <emeyer> …The curly braces make it clear where the complicated bits start and stop
16:43:37 <emeyer> …This also makes other issues easier
16:43:47 <emeyer> …There are a few parsing questions about how this would apply to var()
16:43:55 <emeyer> …They’re arcane
16:44:03 <oriol> q+
16:44:10 <emeyer> …So we’d like to change to curly brace wrapping and resolve on that instead
16:44:25 <astearns> ack oriol
16:44:42 <emeyer> oriol: I agree the commas were not a great decision, but I have a mild preference for the original idea to require semicolons
16:45:02 <emeyer> …It avoids authors thinking if they use a var(), maybe the value is something typical
16:45:31 <emeyer> …But the semicolons has some downsides so I’m okay with doing this
16:45:53 <alisonmaher> alisonmaher has joined #css
16:46:05 <emeyer> TabAtkins: Oriol’s pointing out authors had to memorize the special-casde syntax even if they didn’t often use it
16:46:19 <kizu> kizu has joined #css
16:46:22 <emeyer> …This is what turned us against it; we wanted something lower-touch
16:46:54 <emeyer> TabAtkins: (shows an example of the older syntax)
16:47:00 <emeyer> s/casde/case/
16:47:16 <lea> q?
16:47:56 <emeyer> TabAtkins: This would have required defensive coding, but that’s kind of true of any syntax we decide to use
16:48:15 <emeyer> …The only one that avoids it is “always use semicolons” but we rejected that for other reasons
16:48:22 <lea> q+ to say agree that a wrapping construct is better than upgradable commas. The natural option here is bare parens, and I don't buy the argument that we should contort our syntax *forever* to accommodate a preprocessor, especially now that its popularity is dwindling
16:48:32 <astearns> ack lea
16:48:32 <Zakim> lea, you wanted to say agree that a wrapping construct is better than upgradable commas. The natural option here is bare parens, and I don't buy the argument that we should contort
16:48:35 <Zakim> ... our syntax *forever* to accommodate a preprocessor, especially now that its popularity is dwindling
16:48:35 <ethanjv> ethanjv has joined #css
16:49:09 <emeyer> lea: I agree that upgradable commas are weird and wrapping constructs are much better
16:49:28 <ydaniv> ydaniv has joined #css
16:49:39 <emeyer> …For the best wrapping construct would be, we can discuss options but I agree that bare parentheses are the natural option
16:49:54 <emeyer> …We should not contort CSS syntax forever
16:50:25 <emeyer> …The choice to prioritize Sass syntax over natural syntax seems weird
16:50:49 <gsnedders> gsnedders has joined #css
16:50:59 <emeyer> TabAtkins: We used quare brackets in Grid because it was easier at the time
16:51:23 <emeyer> …Here, bare parentheses were proposed and it was pointed out we’d decided against that in the past and didn’t want to revisit that
16:51:38 <kizu> q+
16:51:41 <miriam> q+
16:51:43 <emeyer> …I don’t think there’s an overriding reason to go back and revisit our decision to avoid those
16:51:54 <astearns> ack kizu
16:51:57 <emeyer> kizu: +1 to Lea
16:52:08 <emeyer> …I think plain parentheses would be better
16:52:21 <emeyer> …Curly braces mean a block in CSS
16:52:24 <dbaron> (I agree that wrapping is better than trailing semicolons as a defensive technique, for what it's worth.)
16:52:49 <lea> bare parens are the quintessential grouping construct. No braces, brackets, or function compares to the natural ergonomics of bare parens for this. IMO
16:52:52 <emeyer> (scribe having trouble making out what’s being said)
16:53:08 <emeyer> …I do want to use commas with braces
16:53:21 <astearns> ack miriam
16:53:39 <emeyer> miriam: I think the same can be said the other way about parentheses in CSS< which are only used on function and calculations
16:53:46 <lea> q?
16:53:50 <emeyer> …This stands out as being different and looking different
16:53:52 <astearns> ack fantasai
16:54:12 <lea> q+ to say in every prog lang parens are used for functions and grouping, this is not new
16:54:22 <emeyer> fantasai: The advantage of curly braces is it leaves parentheses to be used for something more useful than “we needed to escape commas here”
16:54:30 <tantek> +1 dbaron, lea
16:54:52 <emeyer> …I don’t think we should take a syntax that could be much more useful here
16:55:05 <ntim> `toggle(« Arial, Helvetica, sans-serif », « Times, serif »)` :D
16:55:08 <emeyer> lea: I don’t see it as escaping, I see it as grouping
16:55:21 <emeyer> …In every popular language, parentheses are used for grouping
16:55:28 <emeyer> …We do that inside our own calc()
16:55:48 <emeyer> …If we end up deciding other constructs are better, regardless of the Sass problem, there’s no Sass problem in the first place
16:55:59 <astearns> q?
16:56:02 <astearns> ack lea
16:56:02 <Zakim> lea, you wanted to say in every prog lang parens are used for functions and grouping, this is not new
16:56:15 <emeyer> TabAtkins: Because the reasons for the original Sass allowances are valid and are even more so here, Chrome would object to using parentheses for this case regardless
16:56:17 <akeerthi> akeerthi has joined #css
16:56:23 <emeyer> q?
16:56:56 <emeyer> astearns: We have two options, each with champions, and one has an objection
16:57:07 <emeyer> …Is there anyone who would object to curly braces
16:57:18 <emeyer> lea: There are other options like square brackets
16:57:35 <emeyer> fantasai: Square brackets aren’t an option because you’d have to escape them
16:57:46 <emeyer> TabAtkins: You wouldn’t but other options lost to curly braces
16:58:03 <emeyer> …in the original poll
16:58:04 <fantasai> s/escape them/escape them in grid/
16:58:06 <TabAtkins> TabAtkins: Chrome doesn't object to the other options, but {} won the original poll
16:58:11 <romain> Curly brackets look quite nice in this example by kizu for inline conditions : https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2373483709
16:58:13 <lea> Option 1: Bare ()
16:58:13 <lea> Option 2: {}
16:58:13 <lea> Option 3: []
16:58:13 <lea> Option 4: Function e.g. value(), val(), arg(), item()
16:58:20 <emeyer> astearns: It’s not clear to me that the options for parentheses transfeer to square brackets
16:58:35 <emeyer> …It’s another grouping mechanism
16:58:35 <ntim> 2
16:58:38 <fantasai> 2
16:58:42 <romain> 2
16:58:44 <kbabbitt> 2
16:58:45 <lea> 3
16:58:45 <emeyer> s/transfeer/transfer/
16:58:47 <ethanjv> 2
16:58:49 <moonira> 2
16:58:55 <chrishtr> 2
16:58:56 <alisonmaher> 2
16:58:59 <kizu> 4
16:59:01 <emeyer> …Looks like we’re doing a straw poll; Lea put options into IRC
16:59:02 <miriam> 2
16:59:03 <TabAtkins> 2
16:59:07 <keithamus> 2/3
16:59:12 <Penny> 2
16:59:13 <emeyer> …Please put in a number corresponding to your preference
16:59:14 <astearns> 2
16:59:17 <futhark> 4
16:59:18 <lea> actually 3/4 for me
16:59:30 <dbaron> 2
16:59:34 <vmpstr> abstain
16:59:37 <rachelandrew> 2
16:59:39 <dholbert> abstain
16:59:41 <ydaniv> abstain
16:59:41 <emeyer> abstain
16:59:43 <castastrophe> 2
16:59:46 <masonf> abstain
17:00:03 <kzms2> kzms2 has joined #css
17:00:04 <emeyer> astearns: Poll looks pretty clear toward curly brackets
17:00:09 <oriol> Preference for requiring semicolons. But 2 among the above.
17:00:15 <emeyer> …Is there anyone who would object to that option?
17:00:21 <emeyer> (silence)
17:00:34 <emeyer> …Given the straw poll, I suggest we resolve on using curly braces
17:00:48 <emeyer> …Objections?
17:01:13 <emeyer> astearns: Hearing none, we will undo the previous resolution
17:01:54 <emeyer> RESOLVED: Undo previous decision and move forward with optional curly-brace wrapping of complex arguments
17:02:15 <emeyer> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10064
17:02:15 <github-bot> Topic: [css-values-5] What is the MVP for inline conditionals on custom properties?
17:02:15 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10064.
17:02:38 <emeyer> lea: In June, we resolving to work on inline conditionals
17:02:53 <emeyer> …There were syntax disagreements, but we seem to be converging on a specific option
17:03:10 <lea> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2372578597
17:03:17 <emeyer> …There were disagreements about else being optional or mandatory
17:03:28 <emeyer> …How does it resolve, what should separators be
17:03:40 <emeyer> …Converging on an else clause that it spelled out
17:03:55 <emeyer> …If the else is omitted and nothing matches, it decomposes to a token stream
17:04:11 <emeyer> …Right now, we need a resolution for that and for waht the separator should be
17:04:28 <emeyer> …We think there’s value in having a different separator for the condition and the values
17:04:38 <kbabbitt> q+
17:04:46 <emeyer> …Tab suggests colons, I suggest question marks
17:05:17 <kizu> q+
17:05:34 <emeyer> kbabbitt: I think as written, it allows multiple elses
17:05:59 <emeyer> …There’s also a proposal in the thread to drop separators and I like it, I think it looks cleaner
17:06:22 <emeyer> TabAtkins: This does allow an else to be put anywhere; it’s sometimes useful when debugging
17:06:34 <astearns> ack kbabbitt
17:06:41 <emeyer> …I think it’s valuable to have the ability to do that
17:06:44 <lea> essentially else is just another way to say true, right?
17:06:54 <fantasai> the only way? :)
17:07:06 <emeyer> …For Roman’s proposal, he’s using curly braces, which aren’t required
17:07:12 <lea> we should have true and false constants for <boolean>...
17:07:13 <emeyer> …There is no grammatical reason for the separator
17:07:26 <emeyer> …They’re meant to guide the eye to separators
17:07:41 <emeyer> …Oh wait no, not true
17:07:55 <emeyer> …If you have max-width and something, it could get greedy
17:08:04 <emeyer> …So we do need something
17:08:08 <lea> not to mention in the future <decl-value> could include <boolean> too
17:08:26 <astearns> ack kizu
17:08:27 <emeyer> …to be a separator
17:09:06 <emeyer> kizu: If we’re settled on curly braces, making them necessary so we can use colon and question mark
17:09:50 <emeyer> …If choosing between colon and question mark, I would choose colon
17:10:22 <emeyer> …My proposal looks more like CSS in my opinion
17:10:38 <keithamus> q?
17:10:53 <oriol> q+
17:11:02 <emeyer> TabAtkins: We’d like a resolution on this grammar looking good with a quick poll on the separator value
17:11:03 <astearns> ack fantasai
17:11:10 <kbabbitt> q+
17:11:14 <emeyer> fantasai: Can we go through the questions you were debating?
17:11:43 <lea> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2368914947
17:12:18 <emeyer> lea: I think we need to consider both short and long ifs
17:12:45 <fantasai>     Separator between condition and values (? vs :)
17:12:45 <fantasai>     Separator between value if true and value if false (; vs ,/; vs :)
17:12:45 <fantasai>     Trailing separator allowed? (mainly with ; syntaxes)
17:12:45 <fantasai>     Mandatory or optional else?
17:12:45 <fantasai>         If optional: what happens if nothing matches? Empty token or IACVT?
17:12:56 <lea> s/I think we need to consider both short and long ifs/in considering syntax options, one should think of *both* very short conditionals (possibly with a single value consisting of many of them)/
17:14:25 <emeyer> TabAtkins: The problem with not requiring `else` when there’s an else, you could get parsing problem
17:14:43 <emeyer> …Lea and I decided it was okay to require the else because it’s unambiguous
17:15:06 <keithamus> q+
17:15:19 <emeyer> …The subissue is whether a missing fallback else leads to empty token or IACVT
17:16:01 <flackr> q+
17:16:13 <lea> lea: What is the use case for triggering IACVT intentionally? Remember if your whole value is if() you get that anyway
17:16:24 <emeyer> astearns: We should go to the queue and then try to get resolutions for remaining questions
17:16:31 <lea> lea: Whereas there are many use cases for getting an empty token stream
17:17:00 <emeyer> fantasai: I would like an explkicit resolution on each of the raised questions
17:17:15 <emeyer> astearns: If you have concerns on any of the decisions, they should be raised as separate issues
17:17:27 <emeyer> oriol: I like the proposal of using curly braces
17:17:45 <emeyer> …As I understand it, the curly braces would be required and we would comma-separate cases
17:17:56 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2373483709
17:18:02 <emeyer> kizu: This is correct
17:18:15 <emeyer> TabAtkins: I’m uncomfortable with not separating cases
17:18:32 <fantasai> s/cases/arguments in a list of arguments with a comma/
17:18:36 <emeyer> astearns: I suggest that become a separate issue
17:18:38 <astearns> ack keithamus
17:18:46 <astearns> ack oriol
17:18:48 <astearns> ack kbabbitt
17:19:11 <emeyer> kbabbitt: I advocated for the curly braces but I like the comma syntax looking like a declaration block
17:19:31 <emeyer> …I lean toward comma between values, semicolon between blocks
17:19:52 <emeyer> …I think the else should be optional
17:20:04 <emeyer> s/optional/mandatory/
17:20:22 <lea> My position was: As long as else is optional, I don't think it's a big imposition to label it explicitly.
17:20:39 <emeyer> keithamus: The question token looks strange if else is mandatory
17:20:52 <kbabbitt> s/comma between values/colon between condition and value/
17:21:05 <emeyer> …The colon fits well with the grammar as I understand it
17:21:10 <kbabbitt> s/else should be optional/else should be mandatory/
17:21:23 <emeyer> …Empty token vs IACVT; is the token something we can reason about?
17:21:49 <emeyer> …If you have a custom property that evaluates to an empty token, you could reason about it with another custom property to provide a fallback
17:22:02 <emeyer> TabAtkins: I don’t think that works, but it depends on what conditions are allowed
17:22:16 <emeyer> keithamus: I think that should be considered
17:22:24 <emeyer> TabAtkins: I would love to see that as an issue with a simple use case
17:22:27 <astearns> ack flackr
17:22:43 <emeyer> flackr: Is there an easy way to get the value that’s in the cascade before the property?
17:22:50 <emeyer> …I can see that would be useful
17:23:04 <emeyer> TabAtkins: I suspect the answer is, whatever style queries can do
17:23:08 <emeyer> …SO I think not right now
17:23:24 <emeyer> …I don’t know how much I want to divert from other queries right now
17:23:58 <emeyer> flackr: If you didn’t specify else, and no conditions matched, we could use the value that would have been used without the custom
17:24:06 <emeyer> TabAtkins: That runs into a proposal by Lea
17:24:37 <emeyer> fantasai: Want to point out that colon and semicolon that follows an existing pattern we have a lot of
17:24:45 <kizu> +1 to `if(cond(): foo; else: bar)`, this was in my other earlier comment in the issue (require mandatory `;` as a separator, not an upgradable one)
17:24:55 <emeyer> …If we want to use commas, it probably makes more sense to use question marks
17:24:59 <lea> https://www.irccloud.com/pastebin/4Zx0VWlX/
17:25:09 <lea> Option 1: ?
17:25:11 <lea> Option 2: :
17:25:16 <ethanjv> 2
17:25:17 <vmpstr> 2
17:25:19 <emeyer> astearns: Straw polling on separators
17:25:19 <alisonmaher> 2
17:25:19 <kizu> 2
17:25:19 <TabAtkins> 2
17:25:19 <romain> 1
17:25:19 <jarhar> jarhar has joined #css
17:25:19 <lea> 1
17:25:19 <flackr> 2
17:25:19 <ydaniv> 2
17:25:20 <kbabbitt> 2
17:25:20 <fantasai> 1
17:25:21 <moonira> 2
17:25:22 <miriam> 2
17:25:22 <astearns> 2
17:25:23 <chrishtr> 2
17:25:27 <Penny> 2
17:25:32 <keithamus> 2
17:25:33 <jarhar> 2
17:25:33 <matthieud> abstain
17:25:34 <oriol> 2. Wouldn't mind {} either
17:25:35 <futhark> 2
17:25:35 <dholbert> abstain
17:25:37 <emeyer> abstain
17:25:38 <masonf> abstain
17:25:41 <andreubotella> abstain
17:25:52 <fantasai> I would be OK with `:` if we were using `;` as a separator, but `:` and `,` is weird.
17:26:07 <dbaron> abstain
17:26:08 <akeerthi> akeerthi has joined #css
17:26:31 <emeyer> astearns: We can decide on colon for now; are we also going to straw poll the separator?
17:26:36 <emeyer> TabAtkins: We can
17:26:43 <ydaniv> +1 for fantasai
17:26:48 <ntim> I like `:` and `,` personally
17:27:11 <emeyer> fantasai: I think commas as a separator makes sense, but pairing them with colons is weird because of the way the rest of CSS works
17:27:25 <emeyer> …So I think they should be considered as a set
17:27:41 <lea> Option 1: if(test? v1, v2)
17:27:41 <lea> Option 2: if(test: v1, v2)
17:27:42 <emeyer> …That’s what’s reading weird to me
17:28:23 <sgill> sgill has joined #css
17:28:42 <emeyer> …In isolation, any combination is fine, but in context it’s weird to invert the precedence of these
17:28:44 <kizu> +1 to fantasai
17:28:56 <futhark> +1 to fantasai
17:28:56 <emeyer> astearns: Anyone who voted 2 and is convinced by Elika’s argument?
17:28:56 <vmpstr> +1
17:29:29 <emeyer> flackr: What are the options?
17:29:45 <lea> Option 1: if(test? v1, v2)
17:29:48 <lea> Option 2: if(test: v1, v2)
17:30:02 <lea> 1
17:30:04 <TabAtkins> 1) if(cond()? foo, else? bar)
17:30:04 <TabAtkins> 2) if(cond(): foo, else: bar)
17:30:04 <TabAtkins> 3) if(cond(): foo; else: bar)
17:30:15 <kizu> 3
17:30:17 <flackr> 3
17:30:17 <futhark> 3
17:30:17 <fantasai> 1 or 3
17:30:18 <TabAtkins> 2
17:30:18 <kbabbitt> 3
17:30:18 <moonira> 3
17:30:19 <vmpstr> 3
17:30:19 <astearns> 3
17:30:20 <keithamus> 3
17:30:20 <romain> 1 or 3
17:30:21 <ydaniv> 3
17:30:25 <ethanjv> 3
17:30:27 <dbaron> 3
17:30:28 <bts> bts has joined #css
17:30:31 <chrishtr> 3
17:30:32 <masonf> 3
17:30:32 <emeyer> astearns: Votes are according to Tab’s options
17:30:34 <alisonmaher> 3
17:30:36 <miriam> 1 or 3 equally
17:30:43 <emilio> 2 or 3
17:30:45 <ntim> 2 > 3
17:30:45 <oriol> 2 or 3
17:30:48 <kschmi> 3
17:30:53 <emeyer> 3
17:31:05 <emeyer> astearns: The 3’s have it
17:31:19 <TabAtkins> winner: if(cond(): foo; else: bar)
17:31:25 <emeyer> …We will use colons and semicolons; any objections?
17:31:41 <emeyer> RESOLVED: We will use if(cond(): foo; else: bar)
17:31:52 <keithamus> (regarding the decision of empty vs IACTV https://github.com/w3c/csswg-drafts/issues/10956)
17:31:55 <emeyer> fantasai: We could resolve on mandatory else
17:32:03 <emeyer> TabAtkins: We have to do that
17:32:36 <emeyer> fantasai: We could resolve that if you have an else clause, you must say else explicitly
17:32:42 <emeyer> astearns: Any objections?
17:32:43 <emeyer> (silence)
17:32:58 <emeyer> RESOLVED: If you have an else clause, you must say `else` explicitly
17:33:02 <oriol> q+
17:33:06 <astearns> ack fantasai
17:33:47 <emeyer> keithamus: I don’t know which one of the two options I stated in the issue should be available syntax
17:33:50 <astearns> ack oriol
17:34:18 <lea> IACVT if nothing matches means you cannot do things like background: if(test, yellow) if(test, linear-gradient(...) top);
17:34:19 <emeyer> oriol: If we are going with semicolon separator between cases, are we requiring that inside curly braces??
17:34:28 <emeyer> fantasai: I think that’s no longer needed
17:34:30 <lea> so you sacrifice composability, but get absolutely no advantage
17:34:41 <emeyer> TabAtkins: I’m not sure if it’s a requirement now or not, I’ll have to think about it
17:34:56 <emeyer> astearns: I think we’re done with this issue for today
17:35:11 <emeyer> …Break time needed; will resume at the top of the hour
17:35:14 <emeyer> github-bot, end topic
17:35:16 <astearns> topic: break
17:35:46 <Penny> Penny has joined #css
17:42:57 <nigel> nigel has joined #css
17:44:36 <akeerthi> akeerthi has joined #css
17:53:31 <kbabbitt> kbabbitt has joined #css
17:55:24 <alisonmaher> alisonmaher has joined #css
17:57:14 <moonira> moonira has joined #css
17:59:56 <Adam_Page> Adam_Page has joined #css
18:00:16 <nigel> nigel has joined #css
18:00:30 <emeyer> emeyer has joined #css
18:01:23 <ethanjv> ethanjv has joined #css
18:03:28 <gsnedders> gsnedders has joined #css
18:04:27 <nigel> nigel has joined #css
18:04:38 <florian_irc> florian_irc has joined #css
18:04:45 <ydaniv> ydaniv has joined #css
18:04:49 <kbabbitt> scribenick: kbabbitt
18:04:54 <fserb> fserb has joined #css
18:05:48 <kbabbitt> github-bot, topic: https://github.com/w3c/csswg-drafts/issues/10437
18:05:48 <github-bot> kbabbitt, Sorry, I don't understand that command.  Try 'help'.
18:06:03 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10437
18:06:03 <github-bot> Topic: [css-values] attr()'s type system is inconsistent with other things
18:06:03 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10437.
18:07:05 <sgill> sgill has joined #css
18:08:02 <kbabbitt> moonira: in attr() grammer we define without angle brackets which is inconsistent with other custom property syntax
18:08:13 <kbabbitt> ... we have a prototype of attr() in Blink which we are going to ship
18:08:26 <kbabbitt> ... propose to resolve this issue by making attr() consistent with @property using angle brackets
18:08:45 <kbabbitt> TabAtkins: want to make sure all the places use consistent syntax; attr() was designed before we came up with this other stuff
18:08:54 <kbabbitt> astearns: and this is ocnsistent ewith type decision we made earlier
18:08:57 <andreubotella> andreubotella has joined #css
18:08:58 <kbabbitt> TabAtkins: yes
18:09:00 <lea> +1 seems like an obvious win to me
18:09:03 <kbabbitt> astearns: questions?
18:09:19 <kschmi> kschmi has joined #css
18:09:22 <chrishtr> q+
18:09:51 <kbabbitt> Proposed: Use the <syntax> production that we hae defined in the mixins spec, consistent with what we will be allowing in registered custom properties
18:09:55 <flackr> +1 sgtm
18:09:57 <kbabbitt> lea: (missed)
18:10:05 <fantasai> +!
18:10:08 <astearns> ack chrishtr
18:10:08 <fantasai> s/!/1/
18:10:15 <hypebeatsmagazine> hypebeatsmagazine has joined #css
18:10:21 <astearns> s/(missed)/consistent with custom properties etc.
18:10:25 <kbabbitt> chrishtr: question, this is new syntax for attr() and there's no compatibility risk with existing websites?
18:10:36 <kbabbitt> moonira: I don't think it should be a problem
18:10:44 <kbabbitt> chrishtr: attr exists, but it's just not exposed
18:11:23 <kbabbitt> moonira: existing attr() version doesn't include type syntax
18:11:31 <kbabbitt> chrishtr: what you're planning to ship will have type syntax?
18:11:34 <kbabbitt> moonira: correct
18:11:43 <kbabbitt> chrishtr: so because it's new syntax, there will not be a compat concern?
18:11:46 <kbabbitt> moonira: yes
18:11:59 <kbabbitt> astearns: other commments or questions?
18:12:14 <kbabbitt> hober: you're right, everyone has simple attr() that's it, should be good. but...
18:12:31 <kbabbitt> ... older spec has had other syntax for a long time, authors do like to do the cool thing they hope will work eventually
18:12:43 <kbabbitt> ... so there is potentially a compat risk, there may be things that were invalid before and would have been ignored
18:12:53 <kbabbitt> chrishtr: good point, it's possible but it seems worth trying to me
18:13:20 <kbabbitt> dbaron: I think it might even be less scary to change it just because suddenly implementing a feature if authors have been trying to write it and not test it for a long time is scary
18:13:24 <TabAtkins> we don't *usually* account for people writing invalid stuff ahead of the spec unless we're pretty sure there's actually a problem
18:13:25 <kizu> +1
18:13:29 <kbabbitt> ... changing the syntax right befor eit ships helps with that
18:13:51 <kbabbitt> chrishtr: are there other older features that have not been shipped with similar conditions?
18:14:26 <gsnedders> gsnedders has joined #css
18:14:33 <kbabbitt> tabatkins: no additional locations, just @property, @function, attr()
18:14:39 <TabAtkins> @property @function and @tr
18:14:41 <kbabbitt> astearns: objections?
18:14:54 <kbabbitt> RESOLVED: Use the <syntax> production that we hae defined in the mixins spec, consistent with what we will be allowing in registered custom properties
18:14:55 <matthieud> q+
18:15:30 <astearns> ack matthieud
18:15:36 <lea> q+
18:15:39 <kbabbitt> matthieud: for @property we need to put the syntax in quotes, but for attr() and @function we don't need uqoes?
18:15:47 <kbabbitt> tabatkins: no, @property will be updated
18:16:12 <kbabbitt> lea: the string versio will strictly be more powerful because you can still do quantifiers and htings like that?
18:16:22 <kbabbitt> tabatkins: no, you'll be able to use th enew syntax prodyction
18:16:31 <kbabbitt> lea: can you use quantifiers, e.g. 0-5?
18:16:44 <kbabbitt> tabatkins: I don't think that's in the grammer but it's not supported for the string version either
18:16:57 <kbabbitt> ... (missed0
18:17:00 <TabAtkins> like <number [0, 5]>
18:17:41 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/5900
18:17:42 <github-bot> Topic: [css-color] [css-ui-4] Authors should have access to accent-color value to use in their code
18:17:42 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5900.
18:18:12 <kbabbitt> lea: there's an accent-color property which lets you set the accent color for whole page or subtree
18:18:21 <kbabbitt> ...native ontrols take advantage of it to adapt their display
18:18:36 <kbabbitt> ...even though we have a system color called accentcolor, it returns the os default system color
18:18:44 <kbabbitt> ...seems like an easy win to have it return value of accent-color property
18:18:55 <kbabbitt> ...we have precent for system colors resolving differently based on other properties
18:18:58 <kbabbitt> ... <examples>
18:19:07 <Penny> Penny has joined #css
18:19:15 <kbabbitt> ... would give web components and components in general ability to adapt in that way same as native components
18:19:15 <akeerthi> akeerthi has joined #css
18:19:24 <astearns> ack lea
18:19:28 <kbabbitt> ... cannot be an environment variable because it's different for subtree
18:19:58 <kbabbitt> fantasai: if we look at the work on base stylesheet for form controls, where tims proposed to use currentcolor and transparent backround
18:20:10 <kbabbitt> ...you often need another color to <missed.
18:20:10 <chrishtr> q+
18:20:17 <kbabbitt> ... author would be able to use accent-color for that
18:20:18 <astearns> ack fantasai
18:20:26 <astearns> ack chrishtr
18:20:34 <kbabbitt> chrishtr: is accent-color inherited?
18:20:35 <kbabbitt> lea: yes
18:20:36 <fantasai> s/<missed/e.g. identify the selected item/
18:20:52 <kbabbitt> chrishtr: so then the color would start out as the same as the text color system color?
18:21:00 <kbabbitt> lea: OS default accent color
18:21:19 <emilio> q+
18:21:20 <kbabbitt> chrishtr: default would be OS default accent color provied by UA, if overrided subtree would receive new value
18:21:25 <kbabbitt> ... would this apply to shadow DOM?
18:21:31 <kbabbitt> lea: I believe inherited properties do
18:21:37 <fantasai> https://www.w3.org/TR/css-ui-4/#widget-accent
18:21:43 <kbabbitt> chrishtr: devlopers can already figure it out?
18:21:51 <astearns> ack emilio
18:21:52 <kbabbitt> emilio: <missed>
18:22:01 <kbabbitt> emilio: you want to make system colors based on the accent color?
18:22:04 <kbabbitt> lea: yes
18:22:14 <kbabbitt> emilio: you would also need text accent color
18:22:29 <kbabbitt> ... we need to deal with cycles
18:22:46 <kbabbitt> ... <missed>
18:23:07 <kbabbitt> ... you set accent-color to the system accent color, now you need to say what happens when this property resolves against the parent
18:23:13 <lea> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property. accent-color: accentColor resolves relative to the parent.
18:23:14 <kbabbitt> ... it's a bit weird with childrens' color schemes
18:23:26 <kbabbitt> ...anyway we need to sort that out, a bit weird you lose system accent color once you override it
18:23:32 <lea> q?
18:23:47 <ntim> What is accentcolortext ?
18:24:01 <kbabbitt> lea: you dont neessarily lose system color, we could define it relative to the parent or resolve realtave to acccent color on the root then you get the os color
18:24:12 <masonf> +1 to this question: what is accentcolortext?
18:24:17 <hober> q+
18:24:24 <ntim> oh I guess it's the text used against an accentcolor background
18:24:38 <masonf> ahh ok. The contrasting color. Thanks.
18:24:40 <kbabbitt> emilio: the accent color system color could be different in @@@ so registered custom property doesn't work as a workaround
18:24:50 <oriol> Wondering about `accent-color: currentcolor; color: accentcolor`
18:24:58 <kbabbitt> fantasai: whit if instead of resolving accent-color: accentcolor against parent, resolve against ???
18:25:08 <kbabbitt> emilio: maybe it's not a big deal because you could set it back to auto
18:25:25 <kbabbitt> fantasai: I don't see a use case for setting accent-color: accentcolor and wanting to change it
18:25:34 <ntim> +1 to oriol's question
18:25:40 <kbabbitt> emilio: once you set accentcolor to something, you can't get it back
18:26:21 <kbabbitt> hober: my initial thought was accentcolortext was a bad name because on sopme [platforms accentcolor s a background som eits a foreground
18:26:35 <kbabbitt> but we could have contrast color accent color
18:26:40 <kbabbitt> s/but/...but
18:26:58 <kbabbitt> fantasai: it would be weird if accent-color property changed with accentcolor
18:27:10 <kbabbitt> lea: accentcolor is defined in css color
18:27:28 <fantasai> ss/
18:27:28 <hober> s/contrast color accent color/contrast-color(accentColor)/
18:27:29 <astearns> s/accentcolor is defined/accentcolortext is defined
18:27:37 <fantasai> https://www.w3.org/TR/css-color-4/#valdef-color-accentcolor
18:27:57 <lea> https://drafts.csswg.org/css-color-4/#valdef-color-accentcolortext
18:28:05 <kbabbitt> emilio: oriol also mentioned this also causes issuse where you have accent-color: currentcolor or accentcolor, you need to define @@@
18:28:06 <hober> q?
18:28:07 <hober> ack
18:28:49 <kbabbitt> fantasai: agree with emilio that this is an editorial that needs to be solved but it's not complicated
18:28:58 <fantasai> s/editorial/issue/
18:29:14 <kbabbitt> astearns: is that where we are?
18:30:05 <emilio> q+
18:30:09 <kbabbitt> fantasai: funtamendal question is: accentcolor system color defined in color-4 references system accent color, will we have a property that allows setting accent-color, instead of being fixed, in same way currentcolor references color property, accentcolor referenes accent-color property
18:30:14 <emilio> ack hober
18:30:16 <florian> q+
18:30:31 <astearns> ack emilio
18:30:34 <fantasai> s/will we/we already/
18:30:44 <kbabbitt> emilio: something you mentioned, system colors right now compute to an actual color
18:30:46 <fantasai> s/instead of being fixed/proposal is instead of being fixed/
18:31:01 <kbabbitt> ...do we want to make accentcolor and accentcolortext keywords that inherit through or just resolve at computed value time?
18:31:14 <kbabbitt> fantasai: I htink you want to give them same treatment as crurrentcolor
18:31:24 <kbabbitt> florian: for privacy reasons I think it's not reasonable to expose it as an actual color
18:31:34 <akeerthi> akeerthi has joined #css
18:31:34 <kbabbitt> emilio: what's the privacy issue?
18:31:35 <astearns> ack florian
18:31:42 <kbabbitt> florian: two parts, one is acceing thjrough tree to value that the author has set
18:31:51 <kbabbitt> ...but if you haven't set anything, accentcolor depends on os settings
18:31:52 <lea> q?
18:31:58 <kbabbitt> ...so there's dobule use case. one is a convenience to the author
18:32:09 <kbabbitt> emilio: it doesn't matter because the keywords resolve in getcomputedstyle anyway
18:32:18 <lea> q+ the part that depends on OS settings doesn't change though
18:32:19 <kbabbitt> florian: two use cases, one is learning or using the os accent color
18:32:32 <kbabbitt> ...one is convenience of figuring out what the accent color you set yourself is
18:32:55 <kbabbitt> ...if we were only talking abou tlatter, it's kind of nice to have it, it could resolve to an actual color, wouldn't be terrible if we didn't
18:32:59 <kbabbitt> ...less convenient to do that but doable\
18:33:11 <kbabbitt> ...if we also want to expose accent color from outside browser, that's a fingerprintingh concern
18:33:21 <kbabbitt> emilio: that concern already exists from not exposing @@@
18:33:34 <kbabbitt> ...OS accent color keyword is shipped in gecko and webkit
18:33:43 <ethanjv> s/abou tlatter/about latter/
18:33:46 <kbabbitt> ...if you wnat to prevent fingerprinting of system colors you cannot expose OS setting
18:33:57 <kbabbitt> ntim: Safari hardcodes accentcolor to blue
18:34:00 <astearns> q+ lea
18:34:06 <kbabbitt> emilio: I don't think we want to inent something complicated
18:34:13 <ethanjv> s/fingerprintingh/fingerprinting/
18:34:17 <ydaniv> ydaniv has joined #css
18:34:22 <kbabbitt> florian: one of the motivating use cases was not at the javascript evel but OS level to know what the OS color is
18:34:25 <emeyer> q?
18:34:26 <ethanjv> s/inent/intent/
18:34:38 <kbabbitt> ...in Safari if you query the color, ti will say blue but will still render as OS color
18:34:40 <karlcow> karlcow has joined #css
18:34:45 <kbabbitt> ...bt I think that's the use case that's asked in the ???
18:34:57 <kbabbitt> ...OS uses this color and I want to use it too
18:35:13 <kbabbitt> ...either "no" or yes but I can't discover what it is
18:35:21 <astearns> ack lea
18:35:26 <kbabbitt> lea: we seem to be discussing an issue that's not related to @@@
18:35:33 <kbabbitt> ...whatever browser are already doing, they can cointineu to due
18:35:41 <kbabbitt> ...only change is what happens if accent-color is also provided by author
18:35:50 <kbabbitt> ...what happens when accent-color is not set is orthogonal
18:35:59 <kbabbitt> emilio: if yiu want to make accentcolor a keyword
18:36:01 <ethanjv> s/cointineu to due/continue to do/
18:36:03 <kbabbitt> lea: it already exists
18:36:12 <kbabbitt> emilio: it doesn't resolve aty computed value time
18:36:17 <kbabbitt> lea: doesn't matter when it resolves
18:36:30 <kbabbitt> lea: I wouldn't take ? as a model
18:36:38 <emilio> s/?/currentColor
18:36:39 <matthieud> s/?/CanvasText
18:36:48 <fantasai> s/as a model/as a model so much as CanvasText/
18:37:07 <kbabbitt> emilio: so we are not changing when it is resolved, that's fine with me
18:37:20 <dbaron> (ignore matthieud's substitution when preparing minutes)
18:37:48 <lea> canvas/canvastext and color-scheme seems identical to me: it can be set by the author, but there is also an OS default value that can change
18:37:57 <kbabbitt> ...fantasai seemed to want the currentcolor behavior, that seems not great because if you have matching background and text colors, if you change accentcolor in the tree wihtout settting anything, ?
18:38:26 <moonira> moonira has joined #css
18:38:30 <kbabbitt> fantasai: we have border color and on one dcouemtn I set to currentcolor, other I set to accentcolor
18:38:45 <kbabbitt> ... or text-emphasis
18:38:45 <astearns> q?
18:38:50 <kbabbitt> emilio: <missed>
18:39:04 <kbabbitt> ...that would change the accent color text but not the background which is odd
18:39:31 <kbabbitt> lea: does this concern apply to canvas and canvastext as well?
18:40:00 <kbabbitt> emilio: that's my point, the reason system colors resolve at computed value time is to prevent this kind of thing where switching color scheme without settingh background would make text unreadable
18:40:03 <kbabbitt> lea: not a new problem
18:40:14 <kbabbitt> emilio: not a problem aty all if we ckeep accentcolor resolving at computed value time
18:40:22 <kbabbitt> lea: why do we need to change it to work like currentcolor?
18:40:26 <emilio> <style>:root { background-color: AccentColor; color: AccentColorText }</style><p style="accent-color: blue">Foo
18:40:29 <kbabbitt> emilio: I don't think we need to but fantasai wanted to
18:40:38 <kbabbitt> fantasai: I don't know if it's required, but ???
18:40:53 <kbabbitt> lea: I agree it's important to make it work with color-mix, but I don't think ???? is needed
18:41:07 <fantasai> s/<missed>/:root { background: AccentColor; color: AccentColorText; accent-color: something } section { accent-color: somethingelse } would change the text color but not the background color
18:41:08 <kbabbitt> emilio: then you actually want it to resolve at computed value time, that's easier
18:41:14 <kbabbitt> ...it works in both cases, I think
18:41:24 <florian> q+
18:42:01 <lea> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property. accent-color: accentColor resolves relative to the parent.
18:42:25 <emilio> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property at computed-value time. accent-color: accentColor resolves relative to the parent.
18:42:43 <ntim> what about `accent-color: currentColor; color: accentColor;` ?
18:42:55 <kbabbitt> florian: unless I'm missing something this won't be usabel
18:42:57 <fantasai> Probably need accentColor to resolve against the parent in both color and accent-color
18:43:04 <kbabbitt> ...it will be usable if the author has actually set an accent-color
18:43:14 <lea> fantasai: why?
18:43:18 <kbabbitt> ...but if they haven't we're giong to default to system accent color which UA is lying about for fingreprinting reasons
18:43:38 <ntim> lea: how do you define the resolution of `accent-color: currentColor; color: accentColor;` ?
18:43:41 <chrishtr> q+
18:43:41 <fantasai> ... yeah that wouldn't work nm
18:43:44 <kbabbitt> ...if you set to orange, it will be orange, if you don't set it will be blue even if it's pink
18:43:46 <astearns> ack florian
18:43:54 <kbabbitt> emilio: unrelated to this resolution
18:43:55 <fantasai> but the see oriol/ntim's question about cycles
18:44:17 <kbabbitt> florian: currently accentcolor does not reflect the property and is used less because browser can and do lie about it
18:44:26 <kbabbitt> ...if we do this, it will be ???
18:44:33 <ntim> q+
18:44:34 <kbabbitt> emklio: browsers lie about system colors all the time
18:44:39 <lea> q+
18:45:03 <kbabbitt> florian: in my view, browsers lie about stste colors all the time and its fine because authors know that, just not use them
18:45:27 <kbabbitt> ...nbut if we make this a combination of a lie and something useful, some of the time it will be useful, sometimes it will be wrong, and it's not good to tempt authors into that
18:45:29 <astearns> ack florian
18:45:33 <astearns> ack chrishtr
18:45:45 <kbabbitt> chrishtr: I think the browser would lie when a developer tries to read back the color but not when painting the screen
18:45:52 <kbabbitt> ...if you use it in CSS it will have the correct system color
18:46:08 <kbabbitt> florian: if we don't resolve at computed value time I would agree, but if we resolve at coputed value time it has become a specific color
18:46:15 <lea> Current behavior: https://result.dabblet.com/gist/d9354b57012bc1f9eaf8edfbc2b39bed/76e4ff46647e8e44936801620ace82ae882d82ee
18:46:26 <kbabbitt> astearns: if it is using the system color at computed value time, it could remain the accentcolor system color
18:46:33 <emilio> q+
18:46:41 <kbabbitt> florain: but we don't have an ?? that tells us what it is we have a lie that tells us it's blue
18:46:45 <ntim> +1 to florian's argument
18:46:50 <kbabbitt> ...if we had kept it as a keyword I think it would work
18:47:01 <kbabbitt> ...but if we resolve to a specific color the lie becomes the truth
18:47:18 <kbabbitt> emilio: if we keep it as a keyword we also need to implement exceptions for canvas, etc
18:47:26 <ntim> If people use AccentColor on their sites, they'll get the hardcoded color unless someone sets accent-color, which is not really useful
18:47:29 <kbabbitt> ...I don't think we want to go that route
18:47:41 <astearns> zakim, close queue
18:47:41 <Zakim> ok, astearns, the speaker queue is closed
18:47:42 <kbabbitt> ...the browser can choose to make system colors ? or not depending on...
18:47:46 <astearns> q?
18:47:57 <kbabbitt> ...in windows high contrast mode, browser will expose actual system colors, those will be useful
18:48:10 <kbabbitt> ...my point is, I don't think we should ? a mitigation strategy here because we already have one
18:48:20 <kbabbitt> ...we can discuss in some other issue, it affects all system colors
18:48:33 <astearns> ack ntim
18:48:36 <emilio> s/?/invent/
18:48:54 <kbabbitt> ntim: florian's point is, if people start using accent color on their site, they could get fingerprinted, unless someone sets accent-color property
18:49:05 <kbabbitt> emilio: browser cannot tell whether syste accent color is red or blue
18:49:17 <kbabbitt> ntim: say you have a ? form control, system color setting is set to red
18:49:34 <kbabbitt> ...another element on page usees accentcolor keyword that element will have hardcoded blue color while native control will have red color
18:49:40 <kbabbitt> emilio: that may be a bug in webkit
18:50:06 <kbabbitt> florian: it's deliberate that it's blue because it protects fingerprinting and authors know that
18:50:22 <kbabbitt> ntim: how does this relate to tab's proposal for custom color schemes?
18:50:57 <kbabbitt> tabatkins: I don't think it has any affect on there; it's slightly realted in that custom color scheems need to be careful about not ? the system color scheme
18:51:02 <tantek> tantek has joined #css
18:51:12 <kbabbitt> ...other main issues, fingerprinting etc don't seem to apply to custom color scheme
18:51:19 <astearns> ack lea
18:51:31 <kbabbitt> lea: I 've been looking into what happens right now, posted a demo for current behavior
18:51:38 <kbabbitt> ...set system color to pink or something
18:51:46 <kbabbitt> ...regardless of what browsers do, cSS is internally consistent
18:51:54 <kbabbitt> ...you get a live version of what's displayed in accent color
18:52:04 <kbabbitt> ...Firefox and CHrome give you pink, Webkit is lying and gives you blue
18:52:17 <kbabbitt> ...either way it's consistent, mix with white gives you a lighter pink or blue
18:52:23 <kbabbitt> emilio: that was exactly my point
18:52:24 <florian> q+
18:52:33 <astearns> ack emilio
18:52:36 <emilio> ack emilio
18:52:57 <kbabbitt> florian: the reason it wouldn't be useful, yes you get blue and if you mix it you get lighter blue, but actual native controls are pink iN Safari
18:53:05 <emilio> q+
18:53:19 <kbabbitt> ...this is a hint that since some browsers do this on purpose, in genreal using system accentcolor keyword is a bad idea since it will backfire on authors
18:53:40 <kbabbitt> astearns: I'm not hearing consensus, we're not resolving today, we need to take it back to the issue
18:53:49 <astearns> zakim, open queue
18:53:49 <Zakim> ok, astearns, the speaker queue is open
18:53:49 <emilio> FWIW, Firefox lies about the accent color on Windows, but makes the form controls blue too, not the OS accent color
18:53:56 <emilio> Seems WebKit should do that
18:53:59 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7767
18:53:59 <github-bot> Topic: [css-viewport] Add a meta viewport parameter to control ICB layout behavior for interactive overlays
18:53:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7767.
18:53:59 <emilio> Or could
18:54:28 <ntim> lea, emilio: This illustrates florian's concerns: https://jsfiddle.net/5mb7efou/
18:54:41 <lea> astearns: fantasai and I thought we were pretty close to consensus, florian had a concern about the *current* behavior, and it seemed like everyone else was in agreement to do this?
18:54:43 <ntim> (open in Safari)
18:55:02 <kbabbitt> chrishtr: there are two modes supported that I think are common in mobile browsers for what to do about the interaction between fixpos elements in the page
18:55:03 <kbabbitt> ...layout viewport and visual viewport
18:55:36 <kbabbitt> ...two values are proposed, resize-visual and overlays-content
18:55:45 <kbabbitt> iank_: and resize-layout
18:56:15 <kbabbitt> chrishtr: it used to be that android chromium browsers only supported resize-layout, and webkit/safari only supported resize-visual
18:56:26 <kbabbitt> iank_: resize-visual or overlay-content, I forget which
18:56:33 <kbabbitt> chrishtr: compat concern from web developers
18:56:50 <kbabbitt> ...research found an app that is more app like and document like benefits from previous chrome/android behavior
18:56:54 <kbabbitt> ...other pages benefit more from the other value
18:57:09 <kbabbitt> ...difference often happens to do with when you open visual keyboard, does the visual viewport move up or not
18:57:17 <kbabbitt> ...sometimes you want it to move up, sometimes not
18:57:29 <kbabbitt> ...conclusion chrome came to is both values have value and we should support both
18:57:45 <kbabbitt> ...in the itnerest of iterop and because documents are more common than applications, default shoul dbe same as safari/webkit
18:57:56 <kbabbitt> ...thjat's what's shipped in Chrome so we have interop
18:58:01 <kbabbitt> ...implemented but not shipped in Firefox
18:58:11 <kbabbitt> ...meta tag to switch between modes to support app like user interfaces
18:58:38 <kbabbitt> ...instagram or twitter prefer the other mode because they have these little bars that want to be above virtual keyboard
18:58:47 <kbabbitt> ...they prefer the way android/chrome used to be
18:58:52 <kbabbitt> ...those browser support both more
18:59:00 <kbabbitt> ...proposal here is to standardize the meta tag
18:59:09 <kbabbitt> q?
18:59:17 <iank_> the three values are `resize-content`, `resize-visual` and `overlays-content`
18:59:27 <kbabbitt> ...meta tag is in editor's draft, is that editor's draft okay?
18:59:29 <dholbert> Firefox's switch to "resize-visual" (on Android) is shipping in version 132 (currently Nightly) as of https://bugzilla.mozilla.org/show_bug.cgi?id=1916002
18:59:41 <kbabbitt> iank_: we've also seen quite a lot of sites change to the resize content behavior
18:59:47 <bkardell_> carousel
18:59:53 <kbabbitt> emilio: there was another way of changing this behavior, right?
19:00:07 <kbabbitt> ...the virtual keyboard api?
19:00:07 <bkardell_> s/carousel/?
19:00:27 <kbabbitt> flackr: yes there's a virtual keyboard api to opt into overlay's content behaviior
19:00:33 <kbabbitt> ...not the most useful but ???
19:00:39 <kbabbitt> ...also not supported across all browsers
19:00:51 <kbabbitt> iank_: we've seen far more people use the interactive widgets meta tag
19:00:58 <kbabbitt> ...to opt into old chromium behavior
19:01:34 <kbabbitt> astearns: other questions?
19:01:48 <kbabbitt> Proposed: Accept what is in meta tag with the three values iank_ put in chat
19:01:53 <kbabbitt> astearns: objections?
19:02:11 <kbabbitt> RESOLVED: Accept what is in the draft
19:02:34 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10506
19:02:34 <github-bot> Topic: [css-env-1] Specify viewport environment variable property propagation into subframes
19:02:34 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10506.
19:03:28 <kbabbitt> flackr: we have safr area inset in environment variables thjat allow authors to avoid placing content in areas not guaranteed to be visibile
19:03:28 <kbabbitt> ...example around notch
19:03:37 <kbabbitt> ...we have a difference i whether those variables are set in subframes
19:03:44 <kbabbitt> ...on Safari it has the same values
19:04:00 <kbabbitt> ...in my demo you can see content in inner frame having same insets even though inner frame is nowhere near edge of screen
19:04:09 <kbabbitt> ...in Chrome we pass these insets through only when frame is fullscreen
19:04:14 <kbabbitt> ...we also set insets on main frame
19:04:24 <kbabbitt> ...proposal is that for inner frames by default we don't pass through insets
19:04:35 <kbabbitt> ...because it's up to the author to position so it avoids that area
19:04:44 <kbabbitt> ...unless frame has been made fullscreen
19:04:56 <kbabbitt> ...any frame that's been made fullscreen gets those insets
19:04:58 <TabAtkins> +1 from me
19:05:05 <fantasai> sgtm
19:05:15 <kbabbitt> astearns: questions?
19:05:22 <kbabbitt> astearns: concerns?
19:05:40 <kbabbitt> Proposed: insets are not passed through to inner frames by default
19:06:07 <kbabbitt> Proposed: top frame and any fullscreen subframes get insets set, but not otherwise
19:06:44 <kbabbitt> astearns: objections?
19:06:48 <kbabbitt> RESOLVED: top frame and any fullscreen subframes get insets set, but not otherwise
19:07:39 <matthieud> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10497
19:07:39 <github-bot> Topic: [css-cascade-6] Can we support implicit scopes in nested settings?
19:07:39 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10497.
19:07:46 <dbaron> ScribeNick: matthieud
19:08:11 <matthieud> miriam:  previously we creating implicit @scope root without a prelude-start
19:08:27 <matthieud> miriam:  the parent node is the implied scoping root
19:09:41 <matthieud> do we want to have the similar implicit behavior in a style rule nested context ?
19:09:56 <ydaniv> q+
19:10:21 <astearns> ack ydaniv
19:10:37 <matthieud> ydaniv:  what if it's not nested ?
19:10:50 <matthieud> miriam:  we allow non nested & selector which resolve to root, could be the same
19:10:55 <astearns> ack fantasai
19:11:15 <matthieud> fantasai:  when no scope-start, it uses the closest node at the scoping root
19:13:01 <matthieud> fantasai: with this resolution, we will longer be able to reference this implicit scoping root
19:13:10 <fantasai> s/longer/no longer/
19:14:24 <matthieud> miriam:  the confusion is if you are in a style element in the doc, with an implicit @scope non nested and one nested inside a style rule, they don't have the same scoping root anymore which could be surprising
19:14:35 <ydaniv> q+
19:14:47 <fantasai> Example is
19:15:11 <matthieud> ydaniv:  it's useful to have this functionality
19:15:30 <fantasai> <section><style>@scope { ... }</style>  ...</section> vs <section><style>@style (&) { ... }</style> ...</section.
19:15:38 <matthieud> miriam: there is no way to get back the parent node if we adopt this resolution
19:17:02 <matthieud> ydaniv: we could have a new keyword
19:17:37 <matthieud> fantasai:  there are other situation where & and :scope don't represent the same element
19:17:46 <fantasai> s/fantasai/miriam/
19:18:50 <matthieud> PROPOSED SOLUTION: close this issue, no change unless better arguments
19:19:12 <matthieud> RESOLVED: close this issue, no change unless better arguments
19:19:16 <fantasai> s/better arguments/arguments for stronger than those against/
19:19:48 <matthieud> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7348
19:19:48 <github-bot> Topic: [css-cascade-6] Add ability to scope rules from an imported stylesheet
19:19:48 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7348.
19:20:44 <chrishtr> q+
19:20:48 <fantasai> https://github.com/w3c/csswg-drafts/issues/7348#issuecomment-1719504814
19:21:08 <astearns> ack ydaniv
19:21:21 <fantasai> @import [ <url> | <string> ]
19:21:21 <fantasai>         [ layer | layer(<layer-name>) ]?
19:21:21 <fantasai>         [ supports( [ <supports-condition> | <declaration> ] ) ]?
19:21:21 <fantasai>         <media-query-list>? ;
19:21:31 <matthieud> fantasai: currently the order of trailing condition in @import is fixed
19:21:36 <astearns> ack chrishtr
19:22:27 <lea> +1 this seems pretty straightforward
19:22:27 <matthieud> fantasai:  we resolved to adding @scope on @import already
19:22:46 <lea> more generally on this issue, I wish it were possible to simply nest @import in @scope rather than need to learn new syntax
19:23:04 <astearns> ack dbaron
19:23:29 <matthieud> dbaron:  it seems that talking about reordering some of them are self explicit and media queries which are less isolated
19:23:54 <matthieud> dbaron:  we have 2 options : allow reordering everything but the MQ part ; or even across the MQ
19:24:01 <matthieud> fantasai: no strong opinion
19:24:34 <matthieud> fantasai: but no technical issue with reordering everything
19:24:56 <matthieud> astearns:  could we allow full reordering and open a following issue if there is an actual problem ?
19:25:01 <fserb> fserb has joined #css
19:25:18 <matthieud> dbaron: it's not a technical issue, but maybe it's gonna be more confusing for author
19:25:56 <matthieud> PROPOSED RESOLUTION: allow full reordering of all the current conditions on @import (MQ, scope, ...)
19:26:07 <matthieud> RESOLVED: allow full reordering of all the current conditions on @import (MQ, scope, ...)
19:26:50 <matthieud> chrishtr:  we should also add scope condition on HTML link element
19:27:25 <matthieud> miriam: the proposal is adding a scope attribute which take the scope-prelude as argument ?
19:27:41 <matthieud> fantasai: new attribute specifically for scope or a generic attribute for condition ?
19:27:49 <fantasai> s/condition/parameters
19:28:11 <matthieud> miriam:  there has been an issue in WHATWG about @layer should have its own attribute or not
19:28:28 <matthieud> miriam:  whatever the answer, we should do the same for @scope
19:28:43 <bramus> https://github.com/whatwg/html/issues/7540 is the issue
19:29:43 <matthieud> PROPOSED RESOLUTION: the WG recommends having an attribute to enable @scope on the HTML link element
19:30:02 <matthieud> RESOLVED: the WG recommends having an attribute to enable @scope on the HTML link element
19:41:31 <nigel> nigel has joined #css
19:44:12 <futhark> present-
19:49:01 <hypebeatsmagazine> hypebeatsmagazine has joined #css
19:56:02 <hyojin_> hyojin_ has left #css
19:56:21 <astearns> topic: lunch
20:06:53 <florian_irc> florian_irc has joined #css
20:22:42 <nigel> nigel has joined #css
20:23:00 <Francis_Storr> Francis_Storr has joined #css
20:23:08 <masonf> masonf has joined #css
20:29:05 <karlcow> karlcow has joined #css
20:29:18 <dbaron> github-bot: reboot
20:29:18 <github-bot> dbaron, Sorry, I can't reboot right now because I have buffered topics in #css.
20:29:48 <dbaron> github-bot: end topic
20:29:59 <dbaron> github-bot: reboot
20:29:59 <github-bot> dbaron, OK, I'll reboot now.
20:30:06 <github-bot> github-bot has joined #css
20:34:38 <florian_irc> florian_irc has joined #css
20:39:13 <nigel> nigel has joined #css
20:47:40 <emeyer> emeyer has joined #css
20:48:21 <nigel> nigel has joined #css
20:48:27 <astearns> 2pm
20:55:46 <jamesn> jamesn has joined #css
20:56:57 <kschmi> kschmi has joined #css
20:59:51 <Penny> Penny has joined #css
20:59:59 <kbabbitt> kbabbitt has joined #css
21:00:28 <Adam_Page> Adam_Page has joined #css
21:00:30 <khush> khush has joined #css
21:00:43 <gsnedders> gsnedders has joined #css
21:01:17 <astearns> starting up again, for those watching this space
21:02:13 <khush> present+
21:02:24 <kbabbitt> present+
21:02:53 <sgill> sgill has joined #css
21:03:04 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10957
21:03:04 <github-bot> Topic: [css-view-transitions-2] Clarifications around `view-transition-group`
21:03:04 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10957.
21:03:07 <alisonmaher> alisonmaher has joined #css
21:03:12 <vmpstr> present+
21:03:32 <miriam> present+
21:03:42 <Penny> present+
21:03:56 <bts> bts has joined #css
21:03:56 <ydaniv> ydaniv has joined #css
21:03:59 <ydaniv> present+
21:04:16 <TabAtkins> noamr: we resolved in the VT breakout on many things, but there were some unclear or edge cases
21:04:22 <nigel> nigel has joined #css
21:04:24 <TabAtkins> noamr: small but related
21:04:42 <TabAtkins> noamr: want to clarify the semantics of VT keywords are tree-scoped
21:04:47 <TabAtkins> noamr: We have keywords like 'nearest'
21:04:50 <andreubotella> andreubotella has joined #css
21:04:59 <khush> q+
21:05:05 <TabAtkins> noamr: Want to clarify they're tree-scoped as well, so 'nearest' can't capture things that couldn't be explicitly named
21:05:37 <cabanier> cabanier has joined #css
21:05:37 <TabAtkins> noamr: the other one is what happens in a mismatch, the old doc says "VT group X" the new says "VT group Y"
21:05:44 <TabAtkins> noamr: It appears there's no good solution
21:06:07 <TabAtkins> noamr: want to just be consistent with v-t-class and such. the semantic there is "last capture wins", so it'll usually take the VT group from the new doc state, unless it's an exit transition
21:06:28 <TabAtkins> noamr: third thing, not clear when using 'nearest' or a name that it also contains its descendants
21:06:36 <ethanjv> ethanjv has joined #css
21:06:39 <TabAtkins> noamr: if not, it's impossible for an element to contain and be contained at the same time
21:06:52 <florian_irc> florian_irc has joined #css
21:07:00 <TabAtkins> noamr: our proposal is to have it also contains its descendants by default
21:07:10 <TabAtkins> noamr: you can always escape by normal
21:07:15 <khush> q?
21:07:26 <TabAtkins> fantasai: it seems like this is three issues all filed separately, can we take them one by one?
21:07:45 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10633
21:07:45 <github-bot> Topic: [css-view-transitions-2] `view-transition-group` and tree-scoping
21:07:45 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10633.
21:08:03 <astearns> ack fantasai
21:08:03 <Zakim> fantasai, you wanted to react to dbaron
21:08:12 <astearns> ack khush
21:08:31 <TabAtkins> khush: for the scoping one, we made a similar resolution for anchor positioning, wondering if we should be consistent
21:08:49 <TabAtkins> khush: not like we're saying each keyword is a specific tree-scope, it's more like the property is tree scoped
21:08:55 <noamr> noamr has joined #css
21:08:58 <noamr> present+
21:09:03 <TabAtkins> khush: if it's tree scope matches, the property applies, regardless fo the tree scope
21:09:20 <boris> boris has joined #css
21:09:25 <TabAtkins> khush: so should we just say that in general - if the property applies, it has to match the tree scope?
21:09:36 <astearns> ack fantasai
21:09:44 <mustaq> present+
21:09:49 <TabAtkins> fantasai: I think it makes sense to be tree-scoped, dunno if we can come up with something generic, lots of palces we dont' want to be tree-scoped
21:09:55 <TabAtkins> fantasai: but for VT I think we should
21:10:04 <emeyer> emeyer has joined #css
21:10:08 <TabAtkins> noamr: as a general rule I think if the property describes a "style"...
21:10:15 <TabAtkins> fantasai: I think we'll still have to take that case-by-case
21:10:18 <TabAtkins> noamr: agreeing with you
21:10:32 <TabAtkins> +1 from me on one-offing this for now, don't generalize yet
21:10:48 <TabAtkins> noamr: proposed resolution, all vt-group keywords are tree-scoped in behavior
21:11:09 <emeyer> emeyer has joined #css
21:11:13 <TabAtkins> khush: can you give an example of what it means for 'nearest' to be tree-scoped or not?
21:11:34 <TabAtkins> noamr: if you use 'nearest' in a shadow, and the nearest vt container is outside the shadow, it won't match
21:11:46 <TabAtkins> RESOLVED: v-t-group keywords are all "tree-scoped" in behavior
21:11:54 <petele> petele has joined #css
21:11:59 <TabAtkins> githbu-bot, take up https://github.com/w3c/csswg-drafts/issues/10631
21:12:08 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10631
21:12:08 <github-bot> Topic: [css-view-transitions-2] Nested transitions: what happens if there is a mismatch?
21:12:08 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10631.
21:12:38 <TabAtkins> noamr: So old document specifies an element is part of one VT group, new document specifies that element as part of a different VT group
21:13:00 <TabAtkins> noamr: we didn't find something that always works for this. and dont' htink UX-wise there's a reasonable default that always works, it's always somewhat weird.
21:13:09 <TabAtkins> noamr: better for the author to decide when there's a conflict
21:13:18 <TabAtkins> noamr: if they want the common ancestor to be a given group, they can just do that
21:13:39 <TabAtkins> noamr: we thought the right default, then, is to match v-t-class which uses what the new state describes, except for exit transitions
21:13:43 <florian_irc> florian_irc has joined #css
21:13:50 <khush> q?
21:13:52 <khush> q+
21:13:53 <florian_irc> florian_irc has joined #css
21:13:56 <TabAtkins> +1 from me, matching v-t-class sounds better
21:14:01 <TabAtkins> khush: sounds good
21:14:03 <astearns> ack khush
21:14:12 <flackr> q+
21:14:23 <TabAtkins> khush: one thing that was subtle to udnerstand for me is that if the new state wins, the ancestor you're now mapped under was never in your ancestor tree in the old dom
21:15:00 <TabAtkins> khush: [??]
21:15:21 <astearns> ack flackr
21:15:29 <TabAtkins> flackr: i think that option 4 is a nice option in many scenarios
21:15:38 <TabAtkins> flackr: you mentioned that devs can opt into the neaarest common ancestor
21:15:41 <khush> s/??/The screen state transform from the old state is mapped back to the space of the ancestor we're choosing in the new state
21:15:46 <vmpstr> the transform remap is the same even if we go with lowest common ancestor, no?
21:15:47 <moonira> moonira has joined #css
21:15:52 <TabAtkins> flackr: but there's no way to opt into option 4, where the old thing animates out in its container, to the new thing in its container
21:16:09 <TabAtkins> noamr: they can do that with two names, just making the two elements different names
21:16:16 <TabAtkins> flackr: can't have it animate between the positions tho
21:16:18 <TabAtkins> noamr: right
21:16:33 <TabAtkins> noamr: we looked into this, and it breaks too much of the semantics where you split the transition properties into two
21:16:39 <TabAtkins> noamr: didn't seem worth it for this edge case right now
21:16:45 <TabAtkins> noamr: but we might be able to address it in the future
21:17:10 <vmpstr> q?
21:17:10 <TabAtkins> flackr: i udnerstand it's technically complex, was just thinking that if none of the others are good defaults, and this does something you can't do otherwise, it might be a good direction to pursue
21:17:20 <astearns> ack fantasai
21:18:02 <TabAtkins> fantasai: i'm not sure why the one your'e proposing is better than the other ones
21:18:18 <TabAtkins> noamr: It's not *better*, we think they're about equal, but it's consistent with v-t-class and other things
21:18:20 <TabAtkins> noamr: so it's easy to understand/remember that "last capture wins"
21:18:50 <TabAtkins> fantasai: did bramus have an opinion?
21:18:55 <TabAtkins> noamr: we've discussed it with him in the past
21:18:58 <ntim> q+
21:19:12 <TabAtkins> noamr: we've all come to this "can't think of anything better" position. nobody loves it, but users can decide what they want
21:19:22 <TabAtkins> khush: and if it doesn't work for you, you can do a common tree ancestor yourself
21:19:34 <TabAtkins> khush: using common ancestor autoamtically feels like more of a bug than intentional
21:19:50 <TabAtkins> flackr: my counter is option 4 presents *like* the thing they specified. the old thing wont' disappear because eit's suddenly clipped
21:20:05 <TabAtkins> khush: but option 4 is trying to sneak in a new feature into something that's otherwise an edge case
21:20:07 <TabAtkins> flackr: yeah
21:20:17 <janina1> janina1 has joined #css
21:20:22 <TabAtkins> khush: not saying it's bad, it's just not straightforward to add and not worth doing so right this moment
21:20:24 <vmpstr> q+
21:20:37 <nigel> nigel has joined #css
21:20:41 <TabAtkins> flackr: if it's an error case, could we just say you don't do a transition?
21:21:03 <TabAtkins> noamr: we've been there with v-t-class, I think doing "last capture wins" is a better default. CSS usually tries to recover when possible.
21:21:22 <vmpstr> q?
21:21:23 <TabAtkins> khush: if it's a choice between option 4 and not doing a VT, I'd prefer not doing one
21:21:42 <TabAtkins> fantasai: so it would be a transition, but we woudln't independently capture this element
21:21:55 <TabAtkins> flackr: yeah, because ancestors disagreed. almost like you're matching on (name, ancestor) pair
21:22:02 <khush> q?
21:22:13 <astearns> ack ntim
21:22:16 <fserb> fserb has joined #css
21:22:19 <TabAtkins> ntim: I thi8nk last capture wins makes more sense than option 2 or 3
21:22:22 <fserb> present+
21:22:36 <TabAtkins> ntim: usually you want the current state of the Dom to apply, and that's what last capture does
21:23:00 <ntim> current state of the DOM and style
21:23:09 <TabAtkins> vmpstr: option 4 also loses cross fades, because they're split into two groups. so it breaks more than it fixes, I think. I also support last capture wins, it's more consistent
21:23:17 <noamr> q+
21:23:34 <astearns> ack vmpstr
21:23:36 <astearns> ack noamr
21:23:40 <nigel> nigel has joined #css
21:23:43 <TabAtkins> noamr: note this isn't necessarily an error condition, maybe something has changed and now you know what the right state is. you're course-correcting
21:24:06 <nigel> nigel has joined #css
21:24:13 <TabAtkins> astearns: so which was "last capture wins"?
21:24:15 <TabAtkins> noamr: option 1
21:24:15 <khush> +1
21:24:20 <TabAtkins> astearns: ready to resolve?
21:24:27 <nigel> nigel has joined #css
21:24:40 <TabAtkins> RESOLVED: Use Option 1 (last capture wins) when there's a v-t-group mismatch.
21:25:01 <TabAtkins> astearns: I heard chatter about option 4 being a new feature, should there be an issue for this?
21:25:14 <TabAtkins> noamr: yeah we can open an issue to explore
21:25:22 <TabAtkins> astearns: we could possibly wait until it's justified
21:25:27 <TabAtkins> ntim: waiting is my preference, yeah
21:25:39 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10780
21:25:39 <github-bot> Topic: [css-view-transition-2] Should non-default `view-transition-group` act like `contain`?
21:25:39 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10780.
21:25:50 <TabAtkins> astearns: elika was thinking this was alreayd resolved
21:25:58 <tantek> tantek has joined #css
21:26:17 <TabAtkins> fantasai: when we resolved to adopt the v-t-group, there was a proposal that covered this case, which describes the features exactly as specified here
21:26:23 <TabAtkins> noamr: I thought so, but figured it wasn't clear enough
21:26:31 <TabAtkins> fantasai: i'll drop a link to the proposal we adopted
21:26:44 <khush> q+
21:26:57 <TabAtkins> fantasai: the values in the proposal we resolved defined the values in the way noam is discussing here
21:27:06 <TabAtkins> noamr: yeah this detail was in the conversation, but not explicitly in the resolution
21:27:09 <astearns> ack khush
21:27:22 <TabAtkins> khush: the use-case that was raised in the issue, it wasn't clear how we resolved applied to it, let me understand
21:27:25 <ntim> present+
21:27:38 <TabAtkins> khush: right now v-t-group does two things, it parents to something, and says your subtree is parented to you
21:27:54 <vmpstr> q+
21:27:55 <fantasai> the proposal as expressed in the issue
21:27:57 <TabAtkins> khush: you can't say both at the same time, so the proposal is to combine them and have them imply both?
21:28:00 <fantasai> https://github.com/w3c/csswg-drafts/issues/10334#issuecomment-2165649094
21:28:23 <TabAtkins> noamr: option 2, nearest and custom-ident implicitly mean contain too
21:28:23 <vmpstr> q-
21:28:25 <vmpstr> +1
21:28:26 <TabAtkins> fantasai: yes, that was in the description of the values
21:28:36 <emeyer> emeyer has joined #css
21:28:48 <TabAtkins> khush: i'm not a fan of it; i don't see why the nearest keyword has to implly it, rather than just allowing both keywords to be specified together if you want that
21:29:00 <astearns> q+ fantasai
21:29:00 <TabAtkins> khush: i think there are cases where you'd use nearest without implying you want your subtree too
21:29:02 <vmpstr> q+
21:29:06 <astearns> ack fantasai
21:29:14 <TabAtkins> fantasai: you could, but I think it's more likely you want capture.
21:29:18 <vmpstr> q-
21:29:19 <vmpstr> +1
21:29:27 <noamr> +1
21:29:33 <TabAtkins> fantasai: if you want to escape the capture you can use a name on the descendant; it doesn't *trap* them, it just contains by default
21:29:49 <flackr> +1
21:30:05 <TabAtkins> khush: ?
21:30:27 <TabAtkins> fantasai: if you come back with use-cases and decide that by default you don't want to capture, we could revisit, i just think by default it's the right behavior
21:30:40 <TabAtkins> khush: the thing that wasn't clear to me is that you could use a custom-ident on a descendant to escape, ok
21:30:44 <fantasai> https://github.com/w3c/csswg-drafts/issues/10334#issuecomment-2165649094
21:30:57 <noamr> nearest and <custom-ident> implicitly also mean contain
21:31:17 <fantasai> PROPOSED: all values other than normal implicitly contain
21:31:45 <TabAtkins> astearns: any objections to this proposal?
21:31:55 <TabAtkins> RESOLVED: all values other than 'normal' implicitly contain
21:32:16 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10574
21:32:16 <github-bot> Topic: [css-animations-2][web-animations-2] (proposal) Add pointer driven animations
21:32:16 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10574.
21:34:47 <TabAtkins> ydaniv: New proposal for pointer-driven animations
21:34:51 <TabAtkins> ydaniv: gonna show some examples
21:35:11 <TabAtkins> ydaniv: here's one example, parallax driven by pointer
21:35:23 <TabAtkins> ydaniv: another example, a whole suite of elements parallaxing
21:35:38 <TabAtkins> ydaniv: another example, each element is its own timeline (cards slightly shifting in 3d to avoid the pointer)
21:35:50 <TabAtkins> ydaniv: here's something we built internally, using a polyfill
21:35:53 <astearns> (example links in the issue)
21:36:07 <TabAtkins> ydaniv: (more parallax)
21:36:18 <TabAtkins> ydaniv: (a cat watching the pointer)
21:36:26 <TabAtkins> ydaniv: [slides times]
21:36:39 <TabAtkins> ydaniv: proposal for a pointer-timeline
21:36:49 <TabAtkins> ydaniv: driving an animation based on position of the pointer
21:36:54 <TabAtkins> ydaniv: relative to a box, or to the screen
21:37:00 <TabAtkins> ydaniv: builds on what we already have in scroll-driven animations
21:37:05 <astearns> s/screen/viewport/
21:37:18 <TabAtkins> ydaniv: some commonf eatures, attachment is usually the box of: animations target, a parent container, or the whole viewport
21:37:49 <TabAtkins> ydaniv: effects usually have a focal point, effect range is [1, 0, 1], [-1, 0, 1], or [0, 1, 0]
21:37:58 <TabAtkins> ydaniv: focal point is usually relative to the effect's target, or the timeline's subject
21:38:12 <TabAtkins> ydaniv: more common features: delayed progress
21:38:20 <TabAtkins> ydaniv: progress linked to velocity
21:38:28 <TabAtkins> ydaniv: some effects rely on polar coordinates
21:38:46 <TabAtkins> ydaniv: proposal is fully bikesheddable, some features are deferable
21:38:56 <TabAtkins> ydaniv: new property 'pointer-timeline: <name> <axis>'
21:39:01 <TabAtkins> ydaniv: works like view-timeline
21:39:25 <TabAtkins> ydaniv: new functional notation for anonymous animations: pointer(<axis> [ self | nearest | root ])
21:39:44 <TabAtkins> ydaniv: nearest means containing block of the target
21:39:46 <lea> q?
21:39:48 <TabAtkins> (because it's anonymous)
21:40:01 <TabAtkins> ydaniv: root is the whole viewport. can be a bit tricky, i'll explain later
21:40:02 <lea> q+ to ask can we reuse a referencing mechanism from another part of CSS? E.g. anchor positioning
21:40:09 <fantasai> suggest using container rather than nearest
21:40:15 <fantasai> since nearest parent may not be contianing block
21:40:16 <TabAtkins> ydaniv: new range names, entry and exit dont' really make sense
21:40:24 <TabAtkins> ydaniv: can keep cover, contain
21:40:35 <TabAtkins> ydaniv: propose adding fill and fit, taking from object-fit
21:40:41 <lea> Do we have a link to the slides?
21:41:00 <TabAtkins> ydaniv: by default the ranges aren't different unless you shift the center of the attachment point
21:41:09 <TabAtkins> ydaniv: new property, range-center to set the focal point
21:41:24 <TabAtkins> ydaniv: takes <length-percentage> or center/start/end keywords
21:41:39 <TabAtkins> ydaniv: can also take normal|target keyword, to target the animation target instead
21:41:44 <TabAtkins> ydaniv: have some demos
21:41:58 <TabAtkins> ydaniv: [shows off some illustrations]
21:42:29 <TabAtkins> ydaniv: in this, the red square is the viewport, bluie is the target, green has pointer-timeline
21:42:52 <TabAtkins> ydaniv: non-ancestor relationship, 50% is just in the center of the green
21:42:52 <lea> Material buttons are also another use case: clicking on a button grows a highlight from the pointer to the whole button https://m2.material.io/components/buttons
21:43:06 <TabAtkins> ydaniv: if blue is an ancestor, center is the center of blue, 0-100% is centered on that
21:43:14 <TabAtkins> "contain at target center"
21:43:46 <ydaniv> https://docs.google.com/presentation/d/1QwyeTDK8n6RU1px0-iu0Txi2aJH6zTL6d7X6_z-kk4A/edit#slide=id.g3007a239b93_0_79
21:44:27 <TabAtkins> ydaniv: "cover at target center", blue's center is still used, then it expands so 0-100 covers the green
21:46:08 <TabAtkins> ydaniv: "fill at target center", blue's center is used, but 0-100 exactly fills the green, so 0-50 and 50-100 use different scales
21:46:32 <TabAtkins> fantasai: would you want an easing function for that, since you're compressing one side and expanding the other?
21:46:41 <TabAtkins> ydaniv: I think you already have the potential for that...
21:47:03 <TabAtkins> flackr: I think th e point is your animation keyframes will have a 50% frame, and you can apply easing to work
21:47:31 <TabAtkins> fantasai: right, it's just a sharp change from compressed to expanded
21:47:43 <astearns> q?
21:47:47 <TabAtkins> TabAtkins: but a good easing choice can make that smooth, and making it easier is a separate thing
21:48:15 <TabAtkins> ydaniv: "fit at target center", blue center is used, 0-100 range is the *size* of green, but centered on blue
21:48:29 <TabAtkins> ydaniv: as you scroll you can stretch/squish the timeline
21:48:48 <TabAtkins> ydaniv: already can happen in scroll timelines if fixpos, but here's it's more common
21:50:40 <TabAtkins> ydaniv: the way we handle this fact when you're centering at the target is when you're using cover/contain, and your subject is the viewport....
21:51:11 <astearns> the pointer-driven timeline shifts at every scroll in that case
21:51:24 <TabAtkins> ydaniv: as you scroll, it will change the timeline
21:51:38 <TabAtkins> ydaniv: we shipped this to users with the polyfill
21:51:46 <TabAtkins> ydaniv: we use scroll-end to recalc the timeline on each scroll
21:52:25 <TabAtkins> ydaniv: [shows off "contain at source 200px 200px"] contrived to have a range at a specific point, but possible
21:52:46 <TabAtkins> ydaniv: [demo]
21:53:10 <TabAtkins> ydaniv: [demo shows off the range results as a gradient when various options are used]
21:53:54 <TabAtkins> ydaniv: [recaps the proposal]
21:55:00 <astearns> ack lea
21:55:00 <Zakim> lea, you wanted to ask can we reuse a referencing mechanism from another part of CSS? E.g. anchor positioning
21:55:16 <TabAtkins> lea: is there any way we could harmonize these refs with other parts of CSS?
21:55:23 <TabAtkins> lea: anchor-pos allows you to ref other elements
21:55:26 <kbabbitt> q+
21:55:39 <TabAtkins> lea: also, was wondering, the pointer() function is only available in animations?
21:55:52 <bts> bts has joined #css
21:56:01 <TabAtkins> lea: for second, this is just a way to draw animations, like view-timeline and scroll-timeline
21:56:18 <TabAtkins> s/lea/ydaniv/
21:56:25 <fantasai> s/draw animations/drive animations/
21:56:25 <TabAtkins> q+ to respond
21:56:36 <kbabbitt> q- later
21:56:46 <TabAtkins> ydaniv: the functions are used just for anonymous timelines
21:57:06 <TabAtkins> lea: was thinking this seems like a heavyweight solution if all you want is to get the relative position of a pointer for a background
21:57:20 <TabAtkins> lea: was wondering if we could add a simple function that gets you the pointer location relative to whatever
21:57:27 <TabAtkins> lea: I come across those cases fairly frequently
21:57:38 <TabAtkins> ydaniv: I think what you were asking was asked for by Bramus
21:57:49 <TabAtkins> ydaniv: it didn't go further, there were some issues?
21:57:54 <dbaron> Scribe+
21:57:56 <TabAtkins> flackr: we do the same thing for scroll/view timeline
21:58:00 <TabAtkins> flackr: they're not exposed as variables to use
21:58:12 <TabAtkins> flackr: they can be plugged into animations
21:58:18 <TabAtkins> lea: to resolve cycles?
21:58:29 <TabAtkins> flackr: not quite, if you have a variable it's non-trivial to know how we can respond to that off the main thread
21:59:01 <dbaron> TabAtkins: for now this is intrinsically something that wants to run off main thread, because it's scroll responsive
21:59:07 <dbaron> TabAtkins: we've solved that for animations but not the general case
21:59:22 <TabAtkins> flackr: if your animation *can* be composited, as long as we can determine the progress on the compositor we can accelerate the whole thing
21:59:33 <TabAtkins> flackr: but if it requires animating style we havne't figured that out yet
21:59:41 <kbabbitt> q-
22:00:10 <flackr> TabAtkins: I also think that one of the progress functions in values and units is meant to address handling an animation locally
22:00:17 <dbaron> TabAtkins: I also think one of the progress functions in values and units is meant to address this handling the animation locallly like this.  Saying what timeline you want to use, just pops the value right there.
22:00:29 <kizu> q+
22:00:32 <dbaron> TabAtkins: rather than getting a number directly out of the timeline you can directly ???
22:00:34 <astearns> ack TabAtkins
22:00:34 <Zakim> TabAtkins, you wanted to respond
22:00:43 <dbaron> TabAtkins: I think there is something over there -- fantasai wrote that section.
22:01:08 <dbaron> fantasai: are you thinking about progress() and mix() being able to pull a value out of a timeline?
22:01:08 <TabAtkins> fantasai: thinking about progress() and mix() functions that Miriam and I proposed could take a timeline
22:01:16 <TabAtkins> TabAtkins: yes, the grammar for that is currently in the spec
22:01:16 <astearns> ack kizu
22:01:21 <TabAtkins> kizu: +1 to this proposal
22:01:27 <TabAtkins> kizu: this is something authors want
22:01:33 <TabAtkins> kizu: I think animations as a first step is a good idea
22:01:37 <ydaniv> this should work: https://docs.google.com/presentation/d/18P_EX0Vy61Fy6iLUPP6YsNIe2GSHmKtiltEabPXhyo0/edit?usp=sharing
22:01:48 <TabAtkins> kizu: I've played a lot with events
22:02:00 <TabAtkins> kizu: we could do this in a hacky way with view timelines, by getting position as a pixel value
22:02:12 <TabAtkins> kizu: I don't know if the proposal allows doing this rather than using the % directly
22:02:32 <TabAtkins> kizu: if you want to display something you might just want an offset directly; calculating the offset from a % is possible but would like to avoid it
22:03:07 <TabAtkins> (I think you might be able to get that by driving an animation between 0 and anchor-size(), if that's applicable)
22:03:12 <flackr> q+
22:03:21 <TabAtkins> ydaniv: elaborate?
22:03:48 <TabAtkins> kizu: if I want to use this value in other places, like using a % in background. If the % is relative to something *else*, it's not usable directly in backgrounds.
22:04:00 <TabAtkins> kizu: We kinda could do in some hacky ways but it's not easy
22:04:22 <TabAtkins> kizu: so if the container is 300x300, we'd like a way to access a length like "120px" for 40% progress
22:05:03 <TabAtkins> ydaniv: This is using normal animations... basically you just set everything in keyframes
22:05:09 <TabAtkins> kizu: I'll comment with details on the issue
22:05:24 <TabAtkins> flackr: for mouse it's clear that this represents the hovered position
22:05:32 <TabAtkins> flackr: what happens with touch. primary touch point?
22:05:41 <TabAtkins> ydaniv: great question
22:05:49 <TabAtkins> ydaniv: I have libraries that polyfill this behavior, they each do something different
22:05:56 <TabAtkins> ydaniv: one is built to use the gyroscope
22:06:21 <TabAtkins> ydaniv: another uses long-press to trigger the animation, then as you drag your touch it moves with your finger
22:06:37 <TabAtkins> ydaniv: I think the last one just falls back to hover, so if you tap it'll update
22:06:54 <TabAtkins> ydaniv: what we did is just wrap everything in a (hover) MQ, so it's desktop only
22:07:07 <TabAtkins> flackr: so it's default to legacy desktop behavior, if you tap it uses that point
22:07:10 <TabAtkins> ydaniv: yeah
22:07:17 <astearns> ack flackr
22:07:23 <TabAtkins> flackr: does this only update when the cursor is within the observation container?
22:07:25 <fantasai> slides: https://lists.w3.org/Archives/Public/www-archive/2024Sep/att-0011/CSSWG___TPAC_2024___pointer-timeline.pdf
22:07:36 <TabAtkins> flackr: the green boxes
22:08:45 <TabAtkins> flackr: if I move my animation out the box on the left side, circle the box, and reenter on the right, is it tracking my pointer the whole time, or updating when it reenters?
22:08:48 <TabAtkins> ydaniv: the whole time
22:09:15 <TabAtkins> astearns: so I'm assuming this was for socializing the proposal - I think you get a "yes, that's interesting"
22:09:20 <TabAtkins> astearns: did you want anything more?
22:09:20 <lea> +1 to solving the problem, the use cases are common
22:09:25 <kbabbitt> +1 let's do this
22:09:30 <TabAtkins> +1 from me, i'll raise issues
22:10:31 <TabAtkins> ydaniv: demos are also shared in the slides
22:10:52 <TabAtkins> fantasai: do we want to continue just in the issue, or start putting it in a draft?
22:11:02 <TabAtkins> astearns: in the issue for now, it's still early. some point soon can move it to a draft
22:11:13 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6982
22:11:13 <github-bot> Topic: [css-animations-2] there should be a way to set the effect-wide easing for a CSS Animation
22:11:13 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6982.
22:11:29 <Adam_Page> Adam_Page has joined #css
22:12:03 <TabAtkins> flackr: currently, we only have animation-timing-function, which sets easing between keyframes
22:12:11 <TabAtkins> flackr: Web Anim also lets you set an easing across the netire animation
22:12:23 <TabAtkins> flackr: i think we discussed this previously, but I ahve a conrete proposal now
22:12:27 <TabAtkins> flackr: hopefully can resolve
22:12:46 <TabAtkins> flackr: 'animation-easing' property that sets the iteration-wide easing of the animation, defined the same as Web Animation
22:13:10 <TabAtkins> flackr: setting this property to a non-default value (which implies we need 'auto') would reset animation-timing-function to 'linear' by default
22:13:25 <TabAtkins> flackr: becuase a-t-f defaults to ease, you probably don't want that by default if the whole animation is eased
22:13:31 <TabAtkins> flackr: but you *can* specify both if you want
22:13:41 <TabAtkins> flackr: a use-case for doing both is a step animation that eases the timing of the steps
22:13:45 <astearns> ack fantasai
22:13:45 <Zakim> fantasai, you wanted to ask about compounding easing vs resetting
22:13:57 <TabAtkins> fantasai: I think having a shorthanding relationship is gonna be confusing
22:14:13 <TabAtkins> fantasai: if the concern is the initial value, we should change the a-t-f initial vlaue to something else that computes to linear or ease, depending
22:14:33 <TabAtkins> fantasai: that way if yous pecify both it works regardless of order
22:14:37 <TabAtkins> fantasai: other than that, makes sense
22:15:11 <TabAtkins> dbaron: clarify, the idea is not that it's some new type of easing, it's jsut setting the easing between every set of keyframes?
22:15:28 <TabAtkins> flackr: No, that's what a-t-f does, this is the animation-easing form WebAnim
22:15:32 <TabAtkins> dbaron: don't know what that does
22:15:48 <TabAtkins> flackr: It changes the time for the whole animation
22:15:58 <TabAtkins> dbaron: okay so your 50% keyframe isn't at 50% of the time, it's eased in some way
22:16:07 <TabAtkins> flackr: yes, and this is already widely implemented in Web Anim, it's not new behavior
22:17:00 <TabAtkins> flackr: proposed resolution is we add the 'animation-easing' as defined in the issue, and add a new initial value for animation-timing-function to something that computes to ease or linear depending on animation-easing
22:17:08 <emilio> q+
22:17:21 <astearns> ack dbaron
22:17:30 <astearns> q+ ydaniv
22:17:44 <TabAtkins> fantasai: just wanna make *sure* you want to change the default from ease
22:17:58 <TabAtkins> TabAtkins: yes, stacking 'ease' in both whole aniamtion and keyframes looks really bad most of the time
22:18:11 <TabAtkins> flackr: and Web Anim defaults all of them to linear anyway, the 'ease' default is from CSS
22:18:19 <fantasai> what should this keyword be though. 'normal'? 'auto'? 'none'?
22:18:34 <TabAtkins> emilio: to be clear, we add some 'auto' value to a-t-f so it looks at animatino-easing?
22:18:37 <ydaniv> q-
22:18:37 <TabAtkins> flackr: yes
22:18:41 <astearns> ack emilio
22:18:56 <TabAtkins> emilio: and presumably in animation-easing too, to distinguish it from an author-set linear
22:18:57 <TabAtkins> flackr: yes
22:19:13 <TabAtkins> emilio: and so the two share the syntax
22:19:14 <TabAtkins> flackr: yes
22:19:17 <TabAtkins> emilio: that sound ok
22:19:27 <TabAtkins> emilio: so if they're both auto, you get linear a-easing and 'ease' a-t-f
22:19:38 <TabAtkins> emilio: so this would be part of the animation shorthand presumably?
22:19:42 <TabAtkins> flackr: that's a separate issue
22:20:31 <TabAtkins> astearns: so proposed resolution to add animation-easing and a new initial value for a-t-f
22:21:12 <TabAtkins> emilio: do we need to *compute* the a-t-f value?
22:21:17 <TabAtkins> TabAtkins: probably can't change the observable initial vlaue
22:21:31 <TabAtkins> emilio: maybe another resolved value exception...
22:21:40 <TabAtkins> emilio: do we need the same thing for transitions
22:21:55 <TabAtkins> TabAtkins: transitions only have one keyframe, so no, not yet
22:22:15 <TabAtkins> flackr: you can attach keyframes to transitions with Web Anim, but then you have access to animationEasing again
22:22:17 <fantasai> We're also resolving this right? https://github.com/w3c/csswg-drafts/issues/8881
22:22:32 <TabAtkins> RESOLVED: add the 'animation-easing' as defined in the issue, and add a new initial value for animation-timing-function to something that computes to ease or linear depending on animation-easing
22:22:52 <TabAtkins> TabAtkins: yes, this closes 8881 too
22:23:20 <fantasai> scribenick: fantasai
22:23:30 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7508
22:23:30 <github-bot> Topic: [css-easing-2] Custom curve-based easing functions
22:23:30 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7508.
22:23:59 <fantasai> TabAtkins: Easying 2 spec added linear() function
22:24:15 <fantasai> TabAtkins: which allows any timing function you want in theory, but annoying if non-trivial function
22:24:23 <fantasai> TabAtkins: so there's a big batch of suggestions for other timing functions
22:24:27 <fantasai> TabAtkins: Possibilities include
22:24:36 <fantasai> piecewise cubic splines
22:24:38 <fantasai> SVG paths
22:24:41 <fantasai> other cubic-splines ideas
22:24:44 <flackr> q+
22:24:46 <fantasai> cubic-bezier
22:24:51 <fantasai> spring
22:24:58 <fantasai> midpoint
22:25:08 <fantasai> stacking easing functions
22:25:17 <fantasai> chaining easing function
22:25:31 <fantasai> easing based on math, e.g. supply a sin() function or whatever
22:25:37 <fantasai> JS-driven easing functions, 2 variants
22:25:54 <fantasai> TabAtkins: I want to decide which ones we want to include in easing 2 vs defer
22:26:06 <fantasai> TabAtkins: inclined to do just chaining and cubic-splining
22:26:12 <fantasai> TabAtkins: but could also be sold on spring
22:26:18 <kbabbitt> q+
22:26:19 <fantasai> TabAtkins: otherwise at some point will ask for a cutoff
22:26:19 <emilio> q+
22:26:21 <fantasai> TabAtkins: opinions?
22:26:29 <gsnedders> gsnedders has joined #css
22:26:32 <astearns> ack flackr
22:26:37 <ydaniv> q+
22:26:46 <fantasai> flackr: Don't have strong opinions on which specific function
22:27:02 <fantasai> flackr: but if using automatic duration for spring(), usually compute based on a distance
22:27:08 <fantasai> flackr: but animations don't currently have a distance
22:27:20 <fantasai> flackr: some hard to know what it would be, others there's no distance (e.g. color)
22:27:32 <fantasai> flackr: so we'll need an answer to that if we want to do it
22:27:36 <astearns> ack kbabbitt
22:28:01 <fantasai> kbabbitt: I only have an opinion on JS-driven. I understand desire, but either need to super constrain or will not be able to run performantly
22:28:19 <fantasai> TabAtkins: if JS available, generating a sufficient precise linear() is trivial, just do it
22:28:22 <astearns> ack emilio
22:28:34 <fantasai> emilio: 1st comment in issue also mentions SVG paths
22:28:37 <fantasai> emilio: how would you do that?
22:28:49 <fantasai> TabAtkins: similar to cubic-bezier()
22:28:59 <fantasai> TabAtkins: restrictions force it to be a function (one y per x)
22:29:08 <fantasai> TabAtkins: idk, don't think we should pursue
22:29:35 <fantasai> emilio: [mumble]
22:29:38 <astearns> ack ydaniv
22:29:40 <fserb> q+
22:29:52 <fantasai> ydaniv: I think we can pursue the math function one
22:30:00 <fantasai> ydaniv: using same syntax we have today for relative color
22:30:09 <fantasai> ydaniv: it will probaby kill the JS-driven use cases
22:30:24 <fantasai> ydaniv: and will cover a lot of easings that can be closely handled by cubic-bezier etc.
22:30:28 <fantasai> ydaniv: so that's worth trying
22:30:50 <fantasai> ydaniv: regarding spring(), might be difficult if we define something that gives you a duration that's not immediately known
22:31:06 <fantasai> ydaniv: stuff in Web Animations 2 like group effect
22:31:17 <fantasai> ydaniv: might need to know animation duration ahead of time
22:31:35 <fantasai> TabAtkins: integration with other types of animations makes me uncertain about an easing that has its own duration baked in
22:31:40 <fantasai> TabAtkins: more things to answer
22:31:48 <astearns> ack fserb
22:32:08 <fantasai> fserb: +1 to avoid the cubic-bezier and to use spline
22:32:19 <fantasai> fserb: because the code to handle that is awful
22:32:28 <fantasai> fserb: I think spline? is generic enough
22:32:41 <fantasai> fserb: if can do chaining etc then should be good enough
22:32:54 <fantasai> fserb: I think math-based is not good. Chaining is easier to understand
22:32:58 <fantasai> fserb: given that ? is not easy
22:33:05 <fantasai> fserb: given what I've seen people try to do
22:33:15 <fantasai> fserb: I have list of advanced cases, e.g. mobiel has special easings etc.
22:33:24 <fantasai> s/mobiel/mobile
22:33:35 <fantasai> TabAtkins: idk if multi-spline is fully general, but it can do a lot of htings including spring
22:33:46 <fantasai> fserb: Way specified, it allows for discontuity
22:34:11 <fantasai> astearns: enough feedback, Tab?
22:34:46 <TabAtkins> TabAtkins: yep
22:34:48 <github-bot> Topic: [web-animations-2] Progress APIs
22:35:02 <fserb> github-bot take up https://github.com/w3c/csswg-drafts/issues/8799
22:35:12 <fantasai> astearns: remaining question is whether we are clamping
22:35:22 <fantasai> flackr: we decided to add a progress accessor to animations
22:35:33 <fantasai> flackr: question was what to do outside the range of the animation
22:35:40 <fantasai> flackr: before animation starts or after it ends
22:35:50 <fantasai> flackr: I believe everyone is agreed that clamping is what makes sense, so want to resolve on it
22:35:57 <fantasai> flackr: [0%, 100%]
22:36:12 <fantasai> flackr: maps to the keyframe you're showing, assuming animation is in effect
22:36:21 <fantasai> astearns: any disagreement?
22:37:08 <fantasai> RESOLVED: Clamp progress to [0,1]
22:37:37 <fantasai> Topic: Scoping and Shadow DOM
22:37:41 <github-bot> Subtopic: [css-animations-1] @keyframes referencing from shadow roots does not match spec in any browser
22:38:08 <fantasai> noamr: Did research about how well we do ? on CSS names and shadow root
22:38:22 <fantasai> noamr: specified that names are inherited into a shadow root
22:38:38 <fantasai> noamr: so a name reference inside a shadow root can reference a name declared in an at-rule outside the shadow root
22:38:45 <kbabbitt> s/?/on interoperability/
22:38:47 <fantasai> noamr: I checked in practice what happens today, and nobody is spec-compliant
22:38:52 <fantasai> noamr: no interop, total mess
22:39:00 <fantasai> noamr: not a single at-rule that is both interoperable and spec-compliant
22:39:07 <fantasai> noamr: I wanted to raise attention to that
22:39:13 <fantasai> noamr: most of it we need to deal with implementation bugfixes
22:40:27 <fantasai> noamr: but for @keyframes specifically...
22:40:39 <fantasai> noamr: outer element for outer keyframes plays animations
22:40:52 <fantasai> noamr: outer animations can't see inner keyframes
22:40:53 <fantasai> noamr: great
22:40:57 <fantasai> noamr: 3rd one is not spec compliant
22:41:09 <fantasai> noamr: inner element can't see outer keyframes
22:41:10 <fantasai> noamr: but that's the same in all browsers
22:41:27 <fantasai> noamr: inner element inner keyframes works in all browsers
22:41:32 <fantasai> noamr: ::part is totally broken
22:41:52 <fantasai> noamr: ::part() should be scoped to where the style for that part is declared
22:42:31 <fantasai> flackr: i.e. animation declaration decides scope of name lookup
22:42:37 <fantasai> noamr: I don't think there's ambiguity in the spec here
22:42:38 <emilio> q+
22:42:46 <keithamus> q+
22:42:54 <fantasai> noamr: but with #3, makes sense to spec what's implemented
22:43:02 <TabAtkins> q+
22:43:03 <fantasai> noamr: i.e. keyframe names aren't inherited into the shadow
22:43:12 <fantasai> noamr: need to match
22:43:20 <astearns> ack emilio
22:43:30 <fantasai> emilio: Another test to try, which is ::slotted()
22:43:45 <fantasai> emilio: I suspect that slotted element can see outside, but it can also be styled from inside
22:43:56 <fantasai> emilio: given this, I'm very skepitical that we'll have interop
22:44:24 <fantasai> emilio: wrt Firefox, what we do is generally look at animations in the scopes where the element would have picked style from
22:44:43 <fantasai> emilio: so that's why, for example, why ::part() inner keyframes would work in Firefox
22:44:55 <fantasai> emilio: so even though super messy on the surface, there's some logic to it
22:45:00 <flackr> q+
22:45:05 <fantasai> emilio: that's why i think ::part would behave differently if [missed]
22:45:07 <astearns> ack keithamus
22:45:31 <fantasai> keithamus: Pain point in web components community wrt styling slot
22:45:33 <emilio> s/::part/::slotted would behave differently than a "normal" light dom element
22:45:43 <fantasai> keithamus: there are several rules that should ideally follow principle of reverse scoping
22:45:48 <astearns> +1 to keithamus
22:45:49 <fantasai> keithamus: all the browsers should implement to the spec
22:45:58 <fantasai> keithamus: I know that may be difficult wrt priority of constitutencies but ...
22:46:10 <astearns> ack fantasai
22:46:25 <emilio> q+
22:46:28 <TabAtkins> fantasai: I suspect that the proposal to have ::part() behavior have a different scope available to the shadow is trickier than having them be conssitent
22:46:52 <TabAtkins> fantasai: so I suspect the right answer is to make the outer and inner scope available to the stuff in the shadow, regardless
22:46:58 <keithamus> s/difficult wrt priority of constitutencies/difficult, but I'd cite priority of constitutencies
22:47:53 <astearns> ack TabAtkins
22:48:00 <noamr> q+
22:48:05 <Francis_Storr> Francis_Storr has joined #css
22:48:07 <fantasai> TabAtkins: Support keithamus, inner element outer keyframes working is important
22:48:13 <fantasai> TabAtkins: ppl complain about this always
22:48:15 <emilio> TabAtkins: two things, inner element outer keyframes working is important
22:48:23 <emilio> ... the fact it doesn't work annoys everybody
22:48:29 <emilio> ... so that should work unless stuff break
22:48:33 <emilio> ... breaks
22:48:59 <emilio> ... re part, the reason why it's defined this way is because that's the styles the stylesheet has access to in all other contexts
22:49:21 <emilio> ... so having a part name a keyframe and have that intercepted by the shadow dom keyframe is potentially confusing
22:49:35 <emilio> ... that said it might be worthwhile making that confusion
22:49:38 <fantasai> 100%
22:49:38 <keithamus> +1; it also breaks encapsulation if light dom can use key frames from shadow dom.
22:49:58 <astearns> ack flackr
22:50:00 <emilio> ... So fine with either with either firefox or safari behavior matching spec, chrome behavior is terrible
22:50:07 <emilio> flackr: Mostly agree with tab
22:50:17 <emilio> ... one case gets complicated,
22:50:23 <emilio> ... what's the scope when you set the inline style
22:50:48 <emilio> ... FF has an answer to that question which is all the scopes that could much
22:51:10 <emilio> TabAtkins: per spec the style attribute is the same as a stylesheet in the element's tree
22:51:25 <emilio> ... the fact that you can have a ::part() read and set again is really weird
22:51:59 <emilio> ... I'm fine with the idea of name visibility being based on the element being styled
22:52:21 <emilio> flackr: fine with the weird behavior where it doesn't roundtrip through style too
22:52:39 <emilio> ... might be better for authors so you have the name based on the stylesheet apply the animation name
22:52:54 <astearns> ack emilio
22:53:03 <fantasai> emilio: was going to argue for "not Firefox behavior"
22:53:09 <fantasai> emilio: look at the element, not at the thing
22:53:28 <fantasai> emilio: because trivially implementable, don't need to track the source of the specific declaration
22:53:51 <fantasai> emilio: if doing a thing where we allow outer keyframes to match inner shadow tree, I'd rather define precisely the order of all the trees given an element
22:53:57 <fantasai> emilio: without looking at the stylesheet
22:54:12 <fantasai> emilio: but in the spec you need to check from which stylesheet the animation declaration comes from
22:54:20 <fantasai> TabAtkins: currently you start from tree  and walk up
22:54:24 <fantasai> TabAtkins: [missed details]
22:54:53 <fantasai> emilio: shouldn't depend on the stylesheet the animation-name was specified
22:55:06 <fantasai> emilio: I think that's trivial to implement
22:55:11 <fantasai> emilio: given current mess, rather do that
22:55:17 <fantasai> TabAtkins: spoiler that makes it not trivial
22:55:25 <fantasai> TabAtkins: inherited values screw up
22:55:45 <fantasai> TabAtkins: because you don't want a font-family specified on an element in the light tree, inherit into shadow DOM
22:55:54 <fantasai> TabAtkins: that's what happened originally in WebKit's implementation
22:56:01 <fantasai> TabAtkins: caused accidental value change
22:56:21 <fantasai> TabAtkins: so you still need to track which tree a style was cascaded into
22:56:23 <karlcow> karlcow has joined #css
22:56:36 <fantasai> TabAtkins: and track it through inheritance
22:57:00 <fantasai> fantasai: I was assuming only talking about animation since non-inherited. Agreed for fonts it needs to be bound earlier
22:57:18 <fantasai> TabAtkins: nobody does good things, but spec doesn't separate out because the spec's current solution is reasonable for this case
22:57:26 <fantasai> emilio: should the font-face lookup be ??
22:57:45 <astearns> ack noamr
22:57:54 <fantasai> noamr: My suggestion to spec current behavior is jsut from perspective of not having specifiction
22:58:00 <fantasai> noamr: rather than finding a good solution
22:58:08 <fantasai> noamr: but happy to spec something else if we're actually going to do that
22:58:12 <fantasai> noamr: I'd like to see us fix this
22:58:26 <fantasai> noamr: We don't want to be leaky, so that's why Safari behavior is better
22:58:38 <fantasai> noamr: doesn't leak shadow DOM stuff external style
22:58:51 <fantasai> noamr: you want to animate a part in some way, and it does something internal
22:58:57 <fantasai> noamr: maybe thinking about names from inside... parts are specifically exposed but keyframes are not
22:59:19 <fantasai> TabAtkins: currently specced behavior gets you that
22:59:31 <fantasai> astearns: proposed resolution for this particular issue is to close no change ...?
22:59:36 <fantasai> noamr: but continue for fixing this on the web
22:59:50 <fantasai> astearns: and then continue discussing for parts/slots
23:00:14 <fantasai> RESOLVED: close no change
23:00:22 <castastrophe> castastrophe has joined #css
23:00:31 <TabAtkins> github-bot, end topic
23:00:34 <TabAtkins> <br dur=30min>
23:00:51 <fserb> fserb has joined #css
23:07:45 <florian_irc> florian_irc has joined #css
23:09:32 <Adam_Page> Adam_Page has joined #css
23:12:20 <Francis_Storr> Francis_Storr has joined #css
23:16:57 <nigel> nigel has joined #css
23:19:07 <florian_irc> florian_irc has joined #css
23:30:17 <bts> bts has joined #css
23:30:29 <sgill> sgill has joined #css
23:30:59 <moonira> moonira has joined #css
23:32:02 <kschmi> kschmi has joined #css
23:33:02 <kbabbitt> kbabbitt has joined #css
23:33:12 <khush> khush has joined #css
23:33:17 <khush> present+
23:33:19 <ethanjv> ethanjv has joined #css
23:33:29 <fserb> fserb has joined #css
23:33:32 <kbabbitt> present+
23:33:48 <ethanjv> present+
23:34:53 <fserb> present+
23:35:06 <moonira> present+
23:35:10 <dholbert_> dholbert_ has joined #css
23:35:11 <khush> ScribeNick khush
23:35:14 <emilio> present+
23:35:38 <khush> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10808
23:35:38 <github-bot> Topic: [css-scoping] Breaking name encapsulation
23:35:38 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10808.
23:35:44 <bkardell_> present+
23:36:11 <alisonmaher> alisonmaher has joined #css
23:36:45 <emeyer> emeyer has joined #css
23:37:01 <rachelandrew> present+
23:37:13 <florian_irc> florian_irc has joined #css
23:37:44 <noamr> noamr has joined #css
23:38:03 <ydaniv> ydaniv has joined #css
23:38:40 <miriam> present+
23:38:51 <ydaniv> present+
23:39:33 <karlcow> karlcow has joined #css
23:39:47 <nigel> nigel has joined #css
23:40:01 <nigel> nigel has joined #css
23:40:34 <dholbert_> dholbert_ has joined #css
23:40:44 <khush> TabAtkins: we talked about tree scoping, names and references. filling context
23:40:49 <fserb> fserb has joined #css
23:41:01 <khush> when you are in a shadow tree you can see names defined in your tree and outer tree but not in other shadow trees
23:41:16 <khush> similarly you can't in the main page see names defined in inner shadow trees
23:41:40 <khush> good thing when you don't want to expose. but people complain about not being able to do componenets, example to anchor to elements in shadow trees
23:41:52 <khush> proposing a solution, allow exposing names in accessible fashion
23:42:07 <khush> new global func takes a custom ident. can be used anywehre you define a custom ident
23:42:30 <khush> instead of carrying the scope where it's defined, it becomes a global tree scope. not a root tree scope. explicit opt-in to the scope
23:42:41 <khush> so intentional process to both define and name things
23:42:51 <khush> you can get names from anywhere inn the tree, any shadow
23:42:59 <khush> if you're not using global, it acts the same as today
23:43:01 <westbrook> westbrook has joined #css
23:43:04 <khush> anders says its reasonable
23:43:25 <khush> right now tree scope is a tuple of ident and scope. this would just set scope to null. and null matches null
23:43:32 <khush> i'd like to turn this into the scoping spec
23:43:39 <emilio> q+
23:43:43 <noamr> q+
23:43:45 <lea> You might want to look at reference target and follow a similar design
23:43:46 <khush> we can resolve to republish the spec them
23:43:48 <khush> *then
23:43:51 <astearns> ack emilio
23:44:01 <gsnedders> gsnedders has joined #css
23:44:08 <khush> emilio: would this only be anchors or other names too
23:44:25 <khush> depending on the kind of data refernced by the name, might not trivial to get random data
23:44:51 <khush> TabAtkins: it should work for all tree scoped names and references
23:44:57 <khush> you'd still be able to do the encapsulation by default
23:45:03 <khush> only things defined by global are accessible
23:45:19 <khush> emilio: unless you have a global map of name or something else. you have to go through all the shadow trees
23:45:26 <lea> What is the use case for eg keyframes?
23:45:30 <khush> TabAtkins yes a global map is needed but not all references
23:45:39 <keithamus> q+
23:46:20 <khush> emilio: any other opinions? global map is based on the DOM. it's different for keyframes. That data in a centralized space in a shadow tree. keyframes won't be tree scoped names?
23:46:26 <westbrook> q+
23:46:53 <khush> TabAtkins: it's in the list of things in the scoping spec that need to be updated to be tree scoped
23:47:04 <astearns> ack noamr
23:48:08 <khush> noamr: i find globals to be messy. replacing something encapsulated with something which causes a footgun. people would want global but not too global. export semantic is better. we use the host pseudo class in the shadow dom to export names and import from outside. so you can track the chain, rather than one global map everything goes into
23:48:32 <khush> global is simpler than this, you just have one thing. css has shown that these things become a problem like z-index.
23:48:41 <khush> web apps become more complex as a result
23:49:18 <khush> TabAtkins hoping to get away with one additional scope. ok with import/export. it makes the concept harder. you need a way to explicitly refer, this name from keyframe is exported. this name from anchor is exported
23:49:23 <khush> so harder to use but not impossible
23:49:37 <astearns> ack keithamus
23:49:40 <khush> explicit import syntax would help emilio's concern. having to search everything in a global map
23:49:49 <khush> keithamus: what happens in a collision?
23:50:03 <khush> TabAtkins same as defining a name twice in the same scope. one wins, based on some order
23:50:14 <astearns> ack westbrook
23:50:15 <khush> TabAtkins you should rename using import/export
23:50:48 <khush> westbrook: like this idea. passing them across subtrees is good. could also extend to anchor across containing blocks?
23:51:16 <andreubotella> andreubotella has joined #css
23:51:25 <khush> TabAtkins wouldn't let you violate that. it's a required thing based on timing of layout. it's logically impossible, it would let you lift a name from a shadow and use it somewhere else
23:51:32 <khush> layout constraints are still obeyed
23:51:40 <khush> astearns any other comments?
23:51:41 <khush> q+
23:51:50 <fantasai> scribe+
23:51:57 <fantasai> khush: I just agree conceptually with what noamr said.
23:52:21 <Francis_Storr> Francis_Storr has joined #css
23:52:25 <fantasai> khush: a single global map is a footgun, better if can explicitly export / import / rename
23:52:43 <fserb> q+
23:52:44 <fantasai> khush: that gives an opt-in from both sides, otherwise shadow tree can export into global() stuff the outer context doesn't want
23:52:49 <astearns> ack khush
23:52:58 <fantasai> TabAtkins: how much can we get away with using global and just have shadow tree say
23:52:59 <khush> ScribeNick khush
23:53:40 <khush> TabAtkins you can grab what you want as a whole, don't have to ref everything indvidiauly. prevent accidental collision in the global space. let you know which shadow trees to recurse into so you don't have to walk all trees
23:53:41 <astearns> ack fserb
23:53:44 <noamr> It's like "import * from"
23:54:12 <khush> fserb: for this idea if you do something like import/export, you would have to go through the parent. Is this a use-case that matters, sharing things. you mention that on the explainer.
23:54:20 <noamr> q+
23:54:25 <astearns> ack noamr
23:54:26 <khush> fserb sibling shadow trees
23:55:00 <khush> noamr: would have to go through the parent. you can redo this with parts, probably have a semantic with this for names. anchor/ view transition are peer to peer rather than hierarchical.
23:55:23 <khush> fserb is there a real use-case for more direct sibling to sibling? global would do that.
23:55:36 <khush> fserb export from here, import in the root and then export to sibling
23:56:07 <khush> TabAtkins most refs walk the tree to find in parent space so just export to sibling. anchor is not doing but likely change has to happen for anchor. the use-case is important
23:56:15 <khush> TabAtkins: can take it back to the issue now
23:56:25 <khush> astearns come up with an import/export mechanism. get anders feedback
23:56:44 <khush> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10541
23:56:44 <github-bot> Topic: [css-properties-values-api] "Property registration cannot be scoped" differs from all implementations in a consistent way
23:56:44 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10541.
23:56:55 <bkardell_> just will note for the record that I'm not sure people really like parts
23:56:57 <khush> astearns nobody matches the spec issue. yay
23:57:09 <tantek> tantek has joined #css
23:57:19 <khush> noamr repeat of the prev one with @property
23:57:38 <khush> i opened bugs on all browsers. browsers match but don't match the spec
23:57:56 <khush> prop descriptor has spec text that says you can define it in any scope and they are global
23:58:08 <tantek> present+
23:58:12 <khush> but they actually work in the global document only. prop descriptors from shadow dom are ignored
23:58:28 <khush> they are diff from everything else, global and inherited by the shadow tree
23:58:39 <khush> current way is not bad, it's actually like an api contract
23:59:13 <khush> if you have a custom element which uses custom props, you have to import the CSS which will have prop declarations. rather than relying on shadow root to declare those props. it's like a header file
23:59:13 <flackr> q+
23:59:37 <khush> ideal resolution would be prop descriptor have to be in the Document
23:59:47 <astearns> ack flackr