I guess given appearance: auto is already a mess maybe this is fine? But it feels unfortunate, especially once we get appearance: base where I feel we'd want to specify one way or the other anyway.

I wonder if this shouldn't match at all for appearance:auto. At least I think @emilio argued that it shouldn't because those are replaced elements. And it certainly seems preferable that for appearance:auto you don't get to style parts of the control.

cc @whatwg/forms @nt1m

This is a pre-existing pseudo element rather than a new one so I don't think no longer matching it is an option.

Especially when there's an even older ::-webkit-file-upload-button.

I'm happy with using <button> instead of <input type=button>

It looks like @emilio was the one who wrote that it is a <button> as opposed to an <input type=button> in the css spec here: w3c/csswg-drafts#5788

It also looks like it was defined in html to be a thing with "button layout", but not specifically a <button> or <input type=button>: #6250

I agree with luke that if we stop matching ::file-selector-button/::-webkit-file-upload-button for appearance:auto it will probably break websites. I wonder if any implementations/implementors are actually interested in changing this for appearance:auto to not be a <button>/<input type=button>?

::first-line doesn't work on input buttons in Firefox, but does on real buttons.

That's just because we don't allow ::file-selector-button::first-line (but if we fixed that it'd work).

I wonder if any implementations/implementors are actually interested in changing this for appearance:auto to not be a <button> / <input type=button>

What should it be instead? In general, <button> is a bit more flexible and easier to reason about, so lacking implementation complexity concerns I'd prefer to align with Gecko here.

That's just because we don't allow ::file-selector-button::first-line (but if we fixed that it'd work).

Isn't this allowed since ::file-selector-button is an element-backed pseudo-element?

What should it be instead? In general, <button> is a bit more flexible and easier to reason about, so lacking implementation complexity concerns I'd prefer to align with Gecko here.

I agree, this is my preference too

Isn't this allowed since ::file-selector-button is an element-backed pseudo-element?

It should per spec, yeah, but that concept wasn't around when we implemented it. So it is a Gecko bug that it doesn't work (in fact @lukewarlow is fixing some of that).

That's just because we don't allow ::file-selector -button: :first-line (but if we fixed that it'd work).

I mean on input buttons in general aside from the file input. It's a separate bug that I need to file.

It still seems a little concerning to me to impose even more requirements on appearance: auto, especially without having much clarity on what where we want to end up for it overall. For most (all?) controls that's still a big red box in the HTML standard.

It still seems a little concerning to me to impose even more requirements on appearance: auto

I understand this concern but personally I think this is a special case. Browsers are largely in agreement on what a file input looks like. In LTR flows it's a button followed by some text and optionally the browser may include additional stuff (I believe WebKit might show thumbnails?). All browsers already match :: file-selector-button on the button part of the control in auto mode, and I think it's highly likely we will always have to do that.

The main question I guess is that perhaps this pseudo element should only be element backed when in appearance: base mode? This would have to be a discussion for the csswg and I'm not sure if it makes sense (or even if it's possible?) for that to be conditional on the appearance.

For me personally I think it would make the most sense to simply define this as being a real button element, and have file elements be special in the fact they're slightly defined for auto appearance mode for historical reasons. Especially given that if a browser has to use a real button in one mode they're likely to also just use that same element in auto mode given it's practically the same thing.

Based on discussions in a previous whatnot I've gone ahead and made a spec PR to explicitly require a real button element. #11257

Was there a decision for appearance: base that pseudo-elements should be element-backed? That was an open question until somewhat recently, as it was unclear whether we should offer a consistent API with that.

I'm not aware of anything specifically related to appearance:base but this pseudo is defined to be element backed predating CSS forms.

I think it would depend on the specific pseudos as to whether they are element backed or just tree abiding.

Cc @nt1m in case I'm missing something.

Our position has been that we want consistent behavior for all pseudo-elements that apply to form controls. It shouldn't be a per-pseudo-element choice.

From that perspective not having them be element-backed is probably more tenable.

That's the first I've heard of that and it's slightly concerning to me. Rather than have separate conversations in CSS and in html I'm adding this to the joint tasks force meeting for discussion.