[css-selectors] Can you standardise a pseudo-element selector for file inputs?

[Roy-Orbison]

As per this Mozilla bug, there are already vendor-specific selectors to style buttons rendered within <input type=file> controls for Webkit and Trident engines. Webkit alone represents the majority market share, EdgeHTML is now "legacy", leaving Gecko/Quantum as the only current major engine without it. Mozilla is reluctant to add their own vendor-prefixed selector when the sensible choice would be to make ::file-upload-button official.

[css-meeting-bot]

The CSS Working Group just discussed [css-selectors] Can you standardise a pseudo-element selector for file inputs?, and agreed to the following:

• RESOLVED: expose this selector and name it ::file-chooser
• RESOLVED: expose this selector and name it ::file-chooser button

The full IRC log of that discussion

<dael> Topic: [css-selectors] Can you standardise a pseudo-element selector for file inputs?
<dael> github: https://github.com/w3c/csswg-drafts/issues/5049
<dael> emilio: Apparently all others UI than FF have a pseudo-element for this.
<dael> emilio: Is anyone planning to remove it? If not, can we add a specific pseudo for this?
<dael> Rossen_: Is question about if component model for the control will change so there's no button?
<dael> emilio: No, question is that all of them have a button and all UI except FF expose as a pseudo element. ONly reason to not make a standard version is if underlying model will change. I don't see a reason not to add this unless there are objections
<dael> TabAtkins: Still vaguely uncomfortable about exposing internals of form controls, but I'm comfortable with this one. All files must have button and I expect will in future
<dael> emilio: Ideas on name?
<dael> TabAtkins: In issue works for me
<dael> Rossen_: Can we future proof more?
<dael> Rossen_: Currently ultra specific to the input type = file. If we're going down the path of exposing selectors to target form controls I would hope more generic so if there are other input types that can have a button that this selector will match with them
<dael> emilio: Not sure I agree. All different input types have values, mostly prefixed pseudo-elements. I don't think you want...I'd rather it be specific than potentially expand in the future and websites change b/c of that
<dael> TabAtkins: Comfortable with button name. This is a naming convention that we could extend
<jensimmons> I wanted to ask "how does this fit with the overall form control research project that's underway?" (Instead I hung up the call)
<dael> smfr: I don't like upload in the name. It's choose a file. Not sure it should look the same b/c this is apsecific behavior about trigger UI file selection. If it says only image types it opens photo picker. Name needs to be generic
<dael> emilio: Edge name is ::msbrowse
<smfr> ::file-chooser-button
<fremy> ::file-picker-button
<dael> Rossen_: WE spent quite a bit of time bikeshedding that name back when we expanded our control model. I think it was debated quite a bit and I was on the other side of the argument. If everyone else is fine with it, sure.
<dael> jensimmons: Curious about work around form control styling coming in the next few years. Will there be a pseudo-element for buttons? What's the names that have been discussed there.
<dael> TabAtkins: I believe gregwhitworth and Nicole Sullivan have been working on that and doing user research. Work is ongoing but not sure the results.
<dael> jensimmons: I know it's massive and lots of questions, but this feels like it should be designed in the context of that. Though I don't mean don't push for 2 years
<dael> TabAtkins: I feel you. I think the use cases and name are clear enough I think this would be an alright one off to do.
<dael> Rossen_: Sounds like general agreement around the reasoning to expose this. Naming-wise let's not spend hte hour bikeshedding. file-chooser or file-picker sort of fit what has been explained even if case you open an image gallery it's still a file
<dael> Rossen_: Can we pick one and move on? file-chooser or file-picker are good enough for now?
<fremy> +1 to either
<fremy> Rossen_: ^_^
<dael> Rossen_: I'll choose file-chooser. We can rename later
<jensimmons> I'm ok with file chooser or picker or upload, etc. I don't really like "browse" — it's far too generic in the context of "browser" and plus a younger generation of people don't really know what 'browsing files' means....
<dael> Rossen_: Obj to expose this selector and name it ::file-chooser
<dael> RESOLVED: expose this selector and name it ::file-chooser
<dael> RESOLVED: expose this selector and name it ::file-chooser button
<emilio> `::file-chooser-button`

[gregwhitworth]

Can we get an anatomy definition for this in Open UI. The primary purpose of this site is to begin defining the actual pieces of the control from a functional perspective and align across the industry. I can help someone out here. Let me know if you'd like to setup 30 minutes to get it rolling. For the file input anatomy itself it shouldn't take too long.

Here's the contribution docs: https://open-ui.org/contribute

[jensimmons]

I'm really happy we made a clear and quick decision on the call we just had. Also, perhaps the name needs a bit of additional consideration? Testing, really... test the name with Authors to make sure we make the right call. So I tweeted: https://twitter.com/jensimmons/status/1263142931034234886 to see what Authors think.

[gregwhitworth]

Thanks @jensimmons - only reason I want some research done is to ensure that we aren't standardizing ourselves into a corner. Since there is a web compat hit this may be fine but in our peeling of the <select> onion and some other controls there are often usecases that are lost due to cementing what's there at first glance. Again, not saying that the resolution is wrong I just want to ensure we're not missing a valid usecase that may require an additional psuedo/anatomy design or other way of thinking about the problem. Thanks @emilio for your willingness to take an initial stab at the research/proposal page in Open UI. Again, happy to lend a hand where necessary.

[emilio]

@gregwhitworth here's my initial draft. The good thing is that all the systems listed there which have file inputs have a button of sorts, fwiw.

So I think this is pretty sensible over-all.

[Loirooriol]

Should this be a tree-abiding pseudo?

[emilio]

Probably.

[fantasai]

I will note that there are a lot more search results for "file picker" than "file chooser". And also most of the ones for "file chooser" in quotes seem to be about some Java thing...

[tabatkins]

And yes, it's a tree-abiding pseudo.

[Roy-Orbison]

I will note that there are a lot more search results for "file picker" than "file chooser". And also most of the ones for "file chooser" in quotes seem to be about some Java thing...

"file upload" is way ahead in search volume when coupled with either css, or button. As I wrote in the WICG draft thread:

I agree with the -button suffix as the selector's purpose essentially dictates it. However, for consistency's sake, the verb really should be a choice between "upload" and "select"/"selector". The majority of standards documents for HTML and JavaScript refer to such controls as file upload, and the action performed as selection, and have done so for many years. What benefit is there to CSS authors in deviating from those conventions?

There is merit to each:

• the button triggers a file selection system but operating it doesn't guarantee a file upload attempt by the user; and
• emphasising upload as the action is important because successful selection of any file immediately makes the file's name and contents available to running script, unlike the olden days when it was only a state of intent to upload upon form submission.

It's already "upload" in ::-webkit-file-upload-button so why the change to "chooser"? I appreciate the speedy response to this issue, but I think making a new name instead of using the existing convention is a mistake.

[Roy-Orbison]

The only consideration of upload in the IRC log was

smfr: I don't like upload in the name. It's choose a file.

This is not really true because the act of choosing a file is equivalent to uploading it. Choosing a file causes (a copy of) it to move "up" from the context of the OS to that of the web page/app.

[plinss]

A file input only selects a file, submitting the form uploads it. They are not equivalent.

That said, I'm not thrilled with the name myself. But it's still subject to change. We had to pick something in the meanwhile.

[Roy-Orbison]

A file input only selects a file, submitting the form uploads it. They are not equivalent

@plinss This is barely technically correct. A vanilla form won't submit the data until the user chooses, but they are the minority. Once chosen, a file is no longer private to the user. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file As soon as a file is selected, the change event fires on the element, and the file data + name is exposed via the input.files property. It is very common for upload controls to act on that event and immediately submit the file data to a remote machine with no further user interaction.

[plinss]

In your example, it's still JS that's uploading the file, not the input control. It's also entirely possible that client-side JS acts on the file without ever uploading it, see the second half of the sentence you quoted from MDN.

I also find it interesting that when describing the action you used the terms "chosen" and "selected".

An "upload control" as you describe it, is simply a file select control with script to do the upload. Without the script, or a form submission by other means, there is no upload. Whether or not this is the most common use, it's still not descriptive of what the input control does. As I said, I'm not a fan of the current name, but I'm strongly opposed to calling any part of a file input an "upload" control, this would be a disservice to authors.

[Roy-Orbison]

Were I writing standards docs, I would use the word "select" over "choose", because that's what countless other docs already do.

Referring to it as an "upload control" is not my nomencalture, it's the spec and is independent from associated script.

I'm strongly opposed to calling any part of a file input an "upload" control, this would be a disservice to authors.

…who are already referring to it as an upload control and will continue to in the future, not least because of ::-webkit-file-upload-button. I agree that selection better represents the initial action triggered by the button, but upload better represents the consequence of using it.

I don't think "upload" is the only answer, more that "choose" should not be. I've only bothered writing anything about this because it seemed that existing conventions were being ignored.

I'll stop bike-shedding now.

[emilio]

I will note that there are a lot more search results for "file picker" than "file chooser". And also most of the ones for "file chooser" in quotes seem to be about some Java thing...

There are other precedents for "file chooser", fwiw: https://developer.gnome.org/gtk3/stable/GtkFileChooserButton.html

[yisibl]

Among other form elements, there are more pseudo-elements with prefixes, should we also standardize them? e.g.

<input type="range">
::-webkit-slider-runnable-track
::-webkit-slider-thumb
::-moz-range-thumb
::-moz-range-track

[gregwhitworth]

We discussed this on the Open UI telecon today following some research across component libs and resolved on file-selector-button https://github.com/WICG/open-ui/issues/91#issuecomment-639160328

The minutes can be seen here: https://github.com/WICG/open-ui/blob/master/meetings/telecon/2020-06-04.md

[emilio]

Among other form elements, there are more pseudo-elements with prefixes, should we also standardize them? e.g.

<input type="range">
::-webkit-slider-runnable-track
::-webkit-slider-thumb
::-moz-range-thumb
::-moz-range-track

+1 from me, for what is worth, but probably different issue.

[gregwhitworth]

+1 from me, for what is worth, but probably different issue.

Yeah there many parts that need to be made interoperable as well as exposing parts that exist across platforms but aren't. @yisibl if you have interest in aiding in that I'd love to have you start defining an anatomy for these over in Open UI which will help identify the parts across OSes, libs, and UAs including the ones you mentioned. Additionally, there may be states and other aspects we should possibly create/expose in addition.

[emilio]

agenda+ to see if the name proposed above makes sense to the WG.

[css-meeting-bot]

The CSS Working Group just discussed Pseudo-selector for File Inputs, and agreed to the following:

• RESOLVED: Rename to ::file-selector-button

The full IRC log of that discussion

<fantasai> Topic: Pseudo-selector for File Inputs
<fantasai> ScribeNick: fantasai
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5049#issuecomment-639161484
<fantasai> emilio: We came up with name "file-chooser-button-thing"
<fantasai> emilio: OpenUI folks debated came up with different name
<fantasai> emilio: I feel like we should still get a CSSWG resolution
<fantasai> Rossen_: So this is renaming ::file-chooser-button
<fantasai> emilio: yes
<fantasai> emilio: proposal is ::file-selector-button
<fantasai> gregwhitworth: That name is from looking through various componenents
<fantasai> gregwhitworth: Most don't have a button, but of the ones that do, that's the naming trend
<astearns> +1 from me
<fantasai> florian: Sounds good to align with OpenUI
<fantasai> florian: second thought is how to coordinate better with OpeNUI
<fantasai> Rossen_: We have plenty of liaison here in the WG
<fantasai> Rossen_: The meta-question here, we can debate later
<fantasai> Rossen_: Ideally most such work can involve WG members and the WG
<fantasai> Rossen_: See mostly support, no counterproposals. Any objections?
<fantasai> RESOLVED: Rename to ::file-selector-button

[nt1m]

Why not align with HTML rather than OpenUI, Java, Gnome, etc?

So: ::file-input-button. It's easier this way to set a precedent for ::range-input-track, ::search-input-clear-button, etc. I think it'd be nice to have some kind of re-usable naming scheme for the future.

[emilio]

In the past there have been multiple buttons in <input type=file>, so ::file-input-button may not be a great choice.

[sideshowbarker]

The CSS Working Group just discussed Pseudo-selector for File Inputs, and agreed to the following:

* `RESOLVED: Rename to ::file-selector-button`

Is there a reason the actual spec change for that has not been made yet? Is there an open PR for it?

[emilio]

https://github.com/w3c/csswg-drafts/pull/5788 is the spec PR.

[emilio]

https://github.com/web-platform-tests/wpt/pull/26876 un-tentatives the tests.