W3C home > Mailing lists > Public > public-html@w3.org > January 2012

Re: Hidden file inputs [Was: Revert Request]

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 31 Jan 2012 15:43:43 -0800
Message-ID: <4F287CAF.3050801@jumis.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
CC: Jonas Sicking <jonas@sicking.cc>, Laura Carlson <laura.lee.carlson@gmail.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On 1/31/12 3:21 PM, Benjamin Hawkes-Lewis wrote:
> On Tue, Jan 31, 2012 at 10:29 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> While I disagree with this method, I want to point out one little irking
>> unresolved issue.
>> <input type="file" hidden>  is becoming a real thing.
>> I don't think it's a big issue, but since a11y peoples are on this thread, I
>> do want to point it out.
>> This is how I'd handle it, in my current code.
>> <button onclick="file.click()" role="file button">Add files</button>
>> <input type="file" id="file" hidden />
> Providing custom file inputs by delegating clicks to a hidden file
> input is a tricky business, since UAs try to prevent activation of
> hidden file inputs for security reasons. When they do prevent it,

This ship has already sailed. As I understand it, Mozilla introduced it, 
WebKit is fixing bugs related to it.

It's a lot better than the previous situation of using: style="opacity: 0".

Security is handled by the typical manner: restricting execution to the 
current gesture.
That is, you can only send that click during a user gesture.

> As an aside, what's the advantage of including role="file button" in
> your markup example? Only one role would ever be used; only "button"
> is defined, and that semantic is represented by the element anyway.
> Possible negative effects of using the "file" token include:
>     1. Byte wastage.

It's five bytes.

>     2. Causing the control to be misinterpreted according to some
> future definition such as "represents a file".

Could certainly be a problem. There's no telling what's in store in the 
But since I have access to update my application in the future, I'm not 
too worried.

>     3. Constraining ARIA-Next to define the "file" role to mean "button
> that causes a file dialog to open" rather than whatever the spec
> editors think best at the time.

That's the same issue as #2.

I'm not constraining ARIA next at all, as I'm not putting "file" in a 
spec, I'm just sticking it in my current markup.
I don't believe "file" as a reference to the file system will become an 
ARIA role.
I don't believe "folder" will either.

Received on Tuesday, 31 January 2012 23:44:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:19 UTC