– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

github-bot, take up w3c/csswg-drafts#13535

[css-values] Clarification on Simplification for clamp() with none values

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13535

TabAtkins: currently the spec for clamp() says it acts like a max/min depending on where you use the value
… [summarizing description]
… per spec Chrome is wrong, doesn't matter much to me how we go on with this
… unless anybody has a reason to care about that behavior specifically, I suggest open a bug on Chrome and close no change

romain: How does this interact with color interpolation, like color-mix where we also have none, where this can be simplified or not
…

TabAtkins: those nones are unrelated keywords, so should not have any effect

romain: I think lea had some note regarding that
… where substituting none in color function is not the same

TabAtkins: you can not write none into a claculation
… so doesn't have any connection with this none, it's not part of calculation, this none is only related as value to clamp()
… so it can't sub-in for that

romain: ok, thanks

emilio: I don't care which way, but in FF it is implemented and was easier to implement.
… I'm ok with no change, it's a bit weird, FF actually does the same thing as Chrome but we did not ship it yet

TabAtkins: so it's ok either way, don't care much

emilio: my opinion is that it's simpler to implement with min/max

astearns: is this an over simplification in any way?

TabAtkins: no, you don't get one or the other, but it's the exact behavior
… we added the none since using clamp() as min/max is more handy

astearns: don't see anyone from WebKit, we could resolve as a way to get their opinion

<emilio> sg

TabAtkins: SGTM

PROPOSED RESOLUTION: when possible we simplify clamp() to min() or max()

astearns: objections?

RESOLUTION: when possible we simplify clamp() to min() or max()

github-bot, take up w3c/csswg-drafts#11924

[css-values] Grammar syntax for defining excluded idents for <custom-ident> productions

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#11924

<astearns> github-bot: none

<github-bot> astearns, Sorry, I don't understand that command. Try 'help'.

none

github-bot, take up w3c/csswg-drafts#9451

[css-typed-om-1] Should css typed om support the same simplifications as css-values-4?

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#9451

emilio: this is about calc simplification, since we were implementing typed OM we had to add a lot of stuff to avoid,
… seemed silly since no one else added it

TabAtkins: it was intended to reflect what you suggest, but was overlooked, let's add this simplifaction and not hold to intermediary info

astearns: and we need to ammend WPTs?

TabAtkins: yes

PROPOSED RESOLUTION: calculation trees easily simplifies in all representations, including in exposed in Typed OM

astearns: objections?

RESOLUTION: calculation trees easily simplifies in all representations, including in exposed in Typed OM

github-bot, take up w3c/csswg-drafts#13211

[css-properties-values-api] `@property` descriptors should be optional whenever possible

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13211

TabAtkins: for now, for reasons we designed in the past, the @property does not give optional default values, all needs to be specified
… it proved to be annoyance in practice
… it's also been annoying in spec writing
… proposal is to make all descriptors in the @property optional as if it was untyped

<kizu> +calc(infinity) to the proposal

TabAtkins: I saw nothing but support on the thread

<ydaniv> +1

<miriam> +1 strong support

<kbabbitt> +1, this will also make writing supports-conditions for these easier

astearns: anyone with reservations? or need more time?

PROPOSED RESOLUTION: make all property descriptors in @property optional

astearns: objections?

emilio: I think we also do validation on the descriptors, they need to match syntax

TabAtkins: only change that if you specifty a non universal it needs to match syntax
… otherwise we keep existing behavior

kizu: +Infinity, only care about interop where authors do this but may start doing something some browsers, but still break in others

TabAtkins: true, we can see later?

astearns: would you like to resolve? or wait?

kizu: resolve please

<TabAtkins> interop is people wrote an *invalid* rule, got a normal custom prop, but now get *some* behavior

romain: don't see any interop issue, since unregistered is the same as fallbacks we have now

TabAtkins: [repeating above] ^

kizu: or specify something that was not applied and now stops applying to things that don't match anymore

<romain> +1

astearns: so are we still trying to resolve and see whether there's a problem?
… objections? (again)

RESOLUTION: make all property descriptors in @property optional

github-bot, take up w3c/csswg-drafts#11924

[css-values] Grammar syntax for defining excluded idents for <custom-ident> productions

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#11924

TabAtkins: this one is about how custom-ident does not match
… Sam wanted to make it explicit in the grammar

<TabAtkins> <'property'> = <custom-ident> - [ none | foo | bar | baz | something-long ]

<romain> +1

TabAtkins: there are a lot of proposals for syntax, I slightly prefer a - combinator
… you must have a custom-ident on the left, and on the right the keyword

<TabAtkins> <'property'> = <custom-ident -[ none | foo | bar | baz | something-long ]>

TabAtkins: other suggestions are to put it directly into the custom-ident
… ok with any proposal if anyone has strong opinion

<fantasai> <'property'> = <custom-ident ![ none | foo | bar | baz | something-long ]>

<fantasai> was also proposed

fantasai: unless we want to make this a general combinator, ...
… we should keep it inside the brackets
… otherwise it would be the tightest operator

<TabAtkins> s/\[missed\]/tightest/

fantasai: between the 2 things I posted, if it's a combinator I prefer the - because it feels more like a combinator, and if it's incorporated, I prefer the !. - reads like a dash, which we use for other purposes

fantasai: the brackets serve as a grouping operator

<fantasai> s/prefer the -, and if it's incorporated, I prefer the !. - reads like a dash, which we use for other purposes/

kizu: off topic a bit, but nice to have for @property to use this there as well

TabAtkins: after we resolve please open an issue on that

kizu: sure

<romain> slight preference for <custom-ident ![ none | foo | bar | baz | something-long ]>

weinig: fine with anything, I think for those who wanted to do more, would be good to aggregate what's not specified by the grammar and add that as well
… but interested in how we can get this done better

<dbaron> I somewhat like weinig's original suggestion of excludes=

astearns: sounds like we're converging around using !

dbaron: not a strong opinion but I kind of like the original suggestion of excludes but could be too verbose

TabAtkins: don't mind, all reasonable

fantasai: we don't really use a keyword exclusion operator

<TabAtkins> current modifiers are just: a plain `[...]` bracket, for ranges, and now would add `![...]` bracket for exclusions

astearns: as spec production would be nice to have, a readable keywords seems ok to me

<TabAtkins> Notably CSS is the rare language where ! does *not* meant "not" lol

fantasai: this would be the first place where we'd have an identifier as a syntactic operator, and not need to go in that direction

TabAtkins: leaning towards what fantasai said

astearns: dbaron you want to argue more for the keyword?

dbaron: ok with !

<fantasai> PROPOSED: <'property'> = <custom-ident ![ none | foo | bar | baz | something-long ]>

PROPOSED RESOLUTION: we add a new ! brackets group to the custom-ident terminal to add keywords which are excluded from production

astearns: objections?

RESOLUTION: we add a new ! brackets group to the custom-ident terminal to add keywords which are excluded from production

RESOLUTION: Adopt <'property'> = <custom-ident ![ none | foo | bar | <non-terminal> | something-long ]>

<astearns> github-bot, take up w3c/csswg-drafts#12735

[css-properties-values-api] `light-dark()` and system colors in initial values

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#12735

TabAtkins: props and values API says initial values have to be computationally independent
… question is does this mean that stuff like color scheme are not computationally independent?
… answer is yes, I don't think we need to add anything, it follows the definition
… since someone thought this is unclear, we could add a note
… I think we can resolve close no change

dbaron: what's the current state of the computed value of system colors. Does it compute to keywords or to colors?

emilio: I think we ended up computes to color

<kbabbitt> system colors compute to color values

miriam: I think that's right in existing spec, my question is do we need to keep this restriction?
… it's not the way authors think about custom properties
… if we don't need it we should not have it

emilio: it would be quite weird
… it's a restriction custom properties is known to have, I'd have to think how easy it is to remove this restriction

TabAtkins: we have some color stuff here that is used as initial values in custom properties, but between the color property itself and several other properties which depend on other properties, it's a funky case

<emilio> color is also not quite that, because currentcolor computes to itself

TabAtkins: however, outside of color where we do use initial value like em it's calculated like initial em
… it seems weird to authors it's not resolving the same as set on the element they set it on

miriam: I get the complexity, but authors don't have a good way to set a global initial defaults
… it needs a lot more teaching, or some better way to help authors set both, global defaults that can be relative, and initial value

TabAtkins: would love to chat more on the use-cases, and see what are your expectations

dbaron: one thought is what an initial value means is different between inherited and non-inherited
… on inherited it's used only on the root, as opposed to non-inherited
… if you wanted this it would be harder to work around the non-inherited ones

astearns: miriam would want to discuss the general authoring problems here?

miriam: will open a new one

astearns: so for this resolution we decide to add an example?

TabAtkins: yeah

PROPOSED RESOLUTION: Add an example as to why this case is computationally independent

astearns: objections?

RESOLUTION: Add an example as to why this case is computationally independent

github-bot, take up w3c/csswg-drafts#12791

[css-backgrounds][css-animations] Should background-* and animation-* longhands computed values serialize using the same truncation rules?

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#12791

weinig: this is about whether compat will hold up here, animations/background longhands are coordinated lists
… wanted to know if we want to resolve on compat serializations

TabAtkins: in one of the properties having one tramps the others, in the other it's not
… I just care about having a consistent behavior

weinig: not sure even all browsers do that, it's just what WPT test
… should be as round-trippable as possible
… I would be sticking with what the spec says should be correct

emilio: seems FF is already doing that
… so probably compatible

<emilio> https://wpt.fyi/results/css/css-backgrounds/parsing/background-repeat-computed.html

weinig: ok, thanks

fantasai: I support what TabAtkins said, don't have opinion on which way as long as Web-compatible
… backgrounds is a canonical example for coordinating list property group, spec doesn't use the term because it predates the term

weinig: I think background is the one where it does not match the spec's behavior
… but in FF seems ok

dbaron: one thing that can happen, gCS and computed value are different things
… I would not like the truncation to be different, but it is today in some implementations so should be careful
… I think my prefs aggree with weinig, so that both computed value and gCS return the same value

weinig: they should likely match, and I'll ensure on WPT we have something we're explicitly testing

dbaron: there were some implementations that did weird thing to the computed value, don't know if these are still around today

astearns: should we resovle on what we wish to see? and look for compat concerns? Or make smaller viable changes?

weinig: this mostly comes down to changing background and mask-image in WK and CH, and update tests
… probably tests first

astearns: updating the tests makes sense if we updated spec

weinig: the spec is correct

dbaron: side comment, if we do find a compat problem here, I'd like to keep the background and mask matching, then to try and make them match others

<fantasai> +1 dbaron

<ydaniv> +1 dbaron

PROPOSED RESOLUTION: no change, update WPT to match the spec's expectations and see if there's web compat issues

astearns: obejctions?

RESOLUTION: no change, update WPT to match the spec's expectations and see if there's web compat issues

end

Mar 11 agenda: https://lists.w3.org/Archives/Public/www-style/2026Mar/0008.html

<TabAtkins> github-bot, take up w3c/csswg-drafts#12812

Fragmenting (`continue: collapse`) line-clamp containers

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#12812

<TabAtkins> andreubotella: How do we handle a line-clamp container in a fragmentation context, like multicol

<TabAtkins> andreubotella: browsers differ, sometimes broken

<TabAtkins> andreubotella: also, what should happen when the line-clamp container itself has columns/etc

<TabAtkins> andreubotella: I think if we want to make them fragment, wk's behavior is what we'd want

<TabAtkins> andreubotella: You just slice the line-clamp container into fragments. the co9unt is preserved across the fragment break, and the height is the total height including the slice gap

<TabAtkins> andreubotella: this is WK's current -webkit-line-clamp behavior.

<TabAtkins> andreubotella: for clamping by height, they don't currently support it by defualt

<TabAtkins> andreubotella: also, overflow:hidden, which is used everywhere in webkit-line-clamp as its a required property there

<TabAtkins> andreubotella: depending on browser, it can make the box model different

<TabAtkins> andreubotella: with line-clamp you don't need that overflow, but maybe we should make it automatically make the content monolithic

<TabAtkins> andreubotella: chromium does that by default, except when you set columns on the actual line-clamp container

<TabAtkins> andreubotella: (which seems to be a bug)

<TabAtkins> andreubotella: in WebKit where you're slicing the result into multiple columns, this is relatively easy to do

<TabAtkins> andreubotella: main problem is taking into account the gap between columns when clamping by height

<TabAtkins> andreubotella: but in engines where it fragments it's more complicated

<TabAtkins> andreubotella: so, should we allow this? what to do about it?

<TabAtkins> andreubotella: there's also a question - if you have display:block or flow-root the columns proeprties works, but not -webkit-box or float.

<emilio> I think we resolved on it happening at computed value time? So it should apply per spec I think

<TabAtkins> florian: when it comes to 'column' applying directly to a clamp container, not sure when we took a resolution but I think we did take one that says it won't apply

<TabAtkins> florian: the original draft for continue:discard explicitly worked with Multicol and the new value changes that

<TabAtkins> florian: so I think we did make a decision at some point and we should probably stick with it

<TabAtkins> florian: when instead it is *in* a fragmentainer i'd prefer fragmenting properly. i'd be okay with monolithic, don't see much use-cases there. would be sad about slicing in the middle of a line.

<TabAtkins> florian: can you reexplain WebKit behavior?

<TabAtkins> andreubotella: visually it behaves as fragmenting properly. but the layout engine basically does it in one single fragment, leaving the gap, then slices

<TabAtkins> florian: okay so it looks like it's fragmenting properly, that's fine

<TabAtkins> andreubotella: in layout engines that do it "properly" it's just a bi tmore complicated, is why I mentioned it

<TabAtkins> andreubotella: you need to keep track of the gaps and ...

<TabAtkins> andreubotella: when clamping by height you're not sure if you clamp until you've started working on the next fragment. that's a bit more complicated

<TabAtkins> florian: it seems better to do the full fragment, but use-cases dont' seem strong. so if the monolithic beahvior is simpler that's ok by me

<TabAtkins> emilio: I agree monolithic is simpler

<TabAtkins> emilio: per spec, we resolve on -webkit-box to flow-root fixup to happen at computed value time, and it seems clear what happens there

<TabAtkins> florian: we could make an exception if we wanted to...

<TabAtkins> emilio: sure but why would we

<TabAtkins> andreubotella: if you agree that's what the spec implies, that's probably correct

<TabAtkins> andreubotella: I wasn't 100% sure

<TabAtkins> astearns: let's table that aspect for now, you can raise an issue if it turns out to still be important. want to concentrate on line-calmp containers in a fragment context

<TabAtkins> fantasai: I agree with florian that we should fragment properly

<TabAtkins> fantasai: don't have a strong opinion on a line-clamp that is also fragment context

<TabAtkins> fantasai: but *in* in a fragment context should do correctly, counting across the whole thing

<TabAtkins> fantasai: you just have to walk backwards when counting

<TabAtkins> emilio: our fragment breaks are always after a line... ok

<TabAtkins> emilio: it should be well-defined in terms of line count

<TabAtkins> astearns: so it sounds like we're converging on "properly" fragmenting line-clamp containers, taking wk's impl as a guide

<TabAtkins> andreubotella: in layout engines like chromium that's a bit harder. at the point where you're doing layout on the second fragment you can't modify the first anymore

<TabAtkins> andreubotella: so you'd have to make sure the clamp won't happen in the first frag

<TabAtkins> andreubotella: so more complicated but doable

<TabAtkins> emilio: I think was gonna suggest similar

<TabAtkins> emilio: if you grow the block past the clamp point, which you can by setting the height to a tall number, you can end in a situation where the clamp is in the previous fragment, line -1 basically

<TabAtkins> emilio: should be fine to treat it as zero or something. maybe a bit weird

<TabAtkins> emilio: but I think it's not a common use-case ,shoudln't matter much

<TabAtkins> astearns: proposed then, we will specify "actual" fragmentation for line-clamp containers in a fragmentation context, work out details as we go

<TabAtkins> astearns: objections?

RESOLUTION: we will specify "actual" fragmentation for line-clamp containers in a fragmentation context, work out details as we go

<TabAtkins> astearns: do we want a resolution on a line-calmp container that *is* a Multicol, or a separate issue?

<TabAtkins> florian: if anyone wants to argue it should apply... currently spec says it doesn't and i'm okay with that

<TabAtkins> (I think it's reasonable to forbid it, seems weird)

<TabAtkins> astearns: hearing no one calling for it, we'll leave it as specified

<TabAtkins> github-bot, take up w3c/csswg-drafts#12814

[css-pseudo] Allow animations on ::first-letter and ::first-line similar to ::marker

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#12814

<TabAtkins> astearns: looks like convo says "yeah let's do it"

<TabAtkins> dbaron: i'm not sure how much the specs for ::first-letter/line and impls match right now, and before we add animations we should make sure they agree

<emilio> +1

<TabAtkins> dbaron: for things like what inheritance and fictional tag sequence is

<TabAtkins> dbaron: the other thing I'm unsure about is whether it's asking only about CSS animations, or about animations and transitions

<TabAtkins> dbaron: when people talk about animations they sometimes mean T&A, and I think transitions is scarier if we don't have that interop

<TabAtkins> (agree, animations seems pretty clear in its behavior, it's just setting values. reacting to values in transitions is trickier)

<TabAtkins> emilio: agreed

<TabAtkins> emilio: intention seems to be the computed values apply to the root of the first-letter style "box", and whatever comes out of inheritance from that just "happens"

<TabAtkins> emilio: given the state of interop for these pseudos, i'm not a fan of piling more stuff into it before solving those issues

<TabAtkins> astearns: and while I summarized the convo as 'let's do it', I was reading Rob's comment wrong. he was saying "there's no reason not to, except it would be hard"

<TabAtkins> flackr: right, I was saying it' is unlikely we could implement soon because eit would be complicated

<TabAtkins> fantasai: I feel like theoretically there's no strong reason to not do it, but if it's difficult to impl it's not a high prio

<TabAtkins> fantasai: it sounds like the issue is non-tree-abiding pseudos

<TabAtkins> fantasai: and for tree-abiding it's fine?

<TabAtkins> flackr: right

<TabAtkins> fantasai: so the resolution could be that animations and transitions aren't supported on non-tree-abiding

<TabAtkins> flackr: safari today does support *animations* on them

<TabAtkins> fantasai: so MAY support, optional?

<TabAtkins> flackr: maybe yeah. transitions is the tricky one, need to figure out when it happens. style change from an ancestor, or just from the pseudo itself? complicated. didn't test if safari supports them.

<TabAtkins> fantasai: I think if you have an El and it's transitioning, the child functionally transitions due to inheritance but isn't considered to be transitioning

<TabAtkins> fantasai: think it would be similar

<TabAtkins> flackr: so I think elika's point is every browser supports tree-abidng pseudos, so it would be good to clarify that's required

<TabAtkins> astearns: on the "may" thing, maybe leaving the spec saying nothing about non-tree-abiding might be better...?

<TabAtkins> fantasai: we're not allowing "whatever". I think we can specify... if there's details like what rob mentioned we can clarify them

<TabAtkins> fantasai: conflicts would be on certain non-tree-abiding ones. but to the extent that impls can figure it out for some, we should allow it

<TabAtkins> fantasai: so I think we should be clear - a&t are allowed on pseudos, but for non-tree-abiding they're optional

<TabAtkins> fantasai: so impls might be a ble to figure it out for highlights but not first-letter or wahtever

<TabAtkins> fantasai: these are a progressive enhancement, I think it's okay to be optional

<TabAtkins> astearns: I agree if optionality is meant to be a temp stopgap

<TabAtkins> astearns: if there's a plausible way forward

<TabAtkins> fantasai: I think in an ideal world we should get there

<TabAtkins> fantasai: but if someone is really excited about getting ::first-letter implemented, they should go for it

TabAtkins: wrt optional and progressive enhancement, I agree about transitions being an enhancement. Let's nail down details.

TabAtkins: Don't agree for animations. They are often not a progressive enhancement, can break content if they don't work.

TabAtkins: I think for non-tree-abiding, we should take a definite yes/no on animations

TabAtkins: and I would lean towards yes

TabAtkins: because theyr'e simpler

TabAtkins: but leave them unspecified now

<TabAtkins> astearns: but if we have a yes on animations, we run the risk on the spec being fiction since it doesn't seem to be a priority

astearns: But if we have a yes on animations, we run risk of spec being fiction, since not a priority or easy to add to engines that don't support

<TabAtkins> TabAtkins: wk supports animations right now, sometimes only one browser supports a feature for a while, that's fine

<TabAtkins> fantasai: for animations on content generally I agree, but for non-tree-abiding pseudos which are very limited, I don't think I agree. a shimmery highlight or something

TabAtkins: If you set an animation to make shimmery, need to make sure you have base styles that are readable.

TabAtkins: Authors will assume animations exist, and not have good base styles

TabAtkins: So worried about that

<TabAtkins> fantasai: do authors in the room have an opinion on that?

<TabAtkins> flackr: for the other point, we do have things that are specified but not supported in all browsers yet. i'm okay with that. we're clearly not opposed to the behavior

<TabAtkins> romain: as an author i've never written fallbacks for an animation not working, so I agree with Tab that it could be bad

<TabAtkins> romain: it's fine if an animation doesn't play and just skips to the end, but it should *work*

TabAtkins: Let's spec that animations and transitions work on all tree-abiding

TabAtkins: On non-tree-abiding, animations work, and transitions are intentionally optional right now.

<TabAtkins> astearns: i'm fine with that, but it does somewhat go against the idea that authors will write animations that work fine in WebKit and fail in other engines

TabAtkins: That happens with plenty of properties that are supported in one browser and not others.

TabAtkins: We prefer wide support.

TabAtkins: I think it's fine as a temporary state of affairs, to have things be in one browser

TabAtkins: OK for browser to go ahead of each other in various ways

<TabAtkins> astearns: so we have two proposed resolutions, for tree-abiding and non-tree-abiding

<TabAtkins> astearns: any tweaks to those?

<TabAtkins> astearns: objections to the resolutions in IRC?

RESOLUTION: animations and transitions work on all tree-abiding

RESOLUTION: On non-tree-abiding, animations work, and transitions are intentionally optional right now.

[css-font-loading] Lack of interop on FontFace constructor.

<TabAtkins> astearns: Emilio had to drop, but his final comment has his current suggestion: quote invalid font-family names rather thanr ejecting the constructor

<TabAtkins> TabAtkins: I'm fine with that

<TabAtkins> astearns: objections?

<TabAtkins> fantasai: if that's what jfkthame says to do, i'm fine with it

RESOLUTION: If a FontFace is constructed with an invalid font-family name, treat it as a quoted string rather than throwing

<TabAtkins> github-bot, take up w3c/csswg-drafts#865

[css3 positioning] support position:sticky inside an overflow:hidden|auto on general parents

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#865

<TabAtkins> flackr: we decided in another discussion that it's reasonable to create a scroll container that onlys scrolls in one axis, and is clip in the other

<TabAtkins> flackr: following this line of thought, we can support... one of the use-cases for postiion-sticky responding to an ancestor scroll container, by saying the position-sticky in each axis looks for the nearest container that scrolls in that axis

<TabAtkins> flackr: this is a fairly constrained change, doesn't require new syntax, and supports horiz-scoll tables in vertical-scroll docs

<TabAtkins> flackr: we've tested it and it seems to work fine. does what users expect

<TabAtkins> flackr: so the proposal is that sticky can use different containers for each axis

<TabAtkins> astearns: does this cover the original test-case?

<TabAtkins> flackr: the original was relying on the implications of overflow:hidden... there are other APIs that can get that to work, I posted a demo

<TabAtkins> flackr: my proposal handles the either novel use-case which wasn't handled previously, which can be sticky-translated in different axises by different scrollers

<TabAtkins> kizu: this is really nice to have. only concern is interop

<TabAtkins> kizu: a sticky element that previously didn't work well could start working and sticking

<TabAtkins> kizu: but it would be really nice for this to work

<TabAtkins> flackr: we expect that, since to set the container up you have to explicitly set overflow:clip on the off-axis, it'll be rare that existing content gets into this use-case

<kizu> Ah, yes, with `clip` is will be for sure safer

<TabAtkins> flackr: so I expect it to be safe, but experience will tell

TabAtkins: Just need to document this use case in the spec, to make clear that it works

<smfr> seems fine

ACTION: flackr to put example in the spec

<TabAtkins> astearns: proposal is position:sticky tracks the nearest scrolling container *per axis*

<TabAtkins> astearns: objections?

RESOLUTION: position:sticky tracks the nearest scrolling container *per axis*

<TabAtkins> flackr: this is a long issue, there might be other use-cases but the two I mentioned seem to be the main ones

<TabAtkins> github-bot, take up w3c/csswg-drafts#1525

[selectors] pseudo selector to match forms ValidityState

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#1525

<TabAtkins> astearns: Sebastian put this on the agenda but he's not here. there was a clarification he wanted to make. is anyone read up enough to talk about this?

<TabAtkins> astearns: skipping until Sebastian is available

<TabAtkins> github-bot, take up w3c/csswg-drafts#12495

[cssom-view] How to fulfill programmatic scroll promises?

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#12495

<TabAtkins> flackr: we're resolved to have promises when you invoke scrolling methods

<TabAtkins> flackr: there were open questions about two main things, I think

<TabAtkins> flackr: one, in the original resolution we discussed having a way to tell the difference between a scroll that was interrupted and one that was completed. but that didn't make it into the spec text. we'd like to resolve the promise with a scroll result dictionary that tells the status

<TabAtkins> flackr: happy to bikeshed on the property for that

<TabAtkins> flackr: two, how to handle interruption of particular promises

<TabAtkins> flackr: points 2 and 3 in the issue

<TabAtkins> flackr: for 2, we expect only scrolls that interrupt a particular scroller will resolve the promise for that scroller

<TabAtkins> flackr: for 3, a scroll promise for scrollIntoView is effectively like waiting for all the affected scrollers. so until all the scrolls are interrupted or completed it doesn't resolve. and when they are all resolved, we resolve the whole thing

<TabAtkins> smfr: i'm curious about scrollIntoView. on a nested scroller it might not scroll enclosing scrollers if they don't need to

<TabAtkins> smfr: so do they interrupt an ancestor scroll only *if* they need to change a position?

<TabAtkins> flackr: the intention is to track what the browser actually does with the scroll

<TabAtkins> flackr: so if you have an ongoing smooth scroll and you call scrollIntoView(), does it cancel the smooth scroll? If so, it should cancel the promise too

<TabAtkins> flackr: I believe it *should* cancel, you presumably want to stop the earlier scroll to honor the scrollIntoView request

<TabAtkins> smfr: seems reasonable

<TabAtkins> smfr: there's also a lot of logic in webkit to coalesce user scrolls

<TabAtkins> smfr: if you scroll with smooth and and then without smooth, the second clobbers. I guess that means the first is canceled

<TabAtkins> flackr: yes

TabAtkins: For scroll-into-view, are you planning to re-use existing promise machinery?

TabAtkins: so will get back array of scroll results, or something else?

flackr: Was thinking to have a single scroll result. Hard for developers to reason about an array

flackr: [missed]

<TabAtkins> ydaniv: regarding rejecting the promise, a canceled scroll. should be consistent with how we reject on canceled animations, with aborterror

<TabAtkins> flackr: therew was a prior discussion on scroll promises where we're not rejecting them. it would raise compat issues due to a surprising new error

<TabAtkins> flackr: so we instead resolve successfully, with a result that says it's interrupted, not a rejection

<TabAtkins> (agree, it's fine for this to be a non-exceptional result)

<TabAtkins> smfr: just checking, scrollIntoView() returns a promise?

<TabAtkins> flackr: yes

<TabAtkins> smfr: what about implicit ones like focus?

<TabAtkins> flackr: the dev can't get at that promise

<TabAtkins> smfr: okay, so you're not planning on exposing the indirect scrolls' promises

<TabAtkins> flackr: no

<TabAtkins> smfr: that's fine

<TabAtkins> astearns: are we going to resolve to let Rob do what he thinks is reasonable here, or be more explicit?

<emilio> More explicit is better :)

<emilio> But what rob said sounds good

TabAtkins: Everything Rob said sounds good, so happy to defer to him

PROPOSED: flackr to update spec with what he's outlined

RESOLUTION: Rob update the spec per his comment. Can dig into particular details as needed.

[css-images-4] Add `light-dark-image()`, or generalize `light-dark()` for images too?

TabAtkins: We already have light-dark() for colors, makes it very convenient to write colors inline without indirection

TabAtkins: Similar request for other types of values, but the most important one is images. Identical use case to colors.

TabAtkins: a lot of agreement in the thread that this is a reasonable request

TabAtkins: proposal is that we either augment light-dark() to allow pair of colors OR pair of images, and resolves accordingly

TabAtkins: or we add a new function, light-dark-image(), same as light-dark() but accepts images instead

TabAtkins: Thread leans towards augmenting light-dark()

TabAtkins: There's further questions about allowint more values than just colors or images

TabAtkins: I prefer to not do that right now

TabAtkins: Partly because it has some parsing complications

TabAtkins: and also, we do have the ability to do that with if()

TabAtkins: and the use cases are rarer

TabAtkins: So proposing to allow light-dark() to accept pair of images

emilio: I agree with Tab's proposal

<ydaniv> +1 TabAtkins

emilio: Third alternative is to make it an arbitrary substitution thing, but it makes problems especially for images

emilio: image caches, etc.

emilio: So keeping it simple, and if you want something complicated use if()

emilio: I haven't heard requests for any requests for anything else from FF frontend folks

astearns: So you implemented light-dark(<img>, <img>)?

emilio: yeah

<dbaron> Is there any complexity here about url() versus image() ?

astearns: I don't have a strong opinion on which way to go syntactically

astearns: Thinking about other extensions, overloading seems better than creating a new function per type

TabAtkins: If we branch out into more thing, grammar issues become more difficult.

<dbaron> (had to go, past 1pm)

TabAtkins: colors and images are 100% distinct (and should always be), but not doing that rn

TabAtkins: so we can address in the future

smfr: People have been talking about URL arguments. Can you nest these?

emilio: Yes

emilio: And you can have the color version inside your gradient

emilio: could even nest that inside the image light-dark

[seems weird but doable]

PROPOSED: Overload light-dark() to accept image pairs

RESOLUTION: Overload light-dark() to accept image pairs

end