You realize you don't need input field for file input in any of the modern browsers. Just capture the click event and create input field temporarily.
let i = document.createElement('input');
i.type = 'file';
// other attributes if you like
i.onselect = ev => {
// ev.files contains selected files
};
i.click();
i.remove();
No stupid styling hacks needed. At most you may need tabIndex on the <a> or <div> that represents the button for selecting files.
You can leave <input type=file> around if you want to submit data via <form> and not via XHR.
You clearly never implemented any of the above stupidity with file input styling and overlays and passthrough of events, and different unchangeable widths of file inputs you had to account for in various versions of browsers, and bugs in specific browser versions, and discontinuity in the input field clickable surface so part of the button is not clickable for no reason whatsoever to the user, so that everything works as expected in E6+IE7+IE8+IE9+FF1+Sfari,... to think it's even comparable on the hackiness scale.
That's another issue easily solved by DnD API modern browsers implement. And should probably be done differently with regards to UX depending on whether the clicky part was a button, or a larger upload area.
Frankly, I don't find the original UX of dragging files onto an upload button all that intuitive. So instead I add drop functionality to a larger container in my apps. So if I have dialog that accepts files, users can drag files anywhere over the dialog and the dialog highlights that it accepts drops while dragging.
The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?
Why does there even have to be a button? I want an API not a button...
> The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?
Why don't the buttons on your website look like HIG-compliant buttons on whatever platform the user is using? That's what web chrome looked like back in the aughts and it was fantastic. Apparently you can still do it: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Th....
Question, is the point of HIG-compliance to make everything look exactly the same on a platform? Or is it to nail down some abstract sense of what makes UI intuitive to use?
It seems like people with this viewpoint pay lip service to the latter goal, which allows for trends like Material Design so long as they fit with the guidelines, while really wanting the former, which to me looks like nothing more than tilting at windmills.
I'd post screenshots of our current CMS work, where we have a design staff working earnestly to make everything super-intuitive, but HN doesn't do image management so this discussion will be sadly deprived of examples.
> “The purpose of visual consistency is to construct a believable environment for users… The transfer of skills is one of the most important benefits of a consistent interface, especially for beginning users.” pg. 10
> “…consistency makes it easier for a user to learn new applications; it also makes it less likely that a user who follows habits learned from one application will make a disastrous mistake when using a different one.” pg. xi
The HIG goes beyond simply expressing principles of what makes for a good UI. The consistency in and of itself allows users to develop an intuition and muscle memory for how their computer will work. That intuition is destroyed when different apps look and behave differently. In that sense, it's better to be less intuitive according to some abstract principle if necessary to achieve consistency. It will take the user longer to understand a "more intuitive" UI starting from first principles than to understand a UI that exhibits the quirks embedded in the HIG they already know.
This will never work because each browser has its own idea of how native controls should be rendered, even within the same platform. The link you posted even has examples of this. I'm all for the idea of using OS-native controls where possible, and for native apps you should absolutely do this, but I just don't think it's feasible on the web; I believe making your controls consistent across browsers is a better goal in most cases, as long as you don't sacrifice accessibility.
Is that a problem with the file input button, or with every other button on your website?
The file input button does seem to be a barely remembered feature by browser builders. It's weirdly specific, doesn't work the same way on phones, and probably only hangs around because there isn't a decent alternative.
IIRC correctly, the File Input button was deliberately excluded from CSS styling, as it was felt that it would be abused to 'steal' data from clients, if the user wasn't aware it was file upload...