On May 16, 2008, at 5:50 AM, Jon Barnett wrote:
On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas
<[EMAIL PROTECTED]> wrote:
...
Imagine further that this "iPhone" has no user-visible file system. It
stores music, but annoyingly, the device vendor doesn't want to let
people upload songs to Web sites. What the vendor *does* want to let
people do is upload photos to Web sites, so that they can use sites
like Flickr or even post photos to their Weblogs from the road.
So the "iPhone" vendor implements <input type="file"> just for photos.
Is this the iphone's behavior? (earlier you said it doesn't implement
<input type=file>, but here you're saying it's implemented for photos)
No, this is a hypothetical scenario, but I think a highly realistic one.
It's rendered in a Web page as three components: (1) a button for
taking a new photo, (2) a button for choosing an existing photo, and
(3) a thumbnail of the selected photo. There's no "filename": that
wouldn't make any sense, because device has no user-visible files.
The interface for choosing a file isn't particularly important. It's
the style/presentation of the button that triggers that interface
that's in question, or being able to create your own interface to
trigger that file-choosing interface.
So if an author said input[type="file"]::button {width: 100px} (or
whatever the selector turned out to be), what should this device's
browser do? Style both of the buttons as 100px wide? Or both of them as
50px? Or ignore any width completely, on the grounds that the author
probably doesn't know what they're doing?
...
Sure, we agree that tricking a user into typing a filename is somewhat
of a security risk, and browsers have mitigated that. My point was
"disguising" the button that triggers the file-choosing dialog box (or
web-page-like interface, if you will) is NOT a security issue.
...
Agreed. My issue is not with its security, but with its
device-independence.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
