17:05:13 <RRSAgent> RRSAgent has joined #css
17:05:17 <RRSAgent> logging to https://www.w3.org/2025/11/05-css-irc
17:05:17 <emilio> ... without reasons to have different syntax we should go for that
17:05:17 <emilio> q+
17:05:17 <Zakim> RRSAgent, make logs Public
17:05:19 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:05:19 <Rossen9> Zakim, start meeting
17:05:19 <Zakim> RRSAgent, make logs Public
17:05:20 <emilio> q+ TabAtkins
17:05:21 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:05:21 <Zakim> RRSAgent, make logs Public
17:05:22 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:05:22 <emilio> q+ later
17:05:43 <schenney> schenney has joined #css
17:06:06 <emeyer> emeyer has joined #css
17:06:06 <Rossen9> ack emilio
17:06:07 <emilio> TabAtkins: I agree with fantasai and dbaron's comment on the thread
17:06:14 <dholbert> scribe+
17:06:15 <emeyer> present+
17:06:17 <emilio> ... don't want to resolve us into any particular syntax
17:06:26 <emilio> ... but the right idea is to go ahead is to remove the syntax from the proposal
17:06:26 <Rossen9> present+
17:06:52 <emilio> ... instead of having a specific /for/ we have a note that this is indeed how we're likely to do future combinators
17:07:07 <dholbert> emilio: I was going to say something similar
17:07:19 <emilio> ack emilio
17:07:27 <dholbert> emilio: resolving on the specific syntax seems premature, but generally this seems fine
17:07:34 <jfkthame> present+
17:07:38 <emilio> florian: I'm a bit confused, because tab seemed to agree and disagree with lea at the same time
17:08:01 <emilio> TabAtkins: I was a bit distracted, might be agreeing with her if lea's position has changed
17:08:13 <emilio> dbaron: some of the nuance is about some things in the draft
17:08:20 <emilio> ... that probably shouldn't be in there in its current form
17:08:32 <emilio> florian: but as a design principle it seems ok with everybody?
17:08:41 <flackr> present+
17:08:57 <emilio> dbaron: what I was going to try and add is that we've talked about this idea enough that we should probably document it
17:09:02 <castastrophe> q+
17:09:08 <emilio> ... specially since we are out of characters
17:09:20 <emilio> ... with the exception of one that would be pretty bad
17:09:31 <PaulG> PaulG has joined #css
17:09:31 <emeyer> +1 to bramus!
17:09:32 <TabAtkins> I mean, we've got $, %, ^...
17:09:35 <PaulG> present+
17:09:36 <lea> q?
17:09:36 <emilio> castastrophe: do we have an adjacent document to document these kinds of things?
17:09:43 <Rossen9> ack castastrophe
17:09:51 <emilio> lea: we could do a lot better in that respect
17:09:57 <emilio> ... we have some design principles in the wiki
17:10:03 <castastrophe> *documentation adjacent to specifications
17:10:04 <emilio> ... tag has a css design principles section
17:10:11 <emilio> ... but no canonical source
17:10:16 <emilio> ... which isn't great
17:10:36 <emilio> dbaron: yeah on the wiki except nobody reads it... If we want to make a note of it I think it's fine to be a doc in the spec
17:10:47 <emilio> lea: I think it's useful for anyone proposing future syntax
17:11:04 <Kurt> https://wiki.csswg.org/ideas
17:11:07 <emilio> ... but tangentially we should have a canonical source for design principles
17:11:09 <castastrophe> q+
17:11:12 <emilio> Rossen9: worthy effort
17:11:17 <emilio> ... hopefully someone could pick it up
17:11:17 <emilio> q+
17:11:25 <Rossen9> ack castastrophe
17:11:31 <emilio> castastrophe: I was thinking generally +1 to adding some documentation to the spec
17:11:31 <Kurt> Kurt has joined #css
17:11:36 <fantasai> https://wiki.csswg.org/ideas/principles :)
17:11:46 <emilio> ... would be useful to document the unused ascii chars that are still available for doc purposes?
17:11:49 <emilio> lea: no objection to that
17:12:01 <emilio> dbaron: it might be tricky to say what counts as available, but sounds fine
17:12:22 <dholbert> emilio: more to the point than the design principals thing... have we considered other syntaxes that aren't slashes?
17:12:31 <dholbert> emilio: to me, angle-brackets feel more combinator-y
17:12:40 <bkardell> bkardell has joined #css
17:12:42 <Rossen9> ack emilio
17:12:45 <dholbert> emilio: like <for>; that would parse potentially differently
17:12:49 <bkardell> present+
17:12:52 <miriam> present+
17:12:55 <dholbert> dbaron: given the existing child selector, that might not go over very well
17:13:01 <dholbert> emilio: seems parseable... but anyways
17:13:14 <dholbert> lea: there have been proposals for a < combinator that goes the other way, which would make this ambiguous
17:13:23 <alisonmaher> alisonmaher has joined #css
17:13:36 <emilio> ack fantasai
17:13:37 <Rossen9> ack fantasai
17:13:44 <emilio> fantasai: I think we can resolve on removing the existing idref feature
17:13:55 <emilio> ... and potentially to put a not along the lines that dbaron mentioned
17:14:04 <emilio> ... for future named combinators
17:14:26 <emilio> Rossen9: there's also castastrophe's proposal to document the available ones
17:14:50 <emilio> fantasai: Isn't that just ascii punctuation minus the set of used chars?
17:15:03 <emilio> castastrophe: might be overkill but maybe useful for others not so familiar with the spec?
17:15:07 <emilio> Rossen9: might be useful
17:15:19 <emilio> PROPOSED: Remove idref feature
17:15:31 <emilio> RESOLVED: Remove idref feature from the spec
17:15:44 <emilio> PROPOSED: Add a note about future named combinators
17:16:20 <kbabbitt> +1
17:16:21 <dbaron> "add a note that we expect to use /-delimited idents or functions for future syntax expansion"
17:16:28 <Rossen9> https://github.com/w3c/csswg-drafts/issues/12451#issuecomment-3377805584
17:16:32 <emilio> RESOLVED: add a note that we expect to use /-delimited idents or functions for future syntax expansion
17:16:57 <emilio> PROPOSED: Add a note about unused ascii punctuation
17:17:31 <emilio> RESOLVED: Add a note about unused ascii punctuation
17:17:40 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/7467
17:17:40 <github-bot> Topic: [selectors-4] additional resource state pseudo-classes for img / picture elements
17:17:40 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7467.
17:18:27 <SebastianZ> https://github.com/w3c/csswg-drafts/issues/7467#issuecomment-1412653946
17:18:28 <emilio> SebastianZ: there was a question about where to add additional resource state pseudo-classes, there was a proposal by crissof (?)
17:18:40 <emilio> ... the proposal is to accept those pseudo-classes
17:18:48 <TabAtkins> q+
17:18:53 <noamr> q+
17:18:53 <emilio> ... I saw noamr had a few remarks
17:18:55 <emilio> ... regarding those
17:19:16 <emilio> ... which is when we introduce them for images in the future we might have issues if we want to extend those for other media types
17:19:17 <emilio> q+
17:19:47 <TabAtkins> ack TabAtkins
17:19:58 <emilio> ... second thing is that non-ok status and broken are different in his opinion
17:19:59 <weinig> q+
17:20:05 <emilio> ... and what about cross-origin and no-cors images
17:20:30 <emilio> noamr: with cross-origin no-cors is that we can't expose whether the image is a 404 or anything else
17:20:37 <emilio> ... we should start with something a bit more conservative
17:20:55 <emilio> ... to just reflect that perfectly aligns with whether the image emitted a load or error event
17:21:11 <emilio> ... so load event means it's complete, error is bad url or network error or ...
17:21:13 <Rossen9> ack noamr
17:21:20 <emilio> ... all kinds of things can cause an error event
17:21:29 <emilio> ... something that reflects those two states would be a good start
17:21:36 <smfr> agree with the more conservative approach first
17:21:37 <emilio> ... and maybe not try to be more detailed than that
17:21:53 <dholbert> emilio: I was going to propose something very similar, start with broken...
17:22:02 <dholbert> emilio: more complicated than load event -- fire a load event, start an image load
17:22:14 <dholbert> emilio: you want to remove the broken state as soon as you fire image load [?]
17:22:19 <SebastianZ> q+
17:22:28 <dholbert> emilio: gecko does have something like this; you need that concept to show alt feedback
17:22:34 <Rossen9> ack emilio
17:22:40 <dholbert> emilio: I think we should match our alt-feedback behavior
17:22:55 <dholbert> emilio: if we would show alt-feedback, the image should match broken
17:22:56 <smfr_> smfr_ has joined #css
17:23:22 <dholbert> emilio: we can expand from that, but there's a lot that's proposed, and I don't think we need all of them. FWIW you mostly need 'broken' (trying to load an image, doesn't load, so you want to show a placeholder or something)
17:23:44 <dholbert> emilio: a lot of the different states you can't really expose. So: I'm ok starting with 'broken'; I don't care about the name
17:23:50 <dholbert> emilio: can improve if more use cases come up
17:23:57 <Rossen9> ack weinig
17:23:57 <emilio> weinig: has any thought been put into how this might be exposed for CSS images?
17:24:23 <emilio> ... long-standing goal of representing <img> as content: url or so
17:24:26 <emilio> ... lots of issues here
17:24:38 <emilio> ... but do we know which parallel states we'd need
17:24:49 <emilio> noamr: css images don't show broken state
17:25:02 <emilio> weinig: sure but still have similar loading states
17:25:06 <emilio> noamr: there's a different issue
17:25:19 <emilio> fantasai: not clear which pseudo-classes are being proposed concretely
17:25:29 <noamr> q+
17:25:33 <emilio> ... agree with emilio and others that we don't want to implement all of them
17:25:49 <emilio> ... whatever names we're going to pick for these is it going to apply to only img or do we need to be more specific?
17:25:54 <emilio> ... or are they generic enough?
17:25:58 <emilio> ack fantasai
17:25:58 <Zakim> fantasai, you wanted to ask which set of pseudos, specifically, we're proposing to add there are lots of lists in this issue
17:26:02 <Rossen9> ack fantasai
17:26:02 <emilio> ack SebastianZ
17:26:10 <emilio> SebastianZ: iterating on which ones can we agree on
17:26:15 <emilio> ... emilio said :broken
17:26:28 <emilio> ... what about :loading and :complete? I think those are the most pressing ones
17:26:37 <emilio> fantasai: I think :complete is too ambiguous
17:26:42 <noamr> q+
17:26:45 <emilio> ... but :loading might make sense?
17:26:46 <emilio> q+
17:27:03 <emilio> fantasai: complete in the context of selectors is very ambiguous
17:27:08 <castastrophe> +1, :loading and :loaded is a nice pairing
17:27:19 <bkardell> :borken
17:27:25 <emilio> noamr: I think if we had broken and either :loaded or :loading the rest can be derived
17:27:36 <Kurt> q+
17:27:45 <Rossen9> ack noamr
17:27:50 <emilio> ... I think there's a strong use case for loading or loaded
17:28:09 <emilio> ... animating when it's already loaded
17:28:11 <flackr> +1
17:28:13 <SebastianZ> q+
17:28:14 <kbabbitt> I like :loading, :loaded, :broken as a starting set
17:28:17 <emilio> ... we could also bikeshed the names later
17:28:36 <dholbert> emilio: one of the issues with :loading and :loaded is...
17:28:49 <dholbert> emilio: when you already have an image, and you trigger a new load, the browser will keep displaying the previous image
17:28:57 <dholbert> emilio: so it's :loading and :loaded at the same time, in a way
17:29:03 <dholbert> emilio:  I could see use-cases where you'd want one or the other
17:29:29 <dholbert> emilio: I'm not opposed... I like :broken because it's corresponds well to an existing state (alt feedback stuff)
17:29:35 <noamr> q+
17:29:51 <Rossen9> ack emilio
17:29:58 <dholbert> emilio: we need to decide how to handle the subtlety around :loading/:loaded in this case though. Various outcomes be unexpected for authors
17:30:01 <dholbert> s/be/might be/
17:30:09 <dholbert> emilio: that's why I like :broken as a start
17:30:20 <emilio> Kurt: wanted to add that there's :-moz-{broken,loading}
17:30:27 <emilio> ... maybe they could be investigated
17:30:29 <Rossen9> ack Kurt
17:30:32 <emilio> ... and standardize those
17:30:33 <emilio> q+
17:30:49 <emilio> ... worth investigating current usage and so on
17:30:56 <dholbert> I don't see `moz-loading` in our source tree at all... https://searchfox.org/firefox-main/search?q=moz-broken&path=&case=false&regexp=false
17:31:11 <dholbert> emilio: we (Gecko) remove those from content so authors cannot use them anymore
17:31:20 <dholbert> emilio: we still have support for -moz-broken, but I removed -moz-loading
17:31:33 <dholbert> emilio: mostly because we didn't have a use-case for the semantics of that pseudo-class
17:31:53 <dholbert> emilio: I guess we could add telemetry to see how often we find -moz-broken in the wild (but it's not-parsing)
17:32:13 <dholbert> emilio: I could tell you the use-cases from inside the Firefox codebase (where it's parsed) if that's useful
17:32:15 <lea> q?
17:32:20 <lea> q+
17:32:24 <Rossen9> ack SebastianZ
17:32:25 <emilio> q-
17:32:38 <emilio> SebastianZ: if we resolved on that would that also cover other media like <audio> and <video>?
17:32:57 <emilio> noamr: I think <audio> and <video> have their own pseudo-classes right?
17:33:08 <emilio> SebastianZ: yeah, :seeking, :buffering, :stalled
17:33:18 <emilio> ... which go into that direction but not completely covering that thing
17:33:32 <emilio> noamr: It's very likely that <video> and <audio> are different
17:33:47 <emilio> ... I think :seeking, :buffering, :stalled make more sense there
17:33:58 <emilio> ... other concepts are a bit different, :broken has the poster image and so on
17:34:04 <Rossen9> ack noamr
17:34:06 <emilio> ... maybe we should define them a bit differently
17:34:25 <emilio> noamr: something that we can come out with is to define :broken and :loading with an open issue for the specific semantics
17:34:29 <Rossen9> ack dbaron
17:35:05 <emilio> dbaron: I was going to say that the thing that lead for the implementation of these was bzbarsky about the default styles for img / object
17:35:10 <emilio> ... possibly plugin and embed
17:35:22 <djmarland> q+
17:35:23 <emilio> ... some of the reason is because the default styles for these things have evolved over time
17:35:31 <emilio> ... object might have evolved over time
17:35:42 <emilio> ... that's my memory of why Gecko found these pseudo-classes
17:35:48 <Rossen9> ack lea
17:36:06 <djmarland> q-
17:36:11 <emilio> lea: sorry if this has been said before, :loading / :loaded doesn't paint a full picture before of lazy loading
17:36:12 <flackr> q+
17:36:23 <castastrophe> :queued ?
17:36:24 <djmarland> The issue suggests :pending
17:36:33 <djmarland> https://github.com/w3c/csswg-drafts/issues/7467#issuecomment-3257156796
17:36:34 <emilio> ... would it be useful to have that state?
17:36:36 <emeyer> q+
17:36:37 <bkardell> why not just style the img element by default?
17:36:42 <keithamus> Presumably `:not(:loading, :loaded)` suffices?
17:36:45 <bkardell> right
17:37:04 <emilio> castastrophe: pending might be more translateable
17:37:12 <emilio> flackr: what would you do in that state? there's no image
17:37:22 <djmarland> :deferred
17:37:25 <emilio> Rossen9: prevent it from loading? that's the only thing I can imagine you can do
17:37:38 <emilio> ... or you can have a different visual for when it's loading or queued or whatever we call it
17:37:48 <lea> keithamus: wouldn't that be `:not(:loading, :loaded, :error)`? I've lost track of what we've resolved around that
17:37:48 <bkardell> I think what keithamus said
17:37:49 <dbaron> there are other possibilities, e.g., loading failed for some reason, loading was blocked for some reason, etc.
17:37:51 <emilio> flackr: but it basically means it's off-screen right?
17:37:52 <Rossen9> ack flackr
17:38:21 <emilio> flackr: there might be a difference between having nothing to render and the low-res version of a progressive image?
17:38:28 <lea> q?
17:38:32 <lea> q+
17:38:34 <Rossen9> ack emilio
17:38:38 <emilio> ... maybe we don't need to distinguish that just yet but it might be useful to fade a placeholder color into the image
17:38:38 <Rossen9> ack emeyer
17:38:48 <emilio> emeyer: was going to say something similar to what flackr said
17:38:50 <castastrophe> Should we go back to the issue with this additional discussion and gather use-cases?
17:39:00 <fantasai> +1 castastrophe
17:39:02 <kbabbitt> +1 castastrophe
17:39:04 <emilio> ... I can imagine authors doing simple style for an image that is neither loading nor loaded
17:39:15 <emilio> ... whatever we call it
17:39:19 <lea> +1 castastrophe
17:39:21 <emilio> ... this might be doable with a `:not()`
17:39:35 <emilio> ... since these are inexactly defined that there would be states that an image could have that would be neither
17:39:52 <emilio> ... maybe with clear definitions we could resolve that concern
17:39:55 <castastrophe> I would find it helpful in the issue to put together a table of the proposed states and when an image would meet those requirements
17:39:55 <Rossen9> ack lea
17:39:56 <emilio> ack lea
17:40:04 <dbaron> +1, this stuff is complicated so we shouldn't expect authors to write the correct complicated expression...
17:40:06 <emilio> lea: apparently UAs still support lowsrc
17:40:13 <castastrophe> To give authors a prompt to provide use-cases
17:40:14 <emilio> ... so we should probably define how that works
17:40:24 <SebastianZ> castastrophe I'd like to resolve on the ones that we agree on, at least.
17:40:28 <keithamus> q+
17:40:33 <emilio> ... there might be consensus on going back to the issue and collect use cases
17:40:44 <Rossen9> ack keithamus
17:40:46 <castastrophe> yeah +1, not opposed to a resolution
17:40:47 <emilio> ... even if we take some of it back to the issue there might be consensus on `:broken` or so?
17:41:12 <emilio> keithamus: For :loading placeholder content and transitions feel like the big use case for those?
17:41:14 <lea> It seems we'd have consensus between a state for "has successfully loaded" and "is broken"
17:41:17 <castastrophe> +1, I would support resolving on :broken at least
17:41:18 <emilio> ... not sure if you want more concrete use cases
17:41:21 <djmarland> q+
17:41:40 <dholbert> emilio: similar for :broken, showing a placeholder or something when the image has failed to load is the same kind of use case
17:42:09 <lea> we do want to be able to target succesful loading too, e.g. to not apply placeholder backgrounds
17:42:15 <dholbert> keithamus: you might want to do that on an ancestor, too (collapsing borders, etc. on a container element)
17:42:17 <emilio> keithamus: Yeah if you have a broken image hiding some of the card borders or so
17:42:31 <emilio> djmarland: :not() can get complicated with :has()
17:42:46 <Rossen9> ack djmarland
17:42:57 <dholbert> emilio: why?  you'd need to type 'img' directly, but that's not too bad
17:43:13 <emilio> djmarland: Yeah maybe you can, but feels a bit more complicated
17:43:23 <emilio> ... would be simpler with a more obvious selector
17:43:24 <castastrophe> I could see reflowing :has(img:not(:loaded))
17:43:25 <flackr> Something like :has(img:not(:loaded)) ?
17:43:57 <lea> +1
17:43:58 <emilio> noamr: let's resolve on having :broken and :loaded with details of how :loaded works tbd
17:44:27 <emilio> PROPOSED: resolve :broken (with alt fallback semantics) and :loaded (with semantics tbd)
17:44:49 <flackr> +1
17:44:51 <lea> +1
17:44:53 <SebastianZ> +1
17:44:55 <smfr> +1
17:45:30 <dholbert> emilio: not an objection, but I wonder about :loaded vs :loading... Depending on how we define it, there might be interesting interactions with :broken
17:45:58 <flackr> I think :loaded will be easier to precisely define than :loading where things like progressive loading
17:45:58 <antonp> antonp has joined #css
17:46:11 <dholbert> emilio: maybe resolve on :loading and :loaded simultaneously?
17:46:18 <fantasai> Is a broken image :loaded?
17:46:38 <castastrophe> What if just resolve on :broken for now?
17:46:43 <castastrophe> It seems to have more consensus
17:46:45 <emilio> dholbert: not objecting, but :loaded without semantics seems weird to add, for the replaced image case
17:47:04 <emilio> ... I guess I don't see a lot of value on adding :loaded without knowing what the semantics are going to be
17:47:10 <flackr> qq+
17:47:25 <emilio> ... maybe we should resolve on :broken + exploring :load*
17:48:02 <emilio> PROPOSED: Resolve on :broken (with alt fallback semantics) and make progress on defining :loaded or :loading
17:48:06 <Rossen9> ack flackr
17:48:06 <Zakim> flackr, you wanted to react to djmarland
17:48:39 <emilio> flackr: was going to propose that :loaded is "there's no loading going on"
17:48:43 <emilio> q+
17:48:55 <emilio> dholbert: I think that might not be the state we want to target
17:49:03 <noamr> :broken is already good progress, I'm fine with that
17:49:14 <emilio> flackr: fine to defer if contentious
17:49:34 <emilio> RESOLVED: Add :broken (with alt fallback semantics) and make progress on defining :loaded or :loading
17:49:56 <noamr> +1
17:49:56 <dholbert> emilio: we may want to explore :loaded and :loading in terms of HTML img element states
17:50:06 <dholbert> emilio: e.g. img has .complete() which maybe would correspond to :loaded state
17:50:11 <dholbert> emilio: though that may not be what we want
17:50:22 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/12659
17:50:22 <lea> Might also be useful to consider potential expansion to other elements loading embedded content (e.g. video, audio, iframe etc)
17:50:22 <github-bot> Topic: [css-overflow-5] `:target-current` pseudo class should also imply `aria-current=true` on an active scroll marker
17:50:22 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12659.
17:50:51 <sakhapov> sakhapov
17:51:25 <emilio> sakhapov: We have a bunch of links and we can ask the browser to mark the link which has the link whose target is in view
17:51:36 <emilio> ... for a11y we should mark it as `aria-current=true`
17:51:38 <bkardell> q+
17:51:43 <emilio> ... we should add that to the spec
17:51:43 <flackr> q+
17:51:43 <emilio> q-
17:51:48 <Rossen9> ack bkardell
17:52:07 <lea> q?
17:52:08 <emilio> bkardell: you're not suggesting that we should actually set an attribute right? Just the a11y state?
17:52:10 <lea> q+
17:52:14 <emilio> sakhapov: yeah, I guess
17:52:22 <Rossen9> ack flackr
17:52:26 <emilio> flackr: that's what I was on the queue to talk about
17:52:47 <emilio> ... correct, that implies an aria-current state if there's no explicit one for the element
17:53:00 <emilio> bkardell: doesn't that belong to a11y mappings?
17:53:18 <emilio> sakhapov: you're probably right should I ask the a11y wg?
17:53:21 <lea> q?
17:53:28 <emilio> bkardell: I think it should go there
17:53:29 <emilio> q+
17:53:54 <emilio> bkardell: dunno if it goes in html accessibility mappings, not sure if we have a css one
17:54:16 <Rossen9> ack lea
17:54:20 <PaulG> q+
17:54:27 <emilio> lea: +1 to solving this but not quite sure what it's being proposed, so it's not a property
17:54:35 <emilio> ... :target-current is a property
17:54:46 <emilio> s/a property/a pseudo-class/
17:54:58 <emilio> ... so when is this applied, when somebody uses the pseudo-class?
17:54:59 <flackr> qq+
17:55:17 <emilio> ... it'd be easier to have a property
17:55:30 <emilio> flackr: this has nothing to do with whether or not :target-current pseudo-class
17:55:42 <Rossen9> ack flackr
17:55:42 <Zakim> flackr, you wanted to react to lea
17:55:50 <emilio> ... we've resolved that when you use scroll-target-group we select one link as :target-current
17:56:00 <emilio> ... so not affected by usage of the pseudo-class
17:56:12 <emilio> lea: maybe I got confused by the wording of the issue
17:56:23 <castastrophe> castastrophe has joined #css
17:56:36 <dholbert> emilio: it seems like this is the right thing to do. if it has to go into a CSS spec, we should resolve on it
17:57:00 <dholbert> emilio: lea, maybe a better way to frame it -- if you want to express in terms of css properties, you could think of UA stylesheet having :current { internal-property: state}
17:57:04 <Rossen9> ack emilio
17:57:07 <Rossen9> ack PaulG
17:57:16 <bkardell> https://w3c.github.io/css-aam/
17:57:39 <bkardell> https://w3c.github.io/html-aam/
17:57:57 <emilio> PaulG: I believe ??s comments are correct the APA have discussed this and we're going to talk about this at tpac but this should be in HTML probably
17:58:15 <bkardell> s/??s/Sara's
17:58:17 <emilio> sakhapov: so css triggers this behavior but then triggers this pseudo-class
17:58:25 <emilio> ... so it's mostly HTML accessibility
17:58:47 <emilio> sakhapov: so first of all I should find out where we should put this in
17:59:06 <emilio> ... if it's CSS we should resolve on adding aria-current for scroll-target-group
17:59:09 <emilio> ... the issue was also flagged for tpac
17:59:28 <emilio> Rossen9: do we have time scheduled with APA at tpac? We should probably discuss it here
17:59:45 <emilio> bkardell: does it make sense to open an issue in the html-aam repo?
17:59:50 <emilio> Rossen9: yes absolutely
18:00:18 <emilio> topic: end
18:00:21 <fantasai> Register! https://wiki.csswg.org/planning/tpac-2025
18:00:28 <Rossen9> Zakim end meeting
18:00:35 <Rossen9> Zakim,  end meeting
18:00:35 <Zakim> As of this point the attendees have been emeyer, Rossen, jfkthame, flackr, PaulG, bkardell, miriam
18:00:37 <Zakim> RRSAgent, please draft minutes v2
18:00:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/05-css-minutes.html Zakim
18:00:45 <Zakim> I am happy to have been of service, Rossen9; please remember to excuse RRSAgent.  Goodbye
18:00:45 <Zakim> Zakim has left #css
18:31:08 <antonp> antonp has joined #css