W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

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

From: Alex Henrie <alexhenrie24@gmail.com>
Date: Mon, 23 Mar 2009 23:00:30 -0600
Message-ID: <e89c552e0903232200j38920a9ch8c0c89da65dd0b33@mail.gmail.com>

Recently section 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

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.


Alex Henrie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090323/3f7c0fd8/attachment.htm>
Received on Monday, 23 March 2009 22:00:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:10 UTC