15:01:57 <RRSAgent> RRSAgent has joined #css
15:02:01 <RRSAgent> logging to https://www.w3.org/2025/05/29-css-irc
15:02:01 <Zakim> RRSAgent, make logs Public
15:02:02 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:02:08 <astearns> astearns has changed the topic to: form controls agenda: https://github.com/whatwg/html/issues/11311
15:02:51 <dbaron> Present+
15:02:52 <masonf> masonf has joined #css
15:02:56 <masonf> present+
15:03:20 <astearns> github-bot, take up https://github.com/whatwg/html/issues/11130
15:03:20 <github-bot> Topic: File upload control rendering should specify the button element to use.
15:03:20 <github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/11130.
15:03:29 <masonf> scribenick: masonf
15:03:33 <bkardell> bkardell has joined #css
15:04:04 <masonf> lwarlow: file input button is spec'd as an element-backed pseudo element, but no browsers do that yet
15:04:39 <masonf> lwarlow: if we make it an element backed, there is an interop problem. Some pseudos work differently across browsers.
15:04:50 <flackr> present+
15:05:09 <dbaron> lwarlow: (because some browsers make it a <button> and some make in an <input type=button>)
15:05:10 <masonf> lwarlow: valid questions about whether we should be too prescriptive for appearance:auto, might want consistency among pseudos for form controls.
15:05:45 <masonf> lwarlow: I think it should be element-backed. If you want a dictionary definition, it's the "button" in the file input. Want to discuss. Developers would benefit.
15:06:05 <masonf> astearns: can I hear more about why we want consistency across pseudos? There are a ton of them.
15:06:19 <masonf> anne: just across form controls
15:06:36 <masonf> anne: just to help developers keep things straight for form controls.
15:06:49 <masonf> anne: how do input type button and <button> differ?
15:07:09 <masonf> lwarlow: for input type=button, you can't use ::before and ::after, whereas for <button> you can
15:07:29 <masonf> lwarlow: other stuff, like first-letter and first-line
15:07:37 <masonf> lwarlow: input is replaced and button isn't, but just a guess
15:07:49 <masonf> anne: I wonder how well that's defined. Part of form control styling being a mess.
15:08:09 <masonf> dbaron: lot isn't defined. But before and after might make sense - one renders its content and the other doesn't. before and after create additional contents.
15:08:20 <masonf> astearns: inputs don't render contents?
15:08:32 <masonf> dbaron: yeah, renders value attribute rather than its children.
15:08:53 <masonf> anne: if you implemented input type button with shadow tree, it'd work that way
15:09:07 <masonf> dbaron: might be something we can't change at this point
15:09:12 <masonf> anne: agree, compat might be tough
15:09:21 <jarhar> this is where we disallow ::before and ::after on <input type=button>: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/generated_children.h;l=22;drc=4d079b53ac180ffe553e5980b104924248776b98
15:09:31 <masonf> dbaron: general feeling that this is a hard case. We might want to think about "hard cases make bad law" dictum.
15:09:40 <lwarlow> q+
15:09:44 <masonf> dbaron: this is an unusual case
15:09:50 <astearns> ack lwarlow
15:10:38 <masonf> lwarlow: two points. One: input type button is unfortunate, and shouldn't exist. If we can make them behave more like real buttons, great. Spec has precedent for adding things to buttons and not input buttons.
15:10:58 <masonf> lwarlow: in that case, it seems obvious in this case, just make file inputs use a real button.
15:11:06 <jarhar> +1
15:11:31 <masonf> lwarlow: Two: wanting to be consistent across form controls, I agree with that. When trying to make everything stylable, we should make them all element-backed as much as possible.
15:11:58 <masonf> lwarlow: most of the pseudo elements (with few exceptions) would be separate elements. E.g. range element's thumb should be element-backed.
15:12:01 <masonf> +1 to this (from the scribe)
15:12:27 <masonf> lwarlow: maybe some shouldn't be real elements, but I can't find good examples. Most seem like they should be real elements.
15:12:43 <masonf> lwarlow: so I agree, but my conclusion is that file input should be a real button.
15:13:07 <masonf> lwarlow: one bit is that this pseudo exists for appearance:auto, but let's not use that as a reason to block the rest.
15:13:08 <keithamus> q+
15:13:20 <masonf> lwarlow: also because most browsers already agree.
15:13:33 <astearns> ack keithamus
15:13:52 <masonf> keithamus: have we concluded that all of them can't be element backed? This one (input type button) has issues, but I haven't heard that we can't do this across the board.
15:14:03 <masonf> lwarlow: we have to decide on what the element is for file input.
15:14:25 <masonf> lwarlow: maybe make this a special case to allow the rest to be real buttons and element-backed pseudos.
15:14:32 <fantasai> Making ::file-selector-button a special case makes sense given the security implications
15:14:49 <masonf> lwarlow: easier to not make it element backed. I think you can do it consistently with element backed, and that'd be worth the effort.
15:15:15 <masonf> lwarlow: not good that developers need to remember more stuff. But artificially limiting capabilities just because of that purity isn't right.
15:15:24 <masonf> anne: it gives browsers more freedom on how to implement things.
15:15:30 <fantasai> +1 anne
15:15:42 <masonf> anne: would prefer smaller incremental steps.
15:15:52 <masonf> anne: initial step is slightly less capable elements
15:16:18 <masonf> dbaron: question of file button - this is a small constraint on the potential for appearance:auto, compared to "there's a button there".
15:16:34 <masonf> dbaron: if we're adding a pseudo, saying it's element backed and a real button, that's not a big deal
15:16:45 <masonf> anne: if you only consider that pseudo, yeah. But I Want to think about all of them.
15:17:04 <masonf> dbaron: one question: are there others in the same situation, in that they're there in appearance:auto?
15:17:37 <masonf> anne: choice of backing elements is relevant. We've talked about this for <select>. Exact element to pick mattered, e.g. <dialog> :modal pseudo class matching.
15:17:55 <astearns> q+
15:17:59 <masonf> anne: I'd rather take it slowly
15:18:09 <astearns> ack fantasai
15:18:25 <masonf> fantasai: I agree with Anne that we should go slowly on these. We might learn things as we implement things.
15:18:50 <masonf> fantasai: one question that came up was performance implications for a shadow tree for every single thing on the page.
15:19:13 <masonf> fantasai: let's try to implement and see what needs a shadow tree, and what are the other constraints
15:19:19 <fantasai> s/thing/checkbox/
15:19:32 <masonf> thank you - I heard "chat boxes" and figured that was wrong
15:19:39 <fantasai> :D
15:19:56 <masonf> astearns: if we go slow and find that it does make sense to add capabilities later, what's the progressive enhancement story? How to detect?
15:20:02 <masonf> anne: isn't there an @supports thing?
15:20:17 <masonf> lwarlow: file selector button with ::before pseudo element in @supports
15:20:43 <masonf> fantasai: let's be conservative for now, and based on experience we can expand
15:20:56 <masonf> fantasai: we can always make things element backed, rather than going the other direction
15:21:09 <fantasai> s/we can always/it is easier to/
15:21:24 <masonf> astearns: so we keep being vague about how it's implemented. And for now the pseudo isn't element-backed. Right?
15:21:29 <masonf> lwarlow: status quo
15:21:50 <masonf> dbaron: I'm still inclined in this case to make it element backed.
15:22:18 <masonf> astearns: repercussions are small in that case?
15:22:25 <masonf> dbaron: we should make it element backed and make it button
15:22:44 <masonf> anne: and you don't care about consistency?
15:22:48 <masonf> dbaron: which other?
15:22:55 <masonf> anne: placeholder, checkmark, long list
15:22:59 <masonf> anne: clear icon
15:23:29 <masonf> dbaron: some of those are pretty different. Maybe file selector button is pushing toward an edge case. Some of those are leaf-like, and less pushing towards element backed.
15:23:42 <astearns> all of the other pseudos in the current draft are not element backed
15:23:45 <masonf> dbaron: file selector button is kind of not leaf-like but barely
15:24:07 <astearns> ack astearns
15:24:09 <masonf> keithamus: if you use CSS to style an input button, making it a button allows ::before/after, and icons are common, so those are useful.
15:24:32 <masonf> anne: in theory you can use content property
15:24:45 <masonf> keithamus: no text though
15:24:53 <masonf> anne: in theory it's supposed to be multiple things
15:25:00 <masonf> dbaron: in practice it's not
15:25:14 <masonf> dbaron: it's possible that's the thing that goes away if you make it element backed, depending on definition.
15:25:15 <astearns> ack fantasai
15:25:23 <keithamus>  /keithamus: no text though/keithamus: no HTML/SVG though?/
15:25:27 <keithamus> s/keithamus: no text though/keithamus: no HTML/SVG though?/
15:25:34 <masonf> fantasai: in the past, we hesitated in allowing author to manipulate how file selector looks or operates.
15:25:50 <masonf> fantasai: if we allow it to be styled and change the content, are we happy?
15:26:10 <masonf> lwarlow: they can, effectively. Via hiding it and doing what they want. Nothing unique to file input that I know of.
15:26:16 <masonf> fantasai: just wanted to check.
15:26:26 <masonf> lwarlow: reasonable question, but I think it's already not an issue
15:26:41 <masonf> anne: not ideal that you can change the appearance:auto behavior, but hard to undo that now.
15:26:57 <masonf> fantasai: david is right that content property is weird depending on the kind of pseudo element. Might need to look into that.
15:27:09 <masonf> lwarlow: ideally content property works on the new things, so that'd be good
15:27:29 <masonf> fantasai: would like that to work, not sure it works now. Compat-based restrictions.
15:27:35 <masonf> anne: can replace with icon, but not text and icon
15:27:44 <masonf> anne: used to be in CSS generated content spec.
15:28:07 <lwarlow> q+
15:28:09 <masonf> fantasai: opera tried to implement it and it broke the web. Maybe we could box in the compat problems, but needs digging.
15:28:38 <masonf> lwarlow: if we limit to just appearance:base mode, that might help. Having this element backed doesn't mean the content property needs to work in that mode.
15:28:38 <fantasai> s/implement it/implement unrestricted 'content' on normal elements/
15:28:59 <masonf> lwarlow: is there an issue to track the content property issue?
15:29:34 <masonf> fantasai: worth raising that question. We want content to work on all of these pseudo elements, but there are restrictions - need to go remember.
15:29:41 <masonf> fantasai: spec might not be up to date.
15:30:02 <masonf> fantasai: if we can make it that every value works except for e.g. the empty string (which was the compat problem)
15:30:13 <masonf> :-)
15:30:16 <fantasai> s/restrictions/restrictions on what values can apply to elements/
15:30:59 <masonf> astearns: where are we? I heard three options.
15:31:17 <masonf> lwarlow: resolution should be to update CSS spec to say it's not element backed, or we should update HTML to say it's a real button and keep it element backed.
15:31:35 <masonf> lwarlow: if we make it not element backed, we can say we could relax that in the future.
15:31:51 <masonf> anne: we should make them all consistent. I'm not convinced about the leaf element concept is understandable.
15:32:02 <masonf> anne: I'm not sure how you'd qualify placeholder for example
15:32:12 <jarhar> q+
15:32:17 <masonf> anne: I'd stil want to say it's not element backed for now
15:32:35 <masonf> anne: once we have initial implementations, we might be able to have a v2
15:32:35 <astearns> ack lwarlow
15:32:37 <astearns> ack jarhar
15:33:07 <masonf> jarhar: if for base appearance, the file picker has element backed real button. I'd not want to support two different things for appearance:base and appearance:auto.
15:33:25 <fantasai> testcase -
15:33:25 <fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Adiv%20%7B%20border%3A%201px%20solid%20orange%3B%20%7D%0A.a%20%7B%20content%3A%20url(http%3A%2F%2Fxanthir.com%2Fpony)%3B%20%7D%0A.b%20%7B%20content%3A%20%22pony%22%3B%20%7D%0A.c%20%7B%20content%3A%20%22pony%22%20url(http%3A%2F%2Fxanthir.com%2Fpony)%3B%20%7D%0A.d%20%7B%20content%3A%20%22two%22%20%22ponies%22%3B%20%7D%
15:33:28 <masonf> jarhar: maybe there's a reason to do it later. But impementation-wise it'll be easier to do it now, rather than later.
15:33:31 <fantasai> 0A%3C%2Fstyle%3E%0A%3Cdiv%20class%3Da%3ETest%3C%2Fdiv%3E%0A%3Cdiv%20class%3Db%3ETest%3C%2Fdiv%3E%0A%3Cdiv%20class%3Dc%3ETest%3C%2Fdiv%3E%0A%3Cdiv%20class%3Dd%3ETest%3C%2Fdiv%3E
15:33:53 <masonf> astearns: resistance to going full button now. dbaron, can you live with removing element backed pseudo for now?
15:33:58 <masonf> dbaron: yeah
15:34:06 <astearns> ack fantasai
15:34:18 <masonf> fantasai: I tested and in Safari you can replace an element with a replaced element as content, but no strings.
15:34:38 <masonf> fantasai: if content needs to work, we need to make them not element backed (and we should start there) or we need to investigate how to increase what content can do
15:35:05 <masonf> lwarlow: do we need to change compat for real elements vs ... {I missed this}
15:35:14 <masonf> fantasai: if we can generally expand scope, that sounds better
15:35:20 <masonf> lwarlow: would be nice, just don't want to block
15:35:36 <masonf> fantasai: not sure what triggers the compat problem. Empty string for sure, not sure what else.
15:35:47 <masonf> fantasai: resolution not to element back them for now, and try implementing
15:36:04 <masonf> fantasai: based on real shippable implementation, we can consider it then
15:36:14 <masonf> astearns: change the spec to say file selector button isn't element backed?
15:36:22 <masonf> s/change/resolution is to change
15:36:49 <masonf> lwarlow: yeah, and then browsers don't implement it as such
15:36:56 <masonf> astearns: any objections?
15:37:16 <lwarlow> https://github.com/w3c/csswg-drafts/issues/12250
15:37:17 <masonf> RESOLVED: remove the "element backed" line from CSS spec for file inputs
15:37:20 <masonf> (did I get that right?)
15:37:40 <astearns> yes
15:37:41 <masonf> astearns: anything else?
15:37:52 <masonf> lwarlow: structure changes between auto and base mode questions
15:38:03 <astearns> s/file inputs/:file-selector-button/
15:38:33 <masonf> lwarlow: color swatch implementation investigation. Webkit and chromium - not sure how you'd go about solving this. Can't change the DOM structure based on appearance property.
15:38:47 <masonf> keithamus: can wrapper be display:contents?
15:39:05 <masonf> lwarlow: yeah, maybe. Have two sibling trees and make one display:none.
15:39:11 <masonf> anne: have render tree ignore the wrapper
15:39:38 <masonf> anne: generate different shadow trees. WebKit they're generated lazily, and you could compute appearance property at generation time
15:39:55 <masonf> anne: why does the wrapper get in the way?
15:40:20 <masonf> lwarlow: various code paths for color input. Maybe not relevant for base appearance. When you change value of the color - it reaches in to change the displayed color.
15:40:29 <masonf> lwarlow: if DOM structure is different, you'd have to switch
15:40:42 <masonf> lwarlow: if you have the wrapper element it might mess with margins and padding and stuff
15:40:59 <masonf> lwarlow: unfortunate that the wrapper exists. Looked into it, and not sure it's used, but also not sure it's removable.
15:41:18 <masonf> anne: is the wrapper exposed. It's webkit-color-swatch-wrapper
15:41:26 <masonf> oops that was lwarlow
15:41:36 <masonf> keithamus: tailwind stuff resets it
15:41:48 <masonf> anne: should we have it then?
15:42:00 <masonf> lwarlow: they're specifically removing its appearance to make it work like firefox.
15:42:06 <masonf> anne: so it does have appearance
15:42:11 <masonf> anne: do something
15:42:30 <masonf> lwarlow: it has some properties like padding. End result is essentially the same as firefox. Remove padding and then style it the same.
15:42:37 <masonf> lwarlow: they want the color swatch.
15:42:59 <masonf> keithamus: almost every example in github is removing it
15:43:03 <masonf> anne: maybe remove it
15:43:15 <masonf> lwarlow: that would make the DOM tree consistent, so easier to implement
15:43:37 <masonf> astearns: should this discussion have gone to an issue?
15:43:46 <masonf> lwarlow: no
15:43:56 <masonf> astearns: should there be an issue about removing the wrapper?
15:44:08 <masonf> lwarlow: not in the spec at all. Maybe when there's a base appearance we can do that
15:44:29 <masonf> anne: deprecate/alias many of them long term. That's our hope.
15:44:48 <masonf> lwarlow: we have webkit-color-swatch, but in most other cases, we don't want pseudos in appearance:auto mode
15:44:56 <masonf> lwarlow: don't need much aliasing.
15:45:00 <masonf> anne: yeah mostly want them gone
15:45:16 <masonf> lwarlow: future work to figure out which of these we still need. There are many.
15:45:35 <masonf> anne: wrote code to auto-generate about 50 of them
15:45:53 <masonf> lwarlow: it's hard to tell when they're actually exposed.
15:46:03 <masonf> anne: we did add capability to hide them, Tim tried. But many exposed.
15:46:19 <masonf> astearns: any other topics?
15:46:26 <masonf> lwarlow: multi-select?
15:46:58 <masonf> jarhar: I proposed changing what happens with multiple when you don't have a size attribute - consistency between desktop and mobile
15:47:10 <masonf> jarhar: still collecting use counter data. How often people open select multiple on mobile.
15:47:22 <masonf> jarhar: compat questions around changing it. Might need to lean more on size attribute
15:47:37 <masonf> lwarlow: discussion about what the button needs within it for multiple
15:48:13 <masonf> jarhar: by default we should do the same thing as appearance:auto, if the author doesn't replace the button. Text of selected option for one selected. For 0, 2, or more, it'll say "3 items" etc
15:48:22 <masonf> jarhar: if the author replaces the button, that works
15:48:27 <masonf> lwarlow: selectedcontent?
15:48:38 <masonf> jarhar: some use cases for cloning all selected options into the selectedcontent element
15:49:06 <masonf> jarhar: render all of the icons, for example. Or build android firefox select multiple button with that strategy. Text of all options, separators, etc.
15:49:22 <masonf> s/Text of/Text for
15:49:37 <masonf> astearns: all of those questions weren't part of the size attribute discussion, right?
15:49:39 <masonf> jarhar: correct
15:49:47 <masonf> jarhar: things in my head until just now
15:49:58 <masonf> lwarlow: discussion at OpenUI
15:50:08 <masonf> lwarlow: ideas from WebKit on this?
15:50:18 <masonf> anne: reflecting it makes sense.
15:50:34 <masonf> anne: selectedcontent - not sure how it works with AT at this point. Might be wonky if all of the options are in there.
15:50:45 <masonf> anne: might get unwieldy if the options are long and the user selects all
15:50:55 <masonf> anne: AT might want summary instead of list
15:51:21 <masonf> jarhar: for select multiple, keep "4 items". For single-size select, how to announce button when author replaces it, for now AT announces whatever is in there.
15:51:37 <masonf> jarhar: making multiple different might be a good idea, in a11y tree
15:51:56 <masonf> anne: existing structures to do that. With a list of 4 items, it'll say it's a list, and starts reading but you can skip. Maybe something similar.
15:52:30 <masonf> astearns: sounds like that's it for today. Add for next time
15:52:46 <astearns> topic: end
15:52:50 <astearns> zakim, end meeting
15:52:50 <Zakim> As of this point the attendees have been dbaron, masonf, flackr, keithamus
15:52:53 <Zakim> RRSAgent, please draft minutes v2
15:52:55 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/29-css-minutes.html Zakim
15:53:02 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
15:53:02 <Zakim> Zakim has left #css
16:00:12 <Adam_Page> Adam_Page has joined #css
16:40:04 <jamesn> jamesn has joined #css
16:47:13 <antonp> antonp has joined #css