15:59:48 <RRSAgent> RRSAgent has joined #css
15:59:52 <RRSAgent> logging to https://www.w3.org/2023/01/25-css-irc
16:00:16 <Zakim> RRSAgent, make logs Public
16:00:17 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:59 <lea> lea has joined #css
16:01:49 <emeyer> emeyer has joined #css
16:02:55 <fremy> fremy has joined #css
16:03:10 <Rossen_> present+
16:03:15 <fremy> present+
16:03:30 <dholbert> present+
16:03:41 <jensimmons> present+
16:04:16 <miriam> present+
16:04:25 <fantasai> scribenick: fantasai
16:05:38 <patrickangle_> patrickangle_ has joined #css
16:05:58 <fantasai> Topic: CSS Nesting
16:06:02 <oriol> oriol has joined #css
16:06:02 <fantasai> Subtopic: Admin
16:06:03 <plinss> present+
16:06:07 <fantasai> swapping order of 2 & 3 on agenda
16:06:12 <fantasai> adding republication as a topic
16:06:22 <fantasai> Subtopic: Clearer definition of "nest-containing"
16:06:29 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7972
16:06:30 <oriol> present+
16:06:31 <dbaron> Zoom for web is not working for me... I've tried multiple browsers at this point.
16:06:44 <dbaron> (doesn't work in either Chrome or Firefox)
16:06:56 <fantasai> TabAtkins: If a selector starts with a combinator, we assume relative selector
16:07:05 <fantasai> TabAtkins: insert & and interpret accordingly
16:07:20 <fantasai> TabAtkins: If no such combinator, we need to check if this should be relative selector or if there's an & deeper in
16:07:43 <fantasai> TabAtkins: Could have something like "foo &" or ":not(&) ..>"
16:07:52 <fantasai> TabAtkins: But spec is not super clear what it means by "contain" an &
16:08:08 <TabAtkins> :is(&:unknown, .foo)
16:08:09 <fantasai> TabAtkins: e.g. what happens if & is inside :is() within branch that's ignored by invalidity?
16:08:18 <fantasai> TabAtkins: is that &-containing or not?
16:08:25 <fantasai> TabAtkins: Depending on our answer, how does it affect serialization
16:08:29 <fantasai> TabAtkins: Listed a few options
16:08:37 <fantasai> TabAtkins: 1. Only look at top-level, not inside parens
16:08:47 <fantasai> TabAtkins: 2. Look everywhere except inside forgiving parsing list
16:09:01 <davidleininger> davidleininger has joined #css
16:09:29 <fantasai> TabAtkins: 3. Get deeper into parsing guts, say something about & inside even forgiving selector lists that might be invalid, and preserve that info across serialization even though normally drop such branches during reserialization
16:09:42 <fantasai> TabAtkins: fantasai and I thought #3 would be weird, because [missed]
16:09:53 <fantasai> TabAtkins: so initial suggestion was #1, simple suggestion
16:09:55 <chris> chris has joined #css
16:10:01 <chris> present+
16:10:15 <fantasai> TabAtkins: after discussion with Natalie and Miriam, there were too many use cases for & deeper than top-level
16:10:29 <fantasai> TabAtkins: and having selector only in one branch and not others is weird and unusual, so not that important if behavior differs in branches
16:10:31 <dbaron> OK, given that the meeting link doesn't work for me in (a) Chrome/Mac (b) Firefox/Mac, and (c) Firefox/Linux, I'm going to give up for technical difficulties... see you at the regular call in 50 minutes.
16:10:41 <fantasai> TabAtkins: so suggestion is to look for & in every branch, invalid or not
16:10:52 <fantasai> TabAtkins: needs authors to be a little more careful
16:11:01 <fantasai> TabAtkins: but simple: if there's an & anywhere, it's got one
16:11:02 <fremy> q+
16:11:17 <fantasai> TabAtkins: Might need to tighten up parsing by having known-invalid selectors serialize as something particular
16:11:34 <fantasai> TabAtkins: So definition proposed is that it's containing an & if it contains an & anywhere
16:11:54 <fantasai> fremy: Tab mentioned that it's weird to have branches where some contain & but some do not
16:12:02 <fantasai> fremy: I agree, if you're doing that it's probably a mistake
16:12:09 <fantasai> fremy: But then why can't we make this a rule?
16:12:16 <dbaron> Present+
16:12:17 <fantasai> fremy: if you have a branching selector, have to have & in every branch
16:12:25 <dbaron> (ok, zoom started working when I clicked on the grayed-out "More ..." button at the bottom)
16:12:29 <fantasai> fremy: otherwise invalid
16:12:47 <fantasai> TabAtkins: Valid question, we could, but probably doesn't matter because unusual case
16:13:01 <fantasai> TabAtkins: so I don't think it's necessary
16:13:07 <fantasai> TabAtkins: but I could do either way
16:13:23 <Rossen_> ack fremy
16:13:46 <fantasai> fantasai asks for an example
16:14:10 <fantasai> TabAtkins: Consider the previous example, where only one branch of :is() has an &. Difference is we'd make that illegal
16:14:17 <TabAtkins> so `:is(&:unknown, .foo)` would be an invalid selector
16:14:41 <fantasai> TabAtkins: Also weird, it would be the only way for :is() to invalidate a selector
16:14:43 <lea> in case it helps, as an author, I'd expect .foo { :is(&, .bar) {} } to be interpreted as .foo, .foo .bar , not .foo, .bar
16:15:01 <fantasai> TabAtkins: another little bit of complexity that we could avoid for a corner case
16:15:20 <fantasai> fremy: Yes, I think I agree. It might not make much sense, but you might want it
16:15:57 <fantasai> TabAtkins: Lea posts a different suggestion, which is that you take different paths in deciding relative selector or not
16:16:14 <fantasai> TabAtkins: Problem is that doesn't map directly to :is() notation, so suspect it would complexify implementations
16:16:56 <chris> leaverou there was a question for you
16:17:14 <fantasai> fantasai: Do we have any comments from implementers on lea's question?
16:17:27 <lea> chris: what was it? I'm looking at the minutes but can't find it. I'm not on the call, as I'm on the TAG plenary
16:17:36 <fantasai> TabAtkins: I can't say for sure, but I think  our implementation would find it difficult
16:17:47 <fantasai> s/sure/sure because our implementers aren't on the call/
16:18:00 <fantasai> emilio: Doing what Lea suggests would be fairly annoying
16:18:06 <fremy> @ lea, the question was whether TabAtkins's reply to you addressed your concern or not
16:18:10 <fantasai> emilio: and could have problems with selectors growing exponentially, which is not great
16:18:24 <fantasai> emilio: I think this is a problem Blink had when they initially implemented this
16:18:42 <fantasai> TabAtkins: When trying to do naive impleementation of :is(), it was a problem
16:18:43 <fremy> @ lea, and (I guess) whether this was something you felt strongly about
16:19:21 <lea> fremy: no, this is not something I feel strongly about
16:19:32 <fantasai> Rossen_: Current proposal is simply option 3 without any further modification (and by option 3 we mean option 3 in IRC, which is option 2 in the issue)
16:19:44 <TabAtkins> proposed resolution: Relative-ness is decided based on & appearing *anywhere* in the selector, including in (potentially-invalid) branches of a forgiving-selector-list
16:20:08 <fantasai> plinss: I presume it's only legal for one & in selector?
16:20:11 <fantasai> TabAtkins: no can have multiple
16:20:17 <fantasai> plinss: so I can say &.foo &.bar?
16:20:29 <lea> though I do find it fairly weird if you can "break" out of the nest by doing `:is(&, .bar)`. and if :is(.bar) matches different things than the .bar in :is(&, .bar)
16:20:31 <fantasai> TabAtkins: & represents elements matched by the parent selector
16:20:49 <fantasai> TabAtkins: would be two different elements that both happen to match the same parent
16:20:52 <fantasai> plinss: fair enough
16:21:07 <Rossen_> ack fantasai
16:21:35 <TabAtkins> fantasai: suggest we clarify that if I have any kind of selector garbage inside :is(), including an & nested deep inside of the garbage, that & is considered to be an & for these purposes?
16:21:40 <TabAtkins> TabAtkins: correct
16:21:47 <fantasai> :is(:unknown(&))
16:22:01 <fantasai> :is([something (&something else { } ) ])
16:22:10 <TabAtkins> :is([{(&)}]) has an ampersand in it, per the suggested resolution
16:22:42 <fantasai> TabAtkins: If during selector parsing you see an & delim token, mark the selector as having an & and continue normal parsing
16:23:11 <fantasai> Rossen_: any other feedback?
16:24:05 <fantasai> RESOLVED: Relative-ness is decided based on & appearing *anywhere* in the selector, even nested inside anything else
16:24:16 <fantasai> TabAtkins: Question is what to do about serialization
16:24:37 <fantasai> TabAtkins: Option 1: do nothing special. This might mean that an invalid branch is dropped, which changes selector interpretation
16:24:58 <fantasai> TabAtkins: Option 2: serialize any :is() branch that contains an & as-is
16:25:35 <fantasai> TabAtkins: Option 3: serialize any :is() branch that contains & as something guaranteed to be invalid, e.g. "&:not(&)" (which is guaranteed to not match but definitely contains an &)
16:25:39 <emeyer> q+
16:25:44 <fantasai> emilio: Only doing ????
16:26:09 <fantasai> TabAtkins: Option 4: do 2 or 3 if that's the only branch that contains an & (and thus the selector interpretation is dependent on that branch existing)
16:26:18 <Rossen_> ack emeyer
16:26:31 <fantasai> emeyer: wrt option 1, what are the concerns?
16:26:55 <fantasai> emilio: It's bad if something serializes and then whe you re-parse it it's interpreted differenly than the original
16:27:16 <fantasai> TabAtkins: So you can have a selector that's relative in new browsers and non-relative in older browesers, which is significant change
16:27:33 <fantasai> emilio: You lose the forgiveness ... which is annoying
16:27:42 <fantasai> [missed]
16:28:00 <dbaron> My preferences:  definitely not option 1, weakly prefer option 3 (without the option 4 variant).
16:28:14 <fantasai> emilio: Implementationwise, it feels like it would be nice not to account for & in invalid branches, so you can compute the relativeness of a selector independently of the parsing process
16:28:30 <fantasai> <fantasai> +1 dbaron
16:28:38 <fantasai> emilio: ... but all the options are weird in their own way
16:28:54 <Rossen_> q?
16:28:55 <fremy> @ TabAtkins, for option 3 `&:not(&)` might be costly to compute, how about something truly invalid like `::-invalid-(&)`
16:29:04 <lea> present+
16:29:04 <fantasai> [Tabatkins summarizes dbaron's comment into audio]
16:29:24 <emeyer> present+
16:29:28 <fantasai> plinss: [asks about option 2]
16:29:48 <fantasai> emeyer: option 2 is consistent with media queries, where we preserve the CSS string for general enclosed
16:29:51 <fantasai> TabAtkins: fair
16:29:55 <emilio> s/emeyer/emilio
16:30:09 <fantasai> [Leaning towards 2 or 3]
16:30:16 <dbaron> I'm also fine with 2.
16:30:17 <fantasai> Straw Poll: Option 2 vs Option 3
16:30:28 <TabAtkins> abstain
16:30:33 <fantasai> abstain (defer to implementers)
16:30:38 <emilio> either wfm
16:30:42 <plinss> 2
16:30:46 <lea> 2 (based on the descriptions in the comment primarily, as I've missed a lot of the discussion due to being on another call)
16:30:46 <Rossen_> 3, 2
16:30:52 <fremy> abstain
16:30:59 <emeyer> abstain
16:31:01 <chris> abstain
16:31:01 <davidleininger> 2
16:31:03 <dbaron> abstain
16:31:05 <florian> abstain
16:31:17 <jensimmons> abstain
16:31:20 <fantasai> emilio: other issue of option 2 is that it changes behavior from today
16:31:40 <fantasai> TabAtkins: in theory, yes, if someone is putting & inside their invalid :is() selector, it will change serialization
16:32:04 <fantasai> emilio: We probalby want to do it for all invalid selectors, so that :unknown is reserialized as-is, regardless of &
16:32:13 <fantasai> TabAtkins: I suggest taking up separately
16:32:43 <fantasai> Proposed to go with option 2
16:33:03 <fantasai> and emilio to open issue about switching serialization for all selectors
16:33:17 <fantasai> plinss: In my mind, would want to be consistent for all selectors
16:33:22 <fantasai> TabAtkins: I agree in theory, don't care too much
16:33:46 <fantasai> RESOLVED: Option 2
16:34:19 <fantasai> TabAtkins: open separate issue for the rest, because it may have a compat risk
16:34:34 <fantasai> plinss: If the other one goes the other way, might want to revert this one
16:34:54 <fantasai> TabAtkins: currently don't have compat either way for & stuff
16:35:02 <fantasai> plinss: Yes, but I want us to note in the other issue to reconsider this one
16:35:19 <emilio> I can open the issue
16:35:27 <fantasai> ACTION: emilio to open new issue
16:35:45 <fantasai> Subtopic: CSSOM for nested media query rules
16:35:52 <fantasai> github: CSSOM for nested media query rules
16:36:03 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7850
16:36:18 <fantasai> TabAtkins: Spec as currently defined alllows you to nest conditional rules and other rules directly inside a style rule
16:36:22 <emilio> https://github.com/w3c/csswg-drafts/issues/8356
16:36:24 <fantasai> TabAtkins: in that context, they can have properties directly in them
16:36:40 <fantasai> TabAtkins: so e.g. div { ... @media something { color: blue; } }
16:36:48 <fantasai> TabAtkins: question is, how do we reflect this in the OM
16:36:54 <fantasai> TabAtkins: CSSMediaRule doesn't have .style
16:37:01 <fantasai> TabAtkins: One possibility is to add .style
16:37:28 <fantasai> TabAtkins: other possibility is treat such properties as wrapped in & { .. }
16:37:37 <fantasai> TabAtkins: They would be exposed in their current OM
16:37:39 <fantasai> ->
16:37:52 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/7850
16:38:13 <fantasai> TabAtkins: I suggest going with #2, because then we don't need to change the OM for any of these rules
16:38:39 <Rossen_> q?
16:38:43 <fantasai> TabAtkins: And also, if you're clearing out an at-rule, currently you can just replace .cssRules but if we add .style then you have to remember to clear out .style also
16:38:48 <fantasai> TabAtkins: So that's my proposal
16:38:57 <fremy> +1 to the second option
16:39:00 <fantasai> TabAtkins: wrap directly-contained properties with `& { ... }`
16:39:20 <lea> q?
16:39:26 <lea> q+
16:39:33 <fantasai> dbaron: Is there a way to distinguish these rules from real ones written that way?
16:39:49 <fantasai> TabAtkins: No, and they would reserialize out with the & { ... } wrapper
16:39:54 <Rossen_> ack lea
16:39:55 <fantasai> TabAtkins: other than that no author-visible difference
16:40:11 <dbaron> s/they would reserialize/we have a followup issue to discuss whether the reserialize/
16:40:19 <fantasai> lea: I think option 2 is find for reading code, but could we author a shortcot for this sort of thing, e.g. adding .style to the OM
16:40:28 <fantasai> lea: to provide a shortcut for creating this rule if it doesn't exist
16:40:41 <fantasai> lea: if you read back .cssRules, it's fine to have the extra rule
16:40:54 <fantasai> TabAtkins: setting .style sometimes creating a new rule is a bit magic
16:40:55 <ntim> ntim has joined #css
16:41:15 <emilio> +1 tab
16:41:15 <fantasai> TabAtkins: for any other case would have to manually construct the rule anyway? So I don't think it's worthwhile to have the additional magic for this case
16:41:29 <fantasai> Rossen_: Lea, what you're suggesting can be added later
16:41:42 <fantasai> lea: yes, that's why I don't feel too strongly about it
16:41:53 <fantasai> dbaron: When I asked if they were distinguishable, I felt they should be distinguishable somehow
16:42:19 <fantasai> dbaron: Seems nice if can reserialize in original form
16:42:26 <fantasai> dbaron: also nice to distinguish
16:42:37 <fantasai> TabAtkins: other than serialization, why distinguish?
16:42:41 <fantasai> dbaron: can't think of anything
16:42:55 <fantasai> dbaron: if there was an accessor on the container for this kind of thing ...
16:43:08 <fantasai> dbaron: then you could compare to see if it's different
16:43:22 <fantasai> dbaron: though maybe that's a bad idea
16:43:29 <emilio> q+
16:43:29 <fantasai> Rossen_: sounds like you talked yourself out of it
16:43:30 <patrickangle_> q+
16:43:41 <Rossen_> ack emilio
16:43:43 <fantasai> emilio: Is this rule always need to be the first one?
16:43:50 <fantasai> TabAtkins: that's a great question, I don't have a strong opinion on it
16:44:03 <fantasai> TabAtkins: e.g. do properties outside rules all glom together ?
16:44:18 <fantasai> TabAtkins: I don't have a strong opinion
16:44:18 <dbaron> s/though maybe that's a bad idea/it would also let you do what lea was asking with a single additional access, if the access implicitly created it, though maybe that's a bad idea/
16:44:24 <Rossen_> ack patrickangle_
16:44:45 <fantasai> patrickangle_: Going back 1 step, we'll need to be able to distinguish for developer tools anyway, so will have to support in the engine even if not Web-exposed
16:44:55 <Rossen_> ack fantasai
16:44:55 <Zakim> fantasai, you wanted to point out cascade issues
16:45:08 <TabAtkins> fantasai: question of whether these glom together or not is pretty important bc it chagnes the cascade implications
16:45:33 <mathtieud> mathtieud has joined #css
16:45:35 <TabAtkins> fantasai: can have a selector that has the same specificity as the &, so if you have interleaved decls and they all have the same specificity, where they occur in order is gonna make a difference as to the output of the cascade
16:45:49 <miriam> +1 - I don't think declarations should get merged like that
16:45:50 <TabAtkins> fantasai: so if decls get glommed together and shifted to the top is something that needs to be definitely decided
16:46:00 <fantasai> fantasai: because that impacts the cascade
16:46:07 <fremy> I would not support "moving to the top" the declarations
16:46:12 <TabAtkins> fantasai: I think we should do whatever we do outside of conditional rules
16:46:13 <matthieud> matthieud has joined #css
16:46:30 <TabAtkins> fantasai: so if outside this context we glom them all together and handle them as occuring before all other rules, then we should do the same thing insdie of conditional rules
16:46:37 <TabAtkins> fantasai: And if it's not, we shouldn't
16:46:46 <Rossen_> q?
16:47:06 <fantasai> TabAtkins: We do indeed effectively glom all the un-nested declarations together outside of conditional rules, so I suggest we glom them together
16:47:18 <fantasai> fremy: I don't like that. I prefer in both cases we create an & rule
16:47:27 <TabAtkins> today, in `.foo { color: red; & { ... } width: 100px; }`, we treat it as equivalent to `.foo { color: red; width: 100px; & {...}}`
16:47:57 <fantasai> TabAtkins: First proposed resolution, properties in a default style rule get auto-wrapped in `& { ... }`
16:48:01 <fantasai> Rossen_: objections?
16:48:29 <fantasai> RESOLVED: properties in a conditional rule get auto-wrapped in `& { ... }`
16:48:59 <fantasai> TabAtkins: For declarations which are not at the top, do we do the same thing as style rules or do we wrap each bunch independently or move them all to the top?
16:49:06 <fantasai> fremy: another option is to make them invalid
16:49:13 <fantasai> fremy: idk if worth considering
16:49:13 <TabAtkins> 1. Similar to style-rules-in-style-rules, treat all nested props as if they occurred together at the top, before any other rules?
16:49:39 <fantasai> fremy: I find it pretty confusing that you can write something after something else, and it's treated as coming before
16:49:48 <TabAtkins> 2. Wrap properties in the default-style-rule where they stand, letting them interleave.
16:50:03 <fantasai> ??: If serialize with .cssText, then  [missed, could be confusing]
16:50:04 <TabAtkins> 3. Treat this as invalid (presumably dropping properties that occur after rules?)
16:50:13 <TabAtkins> s/??/matthieudubet/
16:50:31 <fantasai> TabAtkins: for .cssText, I woudl serialize in canonical form
16:50:55 <fantasai> TabAtkins: assuming we glom together, then if first rule in your .cssRules is & by itself, then we serialize that as naked properties
16:51:05 <fantasai> matthieud: That's what we assume, but then ppl write declarations and then [missed]
16:51:10 <fantasai> matthieud: but maybe it's not an issue?
16:51:47 <fantasai> TabAtkins: My proposed resolution is that we treat interleaved declarations the same way in style rules, i.e. they are all sorted to the top
16:52:05 <fantasai> fremy: Can we resolve to do exactly as for style rules, but then discuss if that's what we actually want for style rules?
16:52:10 <fantasai> TabAtkins: works for me
16:52:17 <miriam> +1
16:52:36 <fantasai> Proposed resolution: do exactly as for style rules wrt sorting of declarations interleaved with style rules
16:52:45 <Rossen_> ack fantasai
16:52:55 <TabAtkins> fantasai: the reason we didn't do it for style rules is we don't have OM ability to support that for style rules
16:53:11 <TabAtkins> fantasai: the expectation is that all decls would be in a .style property, and to do that we can't carea bout their order wrt .cssRules
16:54:01 <TabAtkins> fantasai: So worth pointing out that a .cssRules in a style rule will not contain the naked properties
16:54:01 <TabAtkins> fantasai: So that's different from in conditional rules, which is a little inconsistent.
16:54:12 <TabAtkins> fantasai: So do we really want that inconsistency, or do we want to do something like Lea's proposed magic, or...?
16:54:20 <fantasai> fantasai: but it is inconsistent
16:54:55 <fantasai> TabAtkins: I would have preferred something like this resolution for style rules as well, but for clear legacy reasons we can't do that for style rules -- authors need to be able to manipulate in .style
16:55:11 <fantasai> TabAtkins: but we need to make sure that the cascade is consistently handled
16:55:57 <TabAtkins> fantasai: one thing we could do to keep it consistent is to have .style represent the first &-selector'd rule inside of .cssRules
16:56:03 <TabAtkins> fantasai: and then do that for both style and conditional rules
16:56:13 <Rossen_> ack fantasai
16:56:21 <TabAtkins> fantasai: And all subsequent groups of declarations would each get their own &-rule that would *not* be accessible via .style
16:56:33 <TabAtkins> fantasai: And that would give the same interface for both. It would keep the interleaved order of decls.
16:56:36 <fremy> (what fantasai just described is my preference)
16:56:51 <TabAtkins> fantasai: Not sure if that's what we want, but it would give consistent OM & cascading.
16:57:01 <flackr> flackr has joined #css
16:57:11 <fantasai> s/cascading/cascading while allowing preserving interleaved order/
16:57:20 <fantasai> plinss: [something]
16:57:24 <fantasai> TabAtkins: Yes
16:58:21 <TabAtkins> plinss: An alternative is, inside conditional rules all properties are wrapped in an &-rule, but in a regular style rule the *first* group of properties is not, but later ones do
16:58:53 <TabAtkins> plinss: so in `.foo { color: red; &{...} color: blue; }`, it's equivalent to `.foo { color: red; &{...} &{color: blue;}}`
16:59:03 <TabAtkins> emilio: perf-wise that seems slightly problematic
16:59:07 <Rossen_> q?
16:59:17 <TabAtkins> emilio: not quite clear how it would work with shorthands
16:59:22 <TabAtkins> emilio: I think coalescing them makes sense
16:59:34 <TabAtkins> emilio: otherwise using shorthands becomes different inside a conditional rule vs in a style rule
17:00:02 <TabAtkins> emilio: I'm not a fan of wrapping everything inside of different rules - it means now you have to selector-match more times
17:00:07 <fremy> I am not sure I understood that, but we are out of time, so we should clarify on thread
17:00:09 <jfkthame> jfkthame has joined #css
17:01:16 <TabAtkins> Rossen_: Objections?
17:01:32 <TabAtkins> fantasai: Seems like there ar emore things to consider than we thought at the start, wouldn't be good to resolve yet
17:01:33 <TabAtkins> Rossen_: Okay, take the rest to the thread
17:01:58 <TabAtkins> github-bot: end topic
17:03:02 <Rossen_> Zakim, end meeting
17:03:02 <Zakim> As of this point the attendees have been Rossen_, fremy, dholbert, jensimmons, miriam, plinss, oriol, chris, dbaron, lea, emeyer
17:03:02 <Zakim> RRSAgent, please draft minutes v2
17:03:03 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/25-css-minutes.html Zakim
17:03:10 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
17:03:10 <Zakim> Zakim has left #css
17:03:11 <Rossen_> Rossen_ has changed the topic to: Agenda for Jan 25: https://lists.w3.org/Archives/Public/www-style/2023Jan/0010.html
17:03:52 <Zakim> Zakim has joined #css
17:03:52 <Rossen_> Zakim, start meeting
17:03:52 <Zakim> RRSAgent, make logs Public
17:03:53 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:03:53 <alisonmaher> alisonmaher has joined #css
17:03:53 <alisonmaher> present+
17:03:53 <miriam> present+
17:03:53 <jfkthame> present+
17:03:53 <dholbert> present+
17:03:53 <flackr> present+
17:03:53 <morgan> present+
17:04:03 <plinss> present+
17:04:03 <bramus> present+
17:05:25 <smfr> smfr has joined #css
17:05:42 <TabAtkins> brb, making another coffee (happy to minute when i'm back
17:05:51 <TabAtkins> wait my dang phone just dropped the call
17:06:01 <emilio> present+
17:06:01 <Rossen_> present+
17:06:11 <smfr> present+
17:06:44 <dbaron> Present+
17:07:19 <emeyer> present+
17:07:45 <emeyer> sribenick: emeyer
17:08:16 <fremy> present+
17:08:25 <emeyer> Rossen_: Any changes to the agenda?
17:08:45 <argyle> argyle has joined #css
17:08:45 <emeyer> flackr: Propose breakout session for scroll animations?
17:08:53 <emeyer> Rossen_: Let’s do that on the mailing list
17:08:58 <argyle> present+
17:09:21 <emeyer> fantasai: We should publish updated WD of CSS Nesting, it was last updated 2021
17:10:35 <emeyer> plinss: Want to revert a previous resolution before republishing, but it’s not a big deal since it is a WD
17:10:42 <emeyer> fantasai: Agreed
17:10:43 <lea> present+
17:10:54 <fantasai> s/Agreed/Yes, we can add an issue about lookahead/
17:10:56 <emeyer> RESOLVED: Publish updated WD of CSS Nesting with plinss change
17:11:23 <emeyer> s/plinss change/an added issue about lookahead/
17:11:38 <emeyer> Topic: hyphenate-character doesn't just put hyphen at end of line
17:11:44 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/2975
17:12:06 <emeyer> fantasai: Last two comments on issue clarify that single-string value changes what is inserted, but not where
17:12:20 <jfkthame> +1
17:12:24 <emeyer> Rossen_: Any opinions?
17:12:42 <emeyer> florian: I think it’s the right thing to do for now
17:13:09 <emeyer> …When we look into expansions, we’ll need to think harder about whether this is a novelty thing or about symbols in other languages
17:13:34 <emeyer> RESOLVED: A single-string value changes what is inserted, but not where
17:13:35 <florian> s/symbols in other languages/manually defining hyphenation in unsupported languages/
17:13:53 <emeyer> Topic: Hyphenation styling should apply to the wbr element
17:13:54 <florian> s/a novelty thing/novelty hyphens/
17:13:58 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/5972#issuecomment-826582035
17:14:00 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/5972
17:14:31 <emeyer> fantasai: We propose to close WONTFIX becase <wbr> is a soft-wrap but not a hyphenation opportunity
17:14:52 <emeyer> …HTML could extend itself to do more, but current spec is written that if that ever happens, this will all apply to that correctly
17:15:30 <TabAtkins> +1 to wontfix
17:15:30 <emeyer> RESOLVED: Close WONTFIX
17:15:49 <emeyer> Topic: Better describe the likely outcomes of hyphenation (editorial)
17:15:54 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/5973
17:15:56 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/5973#issuecomment-1366321015
17:16:37 <emeyer> fantasai: We added examples
17:17:10 <emeyer> …and made a normative change to say a hyphenation character property app;lis to soft hyphenation opportunities
17:17:27 <emeyer> s/app;lis/applies/
17:18:03 <emeyer> …if there’s supposed to be a spelling change in a hyphenated word, you should apply that
17:18:17 <emeyer> …we want the UA to make a best effort but it may or may not match up
17:18:31 <fantasai> normative changes -> https://github.com/w3c/csswg-drafts/commit/03935eae48ead18beed74ff665f8724c532b49a9
17:18:44 <emeyer> florian: Examples were added to show these sorts of situations
17:19:24 <emeyer> Rossen_: Anything else?
17:19:28 <emeyer> (silence)
17:19:53 <emeyer> Any objection to these changes, or do we need more time?
17:20:18 <emeyer> florian: We did get a heart emoji on the issue, so there’s that
17:20:31 <emeyer> RESOLVED: Accept changes
17:21:05 <emeyer> Topic: Republishing Tasks Permathread Administrative Tracker For external review / publication tracking issues
17:21:15 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/6900
17:21:41 <emeyer> fantasai: We compiled a changes list and disposition of comments
17:21:52 <emeyer> …There’s a minor change we made as a followup to one of the issues
17:22:05 <emeyer> …Assuming that’s good, we’d like to request an updated CR snapshot
17:22:05 <fantasai> https://github.com/w3c/csswg-drafts/commit/d3ed39e04fb2a3087aa745dce57abd59c93412c5
17:23:07 <emeyer> `text-justify: distribute` addition
17:23:38 <emeyer> fantasai: spec was updated to allow Firefox treatment
17:24:10 <emeyer> florian: About testing, all normative changes since last CR do have tests
17:24:21 <emeyer> …Spec itself has pretty extensive test coverage
17:24:32 <emeyer> …Not complete, but pretty exhaustive
17:24:49 <emeyer> Rossen_: All the more reasons to republish
17:24:57 <emeyer> RESOLVED: Republish!
17:25:05 <fantasai> s/Republish CR/
17:26:04 <emeyer> Topic: Multi-line ::first-letter
17:26:07 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/2254
17:26:16 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/2254#issuecomment-1367476156
17:26:33 <emeyer> oriol: We discussed in the past what happens if first-letter container is very narrow
17:26:41 <emeyer> …And then would span multiple lines
17:26:52 <emeyer> …We resolved to clamp to match characters in the first line
17:27:09 <emeyer> …Focus of the previous proposal was not addressing this question
17:27:29 <emeyer> …Better to discuss this and clarify
17:27:44 <emeyer> …So: what to do if the first-letter container only contains punctuation?
17:28:06 <emeyer> …Spec currently selects punctuation if there’s another letter character that appears later in the container
17:28:34 <emeyer> …This seems strange; if the letter character is in another line and you remove it, this suddenly makes the first-letter able to match punctuation characters
17:28:44 <emeyer> s/able/unable/
17:29:07 <emeyer> …first-letter should only be allowed to match punctuation
17:29:38 <emeyer> …I think Gecko’s behavior makes more sense
17:29:58 <emeyer> …Some prefer the specification as it is now
17:30:32 <emeyer> Rossen_: Opinions?
17:30:41 <emeyer> (silence)
17:31:16 <emeyer> Rossen_: Any objections to resolving on the option to use Gecko’s behavior?
17:31:57 <emeyer> iank_: Basically logic UAs use to skip punctuation characters would have that logic removed?
17:32:24 <emeyer> oriol: Yes, since the only one affected would be Blink, it would need to start matching punctuation-only containers
17:32:44 <emeyer> Rossen_: I believe the answer is yes, Blink can stop skipping punctuation-only
17:33:12 <emeyer> RESOLVED: Restriuction will be relaxed to allow punctuation-only matching
17:33:25 <emeyer> s/Restriuction/Restriction/
17:33:35 <emeyer> Topic: Clarification: do ::placeholder/:placeholder-shown apply to <select>s’ “placeholder label option”?
17:33:43 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/2517
17:33:54 <sanketj> sanketj has joined #css
17:34:10 <emeyer> fantasai: The placeholder-shown example is about validation and it’s not really a placeholder option, it’s just a validation thing
17:34:30 <emeyer> …Tab and I propose to undo previous and have :blank match the default option in a dropdown
17:34:49 <dino7> dino7 has joined #css
17:34:57 <emeyer> s/undo previous and/undo previous resolution and/
17:35:27 <emeyer> TabAtkins: placeholder pseudo doesn’t explicitly refer to validation
17:35:41 <emeyer> …any time your input is empty, it will match ::placeholder
17:36:13 <emeyer> …I agree with Elika, we can revert about adding ::placeholder-select and lean on ::blank for use cases
17:36:28 <fantasai> s/::blank/:blank/
17:36:30 <emeyer> …This will get us where we want without binding us to this weird solution
17:36:48 <fantasai> s/::placeholder-select/placeholder label option to matching placeholder pseudos/
17:36:56 <emeyer> Rossen_: Any objections?
17:37:01 <emeyer> (silence)
17:37:13 <emeyer> RESOLVED: Revert previous resolution
17:38:08 <emeyer> RESOLVED: Revert previous resolution; accept :blank works for this use case
17:38:58 <emeyer> Topic: Should ::first-line include markers?
17:39:02 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/4506
17:39:03 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/4506#issuecomment-1367490644
17:39:24 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/4506#issuecomment-1001846929
17:39:34 <emeyer> fantasai: Does ::marker part of a ::first-line or not?
17:39:40 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/4506#issuecomment-558592436
17:39:44 <emeyer> …A lot of tests were done on implementations
17:40:09 <emeyer> …Proposed resolution is ::first-line includes markers when `list-style-position` is `inside` but excludes them when it’s `outside`
17:40:42 <emeyer> oriol: I think that’s fine
17:40:44 <TabAtkins> No strong opinion from me, but the proposed resolution seems good
17:41:16 <fantasai> emeyer: So this would mean that if list-style-position is outside, and color is set by ::first-line, the marker would not pick up that color
17:41:19 <fantasai> Rossen_: correct
17:42:00 <emeyer> TabAtkins: With outside positioning, it’s positioned, so we’re considering it outside the line
17:42:16 <Rossen_> s/ Rossen_: correct/ TabAtkins: correct/
17:42:24 <emeyer> fantasai: This is important if you set a background color on the first line and it wouldn’t match well with the marker, we don]t want it to apply to that outside marker
17:42:59 <emeyer> s/don]t/don’t/
17:43:25 <emeyer> RESOLVED: ::first-line applies to markers when `list-style-position` is `inside` but excludes them when it’s `outside`
17:43:43 <emeyer> Topic: Should line-height be applicable to ::placeholder?
17:43:48 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/5379
17:43:50 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/5379#issuecomment-1367499300
17:44:31 <emeyer> fantasai: Proposal is to exclude CSS inline layout properties from ::placeholder
17:45:17 <emeyer> Rossen_: Objections?
17:45:31 <emeyer> (silence)
17:46:34 <emeyer> RESOLVED: CSS inline layout properties are not applied to ::placeholder
17:48:07 <emeyer> Topic: Custom properties on :root
17:48:10 <emeyer> github: https://github.com/w3c/csswg-drafts/issues/6641
17:48:18 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1367600040
17:48:42 <emeyer> TabAtkins: Authors often define a big set of custom properties on the root element
17:48:51 <emeyer> …These reasonably might want to be used in highlight pseudos
17:49:02 <emeyer> …Currently, highlight pseudos don]t inherit from the normal DOM tree
17:49:11 <emeyer> …So they won’t see any of the stuff on the root
17:50:11 <emeyer> …The way around that is to have that big block have a selector of `:root, ::highlight`
17:50:11 <emeyer> …It’s a little weird and funky
17:50:11 <emeyer> …There are a few suggestions to address this
17:50:22 <emeyer> …One is to have some kind of at-rule allowing you to apply custom properties at a level higher than the root, which highlight pseudos could see
17:50:43 <emeyer> …Another is to change things so that highlight pseudos resolve their vars against the originating element
17:50:56 <emeyer> …Another is to say highlight inherits all custom properties from the root
17:50:59 <miriam> q+
17:51:02 <bramus> q+
17:51:07 <fantasai> ... and maybe all properties from the root
17:51:17 <emeyer> …I don’t like resolving var() differently
17:51:32 <emeyer> …I think it would complicate or break setting vars directly on highlights
17:51:53 <emeyer> …Inheriting from the root element has possibilies, but could cause cascade problems
17:52:31 <emeyer> …Inheriting just custom properties would be a little weird; it has minimal impact but it’s a new way of doing things that might have implementation problems
17:52:46 <emeyer> …Having a root-superior at-rule is also a new weird way to address this
17:53:13 <bramus> A use-case for inheriting only custom properties is `::backdrop`
17:53:20 <emeyer> …Not really sure how to approach this, but leaving as is where you have to select both root and highlights has some implementor objections over memory cost
17:53:33 <fantasai> bramus, why?
17:54:04 <emeyer> miriam: ::backdrop has a similar problem and it’s caused author problems, and articles are starting to pop up about having to address both
17:54:11 <bramus> Authors want it: https://kilianvalkhof.com/2023/css-html/backdrop-doesnt-inherit-from-anywhere/
17:54:25 <emeyer> …I like ::document or something like that, maybe could also respond to dark and light modes
17:54:36 <emeyer> …I’m not sure a document-selecto toggle could respond, though
17:54:43 <fantasai> bramus, but ::backdrop could just inherit from its originating element like all pseudo-elements, couldn't it? why would you want it to inherit from :root specifically
17:54:52 <Rossen_> ack miriam
17:54:54 <Rossen_> ack bramus
17:55:06 <Rossen_> ack fantasai
17:55:06 <Zakim> fantasai, you wanted to distinguish ::backdrop
17:55:09 <emeyer> bramus: There’s author demand for backdrop inheriting custom props
17:55:41 <emeyer> fantasai: That is a little different, as ::backdrop can inherit from its originating element and we should make it do that
17:55:51 <emeyer> …highlights have to inherit from a tree parallel to the document tree
17:56:02 <bramus> Spec says it doesn’t: https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element
17:56:11 <bramus> “It does not inherit from any element and is not inherited from.”
17:56:11 <emeyer> …I can see reasons why we might want an @document
17:56:36 <TabAtkins> Right, spec says it doesn't, but we can't see any reason *why* it shouldn't inherit.
17:56:46 <bramus> True :)
17:56:51 <argyle> q+
17:56:51 <fremy> +1 to inherit custom properties from :root, I think they are de-facto considered "global" by authors
17:56:51 <emeyer> …Downside to inherit-from-root is that you can only ever get variables from the root, not from other elements between root and the highlight
17:56:57 <TabAtkins> We asked about it in the repo but haven't gotten a response
17:57:09 <Rossen_> ack argyle
17:57:43 <emeyer> argyle: If I do define a bunch of vars on @document I could toggle them, but it’s a good place to put them
17:57:58 <fremy> q+
17:58:00 <emeyer> …The at rule would be the place things are originally defined, but can be changed later
17:58:21 <emeyer> fremy: I don’t see why a document is different form an initial value in this case
17:58:47 <dbaron> argyle, what about miriam's point about things like light/dark mode depending both on media queries *and* an attribute on the root that comes from a user-facing toggle
17:58:55 <emeyer> …Why would we ask authors define things in @document and then ask them to redefine later
17:59:09 <argyle> dbaron:
17:59:29 <emeyer> Rossen_: Any other thoughts?
17:59:38 <Rossen_> ack fremy
17:59:43 <emeyer> (silence)
18:00:06 <emeyer> Rossen_: Do we feel like we’re close to resolution, or should we just capture this and pick it up next week?
18:00:07 <fremy> fremy: (for the minutes, I mentioned how developers already assume :root variables are global, and we could acknowledge them as-is)
18:00:22 <argyle> dbaron: @document { --brand: hotpink }, and for dark mode `@media (prefers-color-scheme: dark) { :root { --brand: deeppink } } .dark { --brand: deeppink }` is what i was thinkin
18:00:23 <emeyer> fantasai: Is there any reason we should NOT have the highlight pseudo inherit from :root?
18:00:53 <emeyer> TabAtkins: If you put color: black on root and then inherit into the highlight, it would break the cascade
18:01:08 <emeyer> fantasai: I think that can work by having the highlight tree break inheritance
18:01:29 <emeyer> …You can have paired default highlight colors happen based on author style rules
18:01:29 <dbaron> s/highlight tree/UA style sheet/
18:01:46 <dbaron> s/inheritance/inheritance for color/
18:02:10 <fremy> @ argyle what is the value of @document here? @property { initial } feels indentical (and, I believe, not that great in this case, you would want the deeppink in dark mode)
18:02:19 <TabAtkins> (I'm completely confused as to what fantasai is trying to say.)
18:02:23 <fantasai> s/highlight tree break inheritance/the UA stylesheet break inheritance/
18:02:33 <TabAtkins> (Either I, her, or both of us dont' understand what we're talking about.)
18:02:49 <emeyer> dbaron: A reason not to add it is that it still doesn’t solve the variables problem when they’re set on something other that the root
18:03:11 <emeyer> Rossen_: We’ll have to close here, the clock has run out
18:03:21 <emeyer> Topic: EOM
18:03:22 <TabAtkins> fremy: Problem with `@property {initial:...}` is (a) it's a lot more verbose than a `--foo:...;`, and (b) initial values can't refer to each other, so you can't set a default composite custom property
18:03:34 <jensimmons> present+
18:03:47 <fantasai> present+
18:04:10 <fremy> @ TabAtkins, ah yes, the compositionality argument makes sense (still feel :root ought to be enough, but different question)
18:04:16 <Rossen_> Topic: end
18:04:29 <TabAtkins> I agree that something just referncing :root is gonna be the best ^_^
18:04:37 <TabAtkins> github-bot, end topic
18:04:55 <emeyer> emeyer has left #css
18:05:09 <Rossen_> Zakim, end meeting
18:05:09 <Zakim> As of this point the attendees have been alisonmaher, miriam, jfkthame, dholbert, flackr, morgan, plinss, bramus, emilio, Rossen_, smfr, dbaron, emeyer, fremy, argyle, lea,
18:05:13 <Zakim> ... jensimmons, fantasai
18:05:13 <Zakim> RRSAgent, please draft minutes v2
18:05:14 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/25-css-minutes.html Zakim
18:05:21 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:05:21 <Zakim> Zakim has left #css
18:06:27 <Linux_Kerio> Linux_Kerio has joined #css
18:07:16 <fantasai> [post-meeting discussion]
18:07:19 <fantasai> fantasai: three options
18:07:24 <fantasai> fantasai: 1. inherit from :root
18:07:39 <fantasai> fantasai: 2. inherit custom properties from originating element, other properties from highlight parent
18:07:54 <fantasai> fantasai: 3. don't manage custom properties on the highlight, have var() look up on the originating element
18:08:08 <fantasai> 1. Doesn't handle subtree variable changes
18:08:18 <fantasai> 2. is hard to implement, because you have two different inheritance models for the same element
18:08:43 <fantasai> 3. has the weird problem that you can't set a custom property and use it in the same declaration block
18:09:14 <fantasai> emeyer indicates that as an author, he'd expect behavior of #2
18:09:50 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/25-css-minutes.html fantasai
18:16:43 <dbaron> On the other hand, it may be in the northern hemisphere summer when the APAC calls are bad for Delan...
18:42:29 <jensimmons> jensimmons has joined #css
19:15:40 <antonp> antonp has joined #css
19:20:03 <jensimmons> jensimmons has joined #css