[whatwg] "C:\fakepath\" in HTML5

Alex Henrie alexhenrie24 at gmail.com
Mon Mar 23 22:00:30 PDT 2009


Dear WHATWG,

Recently section 4.10.4.3 of the HTML5 specification was changed to
recommend that "C:\fakepath\" be prepended to the DOM value of file upload
input elements. For example, when uploading "/home/alex/upload.txt",
JavaScript will see "C:\fakepath\upload.txt". This is now implemented in IE8
and Opera 10; Firefox and Opera 9 return "upload.txt" and Safari and Chrome
return "/home/alex/upload.txt". I posted comments about this under the name
"Anonymous Coward" on the IEBlog. As a web developer who will have to design
around this, I would like to voice my strong objection to the change.

First, this change is dishonest. It tells JavaScript that the file is stored
somewhere that it is not. And why say anything, true or not, about where the
file is stored at all? All JavaScript needs to know is that the file is
called "upload.txt". It's easier to parse it that way too, since the
"C:\fakepath\" will never have to be stripped off.

Second, this change is unintuitive. No novice is going to look at
"C:\fakepath\upload.txt" and say "Oh, that makes perfect sense." Developers
on Linux, Mac OS, and BSD are really going to be raising their eyebrows—Unix
systems don't even use backslashes in paths, they use forward slashes
instead.

The change makes even less sense when what is actually sent over HTTP is
just "upload.txt". The difference between the DOM and HTTP will make it more
difficult to design advanced web applications.

I thought the point of HTML5 was to resolve problems in HTML, not to drag
along hacks and baggage implemented in some browsers but not others. But
this, this is just ugly.

Sincerely,

Alex Henrie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090323/3f7c0fd8/attachment.htm>


More information about the whatwg mailing list