01:54:17 <Linux_Kerio> Linux_Kerio has joined #css
02:40:41 <Linux_Kerio> Linux_Kerio has joined #css
04:57:36 <antonp> antonp has joined #css
05:33:43 <antonp> antonp has joined #css
06:44:43 <antonp> antonp has joined #css
14:59:41 <RRSAgent> RRSAgent has joined #css
14:59:41 <RRSAgent> logging to https://www.w3.org/2025/05/15-css-irc
14:59:44 <Zakim> RRSAgent, make logs Public
14:59:45 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:00:00 <jarhar> jarhar has joined #css
15:00:24 <astearns> astearns has changed the topic to: stylable form controls agenda: https://github.com/whatwg/html/issues/11242
15:01:51 <flackr> flackr has joined #css
15:01:54 <masonf> masonf has joined #css
15:03:09 <cwilso> present+
15:03:16 <flackr> present+
15:03:18 <dandclark> present+
15:03:34 <annevk> annevk has joined #css
15:03:39 <kurt> kurt has joined #css
15:03:41 <dandclark> scribe: dandclark
15:04:05 <astearns> github-bot, take up https://github.com/whatwg/html/issues/11019
15:04:05 <github-bot> Topic: Support fragment references in the `<link>` tag's `href` attribute
15:04:05 <github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/11019.
15:04:15 <kurt> present+
15:04:30 <ntim> ntim has joined #css
15:04:36 <dandclark> kurt: Working on getting this to stage 2 in whatwg.
15:04:53 <dandclark> ...want to get some of the concerns worked out in joint call
15:05:05 <astearns> related: https://github.com/whatwg/html/issues/11286
15:05:06 <dandclark> ...Noam filed https://github.com/whatwg/html/issues/11286
15:05:20 <dandclark> ...seems like the biggest blocking issue. Seems to have been resolved in thread
15:05:24 <emilio> present+
15:05:24 <dandclark> ...spec already covers it
15:05:33 <dandclark> ...are there other concerns?
15:05:34 <dandclark> ...before stage 2?
15:05:45 <dandclark> annevk: Not sure it's resolved. Haven't seen Olli reply
15:06:08 <dandclark> ...I think Domenic thinks current situation is OK. Would be good to discuss with him
15:06:12 <dandclark> ...maybe Noam too
15:06:41 <dandclark> kurt: Makes sense to set up one-off session with them?
15:07:00 <dandclark> annevk: Yes, also good to have Tab, he created the local references thing
15:07:14 <dandclark> ...Treating URL starting with `#` differently
15:07:34 <dandclark> ...Doesn't have the issue of re-fetching the same document
15:07:42 <dandclark> ...Not sure it's actually implemented for CSS
15:07:47 <dandclark> ...seems like a useful thing
15:08:13 <dandclark> ...It's more intentonal. Very clear that it will always be treated as local reference, not affected by stuff like `<base>`
15:08:34 <dandclark> emilio: Gecko imlements local reference concept. I assume other engines do so in a more or less semi-consistent way
15:08:42 <dandclark> ...need to handle that kind of stuff for SVG
15:08:55 <dandclark> annevk: Do you end up fetching even if URL matches but doesn't start with fragment ID?
15:09:01 <dandclark> emilio: Need to double-check that.
15:09:07 <dandclark> annevk: I can make test case
15:09:16 <dandclark> emilio: Should be easy to test
15:09:42 <dandclark> astearns: Having specific session on this with the right people sounds good
15:09:46 <dandclark> kurt: I can set up
15:10:13 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2777119047
15:10:13 <github-bot> Topic: [css-ui] Support setting offscreen content inert
15:10:13 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10711.
15:10:45 <dandclark> masonf: There is an HTML spec PR for this
15:11:00 <dandclark> ...It's connecting to CSS concept of interactivity. There have been changes. Part of what's in PR will change
15:11:17 <RobAtADP> RobAtADP has joined #css
15:11:35 <dandclark> ...it keeps existing behavior for modal dialogs. It allows interactivity keyword in CSS to cause intertness. It explains the existing inter attr in terms of that property
15:11:40 <dandclark> ...allows to you de-inert things.
15:11:54 <dandclark> ...Can exempt subtree to be un-intert. that's expected to change
15:12:00 <jBreiland> jBreiland has joined #css
15:12:17 <dandclark> flackr: We're proposing to discuss not de-inerting anymore. Have the interactivity prop be synonomous with the HTML prop
15:12:35 <dandclark> ...can't escape inertness aside from preexisting dialog semantics (which is internal magic)
15:12:46 <dandclark> flackr: It becomes non-inherited property.
15:13:11 <dandclark> ...The way you determine inertness is once you see inert at any point in tree, applies to all descendants, just like inert attribute
15:13:21 <dandclark> annevk: Why do we need interactivity property?
15:13:33 <dandclark> flackr: So it can be applied dynamically by CSS. Lots of cases where it's useful
15:13:57 <jarhar> dandclark: do we still have a11y folks involed in this conversation?
15:14:05 <jarhar> dandclark: theyre interested in this conversation, i hope theyre still involved
15:14:12 <dandclark> flackr: This has been ongoing discussion
15:14:17 <dandclark> ...you can see in various issues
15:14:37 <dandclark> ...change to interactivity is part of attempt, if we allign with HTML intert prop, it has the same implications as we already have for that
15:14:47 <dandclark> ...nice cleanup, it explains HTML prop like display:none explains hidden property
15:14:53 <dandclark> masonf: This change is a result of those convos
15:15:21 <dandclark> astearns: This seems like a necessary change, but not sure it's suffiient to address all concerns from a11y folks
15:15:27 <dandclark> flackr: Synonymouse with HTML inert
15:15:50 <emilio> q+
15:16:04 <dandclark> ...can argue it can be used more broadly now. But seems prescriptive to tell authors they can't do this with CSS when they can with HTML
15:16:14 <dandclark> astearns: Requires AT to update that it's not just HTML
15:16:19 <dandclark> flackr: This is just a browser thing
15:16:29 <dandclark> masonf: Right, should be exposed to AT in the same way
15:16:41 <astearns> ack emilio
15:17:21 <dandclark> emilio: As part of this work are you chaning HTML inert from being magic to be mapped to CSS prop
15:17:40 <dandclark> masonf: Answer is yes. There is still magic because dialogs get to de-inert things magically
15:17:51 <dandclark> annevk: Will CSS define all the inert logic? Moving that from HTML?
15:17:57 <dandclark> masonf: No, defined in both places
15:18:02 <dandclark> annevk: Hows' that make sense
15:18:13 <dandclark> masonf: HTML spec PR refers to both CSS and HTMl concept of inert
15:18:19 <dandclark> annevk: That' snot what you said before
15:18:37 <dandclark> masonf: You said the concept of ineert, which is defined in both places
15:18:49 <dandclark> masonf: Both mechanisms apply concept of inertnesss to tree
15:19:07 <dandclark> ntim: I think anne is referring to conecept of inertness, not the attribute. Why not move the whole def to CSS?
15:19:10 <dandclark> flackr: It's editorial
15:19:16 <dandclark> ...can define in CSS if that makes more sense
15:19:30 <dandclark> masonf: It's already defined in CSS, but yes let's get the language right, any of these are fine
15:19:55 <masonf> CSS concept: https://drafts.csswg.org/css-ui-4/#inert
15:20:02 <dandclark> annevk: I'm not sure it's editorial. If we move these concepts, we'll have to change a bunch of thigns
15:20:23 <dandclark> ...Then css has to be in charge of interactivity, whether nodes are interactive
15:20:34 <dandclark> masonf: I think it does, pasted link above^
15:20:44 <dandclark> annevk: Identically to what we have in HTML?
15:20:49 <dandclark> masonf: HTML links to that definition
15:21:14 <dandclark> masonf: The behaviors come from CSS
15:21:32 <dandclark> annevk: It's not just editorial. Are the behaviors identical?
15:21:42 <dandclark> masonf: My PR removes some of these defs and refers to CSS
15:21:49 <dandclark> annevk: But not removing the entire concept
15:22:08 <dandclark> annevk: Concept could live in CSS, if identical
15:22:11 <dandclark> masonf: I agree
15:22:38 <dandclark> astearns: Makes sense to ensure we are defining something identical. But editorial in that it's something we need to work through once we decide the design we've got is what we want to move forward with with.
15:22:57 <dandclark> ...whether we have interactivity prop is the more fundamental question, not sure we're there yet
15:23:12 <dandclark> ...Hope this change will address the a11y concerns but need to ensure that's the case
15:23:29 <dandclark> ...We don't yet have resolution to make interactivity not inherit. Can we resolve?
15:23:44 <dandclark> s/Synonymouse/synonymous
15:24:06 <dandclark> emilio: Can we resolve in this meeting?
15:24:10 <dandclark> astearns: Yes, it's joint meeting
15:24:34 <dandclark> annevk: Assumption is that the a11y people not in room agree with this
15:24:45 <dandclark> flackr: It's one of the things that have been identified, is a move in the right direction
15:25:02 <dandclark> ...remaining concern is whether you should be able to set inertness from CSS at all
15:25:07 <dandclark> annevk: Yes that seems separate
15:25:11 <dandclark> astearns: But very relevant
15:25:19 <dandclark> flackr: But you can, with visibility: hidden
15:25:31 <dandclark> Proposed resolution: Make interactivity not inherit.
15:25:35 <annevk> annevk has joined #css
15:25:47 <RRSAgent> I'm logging.  Sorry, nothing found for 'link'
15:25:52 <RRSAgent> I'm logging.  Sorry, nothing found for 'logs'
15:26:06 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/15-css-minutes.html annevk
15:26:13 <dandclark> <wordsmithing resolution>
15:26:46 <dandclark> Proposed resolution: Interactivity does not inherit, and setting it on something that's inert does not change the intertness
15:26:47 <masonf> +1
15:26:57 <flackr> +1
15:27:03 <dandclark> RESOLVED: Interactivity does not inherit, and setting it on something that's inert does not change the intertness
15:27:07 <ntim> s/intert/inert :)
15:27:42 <dandclark> astearns: I know this CSS prop is important to carousel set of proposals. What happens if there  isn't interactivity property?
15:27:59 <dandclark> flackr: For a bunch of use cases they'll have to add prop via JS
15:28:16 <dandclark> vmpstr: Or they'll add visibility but that limits the effects you can have
15:28:22 <dandclark> flackr: Visually changes the things that are not current
15:28:42 <dandclark> ...When scrolling, you would see the new contents pop into visibility as it becomes active
15:28:55 <dandclark> ...In many use cases you can peek at next content
15:29:02 <dandclark> ...Interactivity prop supports this
15:29:07 <dandclark> astearns: Can't do this another way?
15:29:09 <dandclark> flackr: Right
15:29:21 <dandclark> astearns: Other questions or comments?
15:29:27 <dandclark> ...before we take it back to issue
15:29:42 <dandclark> masonf: I will update to incorporate the resolution, would like review after that
15:29:54 <dandclark> astearns: And you'll remove special casing for setting things uninert?
15:29:56 <dandclark> masonf: Right
15:30:37 <jarhar> https://github.com/whatwg/html/issues/8189#issuecomment-2877242732
15:30:44 <astearns> github-bot, take up https://github.com/whatwg/html/issues/8189#issuecomment-2877242732
15:30:44 <github-bot> Topic: Rendering <select> as a listbox is a one-line widget that opens a popup on iOS and Android
15:30:44 <github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/8189.
15:30:58 <kurt> kurt has joined #css
15:31:17 <dandclark> jarhar: This is about how select element with multiple is rendered as button with popup on mobile, and in-page listbox on desktop
15:31:29 <dandclark> ...can't opt into one oth or the other, even with `size` attr
15:31:35 <dandclark> ...HTML spec doesn't explain this
15:31:39 <dandclark> ...I want to improve this
15:31:54 <dandclark> ...Have goals mentioned in comment. Previously talked about adding new attr to do this.
15:32:03 <dandclark> ...annevk recommended against, so want to use the size attr
15:32:10 <dandclark> ...Have goal of feature parity across platforms
15:32:24 <dandclark> ...Same HTML create same UI across platforms
15:32:46 <dandclark> ...Believe in-page rendering on desktop is more highly used, have use counter to verity
15:33:05 <dandclark> ...Setting size=1 to opt into button with popup rendering, size > 1 opts into listbox rendering
15:33:11 <dandclark> ...Thoughts?
15:33:18 <dandclark> astearns: Concern is web compat
15:33:21 <emilio> q+
15:33:28 <dandclark> ...Seems risky. Glad you have use counter
15:33:42 <dandclark> jarhar: Yep don't want to break the web, can change course if needed.
15:34:02 <astearns> ack emilio
15:34:03 <dandclark> masonf: Nice thing here is that existing thing for size>1 is bad, so hopefully low usage
15:34:17 <dandclark> emilio: Does this change the dfault for multiple on mobile?
15:34:22 <dandclark> jarhar: That's what i'm proposing
15:34:26 <dandclark> emilio: That's the scary part.
15:34:47 <dandclark> ...Does this involve impementing size > 1 with multiple on desktop?
15:34:52 <dandclark> jarhar: That's one of my goals
15:35:03 <dandclark> emilio: I think end goal is nice. Scared about webcompat. But worth a shot
15:35:04 <masonf> s/size > 1/size = 1
15:35:04 <jarhar> q?
15:35:13 <dandclark> ...Other interesting thing is how will that work on desktop
15:35:22 <dandclark> ...Not a lot of examples for muti-select
15:35:26 <dandclark> ...Needs specifying
15:35:35 <dandclark> ...whether you expect it to close
15:35:53 <dandclark> ...Do you expect seleding a new option to require reopening the popup
15:35:57 <jarhar> https://github.com/openui/open-ui/issues/1217
15:36:00 <dandclark> ...Could be either useful or annoying
15:36:06 <dandclark> jarhar: Linked issue is about this
15:36:16 <dandclark> ...seen sites where there's no extra button to commit or cancel
15:36:39 <dandclark> ...iOS one has close button but not an OK or cancel thing, so as soon as you select the options in native picker you can see the in-page button change
15:36:49 <dandclark> ...pressing option doesn't close picker
15:37:03 <dandclark> ...On android, there's both OK and Cancel buttons, doesn't commit selection until you press button
15:37:15 <dandclark> ...Hoping to at least make base:appearance one consistent.
15:37:24 <dandclark> ...Don't necessarily have to change native
15:37:31 <dandclark> emilio: Tricky part on desktop is that both use cases make sense
15:37:45 <dandclark> ...say you have list of langs, want to select 2 or 3, don't want to have to reopen popup
15:38:17 <dandclark> ...But for sorting option, most of the time you only want one but can select multiple. Good you are thinking about this. End goal makes sense, compat wise might be annoying but we'll see
15:38:30 <RobAtADP> what would the in page widget show after closing with multiple options selected?
15:38:45 <dandclark> jarhar: If compat doesn't work out, might be different without size attr, will  have to give guidance that that be used
15:39:41 <dandclark> astearns: Maybe this is something that gets gated on appearance: base if we have compat concerns?
15:40:01 <dandclark> jarhar: Using CSS to switch modes would be challenging
15:40:24 <dandclark> ...Thought we couldn't do it with in-page CSS. But the way it works now with button vs popup mode is it changes UA shadow root and slotting behavior
15:40:33 <dandclark> ...chaning that on computed val of CSS prop would be not good
15:40:52 <dandclark> ...Did a lot of work to have custom select slotting not to depend on this, would be more work for this new case
15:41:05 <dandclark> ntim: More fundamentally, making behavior changes based on appearance:base is something to avoid
15:41:38 <dandclark> ...Appearance should be for stylistic rather than behavior changes IMO. it's confusing for devs otherwise
15:41:51 <dandclark> annevk: Tend to agree, but this is edge case.
15:42:00 <dandclark> ...Isn't shadow different between auto and base already?
15:42:06 <dandclark> jarhar: Carefully designed so it doesn't change
15:42:39 <dandclark> astearns: Thought there were cases where appearance:base defined that shadow composition of a control, where it would not have been defined before
15:42:52 <dandclark> annevk: But that doesn't make it depend on computed style, could have same shadow for both
15:43:19 <dandclark> ntim: The current cases in css forms spec where we say elements work with appearance:base, it doesn't change behavior. Sliders are still sliders.
15:43:29 <dandclark> ...It's just what's exposed to styling that changes.
15:44:01 <dandclark> ...Anyway seems there's more consensus around making HTML attribute the opt-in. So not sure we have to consider appearance.
15:44:12 <dandclark> astearns: Other comments/questions?
15:44:26 <dandclark> ...Do you want resolution today?
15:44:38 <dandclark> jarhar: No. Discussion more than enough
15:45:03 <dandclark> annevk: Don't think I ever said I don't want a new attribute. Just that we should try to understand existing behavior.
15:45:13 <dandclark> ...Not sure we do, but maybe still OK with changing if it's compatible
15:45:22 <dandclark> astearns: Don't object to new attr?
15:45:28 <dandclark> annevk: Not necessarily, it depends
15:45:53 <dandclark> astearns: Also makes sense even if web compatible to consider this switch on the attr vs a design that has a new attr that was more specifically targeted to this problem
15:46:03 <dandclark> ...What would make more sense for devs?
15:46:28 <dandclark> ntim: If new attr is added, shouldn't just be for the sake of compat. Shouldn't be the only reason to add new attr.
15:46:51 <dandclark> ...Would make more sense to add new attribute if it's well tailored for a certain use case
15:47:08 <dandclark> masonf: I think if this were redesigned today the attribute would be popup vs in page.
15:47:13 <dandclark> ...That would be more semantic
15:47:29 <dandclark> annevk: makes sense, but you still have to figure out CSS, probably in CSS
15:47:48 <dandclark> jarhar: Promising how tall the thing will be in appearance:base world might be hard or impossible
15:47:56 <dandclark> annevk: Yeah probably wont' work
15:48:05 <dandclark> ...but in apperance:base world, size thing is exposed to CSS
15:48:13 <dandclark> ...Can do `calc` magic and make it work
15:48:20 <dandclark> ...Sounds reasonable that it can work
15:48:41 <dandclark> astearns: Seems like a non goal to preserve the existing behavior and then add extra way of getting consistent rendering
15:48:50 <dandclark> ...Like the idea of having consistent rendering to fix this
15:48:53 <dandclark> annevk: yes
15:49:13 <dandclark> astearns: Yes, too many modes.
15:49:23 <dandclark> ...Will wait for use counter results then come back to discuss
15:49:42 <astearns> topic: end
15:49:49 <astearns> zakim, end meeting
15:49:49 <Zakim> As of this point the attendees have been cwilso, flackr, dandclark, kurt, keithamus, emilio
15:49:51 <Zakim> RRSAgent, please draft minutes v2
15:49:52 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/15-css-minutes.html Zakim
15:49:58 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
15:49:58 <astearns> topic: none
15:49:59 <Zakim> Zakim has left #css
15:59:28 <antonp> antonp has joined #css
16:51:49 <jamesn> jamesn has joined #css
16:56:16 <Adam_Page> Adam_Page has joined #css
17:03:47 <Francis_Storr> Francis_Storr has joined #css
18:01:08 <bkardell> bkardell has joined #css
18:03:53 <Penny> Penny has joined #css
18:09:26 <Linux_Kerio> Linux_Kerio has joined #css
20:02:03 <antonp> antonp has joined #css