[whatwg] Fakepath revisited

Dear WHATWG,

I would like to revisit HTML5 section 4.10.4.3, as circumstances have
changed since it was last discussed. For those of you not familiar
with the issue, section 4.10.4.3 defines the value property of <input
type="file"/> elements. This behavior is not currently consistent
across all browsers. For example, if I were uploading a file called
"upload.txt" into input element "foo", foo.value would be...

In Firefox 3: "upload.txt"
In Safari 4: "upload.txt"
In Chrome 2: "upload.txt"
In Internet Explorer 8: "C:\fakepath\upload.txt"
In Opera 10: "C:\fakepath\upload.txt"

Firefox, Safari, and Chrome have an intuitive behavior that requires
no extra parsing and no workarounds such as using "foo.files[0]"
instead. This behavior also reflects what is sent on to the web
server, which all browsers agree should be simply "upload.txt".

IE and Opera recognize that some web pages, in particular some old
router firmwares, are poorly designed. These firmwares were designed
to apply superfluous validation to foo.value, only allowing new
firmware to be uploaded from Windows, and only in an old web browser
which provides the full path to the file. So, to make sure that users
can upgrade the firmware of these old routers, but not wanting to
reveal to the web page the actual path to the file, IE and Opera
append "C:\fakepath\" to foo.value, thus confusing new web developers
but ensuring compatibility with poorly designed software.

HTML5 would declare IE and Opera's "fakepath" behavior to be
"standard" and Firefox, Safari, and Chrome's behavior to be
"nonstandard". HTML5 assumes that Mozilla, Apple, and Google are
willing to change their browsers' behavior to match IE and Opera.
However, as far as I can tell, none of these companies plan to do so.
Further, HTML5 expects us web developers to work around the fakepath
behavior for the next 20+ years in the name of compatibility.

A better solution exists: drop the fakepath requirement. Browsers that
desire extra compatibility can add fakepath to their compatibility
modes as they choose. Like other compatibility mode behavior,
implementation would be voluntary and not governed by the W3C. And
even without browser compatibility modes, bookmarklets, GreaseMonkey
scripts, and other tools will surface to help mitigate the problem.

The bottom line is that no web developer wants to have a confusing,
unintuitive, and very permanent standard. Please remove this
requirement from HTML5 before it becomes a standard. Don't punish all
web developers for the poor past designs of the few.

Sincerely,

Alex Henrie

Received on Wednesday, 2 September 2009 23:07:16 UTC