Dear WHATWG,<br><br>Recently section 4.10.4.3 of the HTML5 specification was changed to recommend that &quot;C:\fakepath\&quot; be prepended to the DOM value of file upload input elements. For example, when uploading &quot;/home/alex/upload.txt&quot;, JavaScript will see &quot;C:\fakepath\upload.txt&quot;. This is now implemented in IE8 and Opera 10; Firefox and Opera 9 return &quot;upload.txt&quot; and Safari and Chrome return &quot;/home/alex/upload.txt&quot;. I posted comments about this under the name &quot;Anonymous Coward&quot; 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.<br>
<br>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 &quot;upload.txt&quot;. It&#39;s easier to parse it that way too, since the &quot;C:\fakepath\&quot; will never have to be stripped off.<br>
<br>Second, this change is unintuitive. No novice is going to look at &quot;C:\fakepath\upload.txt&quot; and say &quot;Oh, that makes perfect sense.&quot; Developers on Linux, Mac OS, and BSD are really going to be raising their eyebrows—Unix systems don&#39;t even use backslashes in paths, they use forward slashes instead.<br>
<br>The change makes even less sense when what is actually sent over HTTP is just &quot;upload.txt&quot;. The difference between the DOM and HTTP will make it more difficult to design advanced web applications.<br><br>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.<br>
<br>Sincerely,<br><br>Alex Henrie<br>