On Mon, 23 Mar 2009, Alex Henrie wrote: > > 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'm surprised Chrome returns a Unix path; is this on Windows? > 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. The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) > 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. I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'