[whatwg] Fakepath revisited

[Alex Henrie]

On Mon, Sep 7, 2009 at 9:41 AM, Anne van Kesteren<annevk at opera.com> wrote:
> On Mon, 07 Sep 2009 17:38:39 +0200, Nils Dagsson Moskopp
> <nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:
>>
>> As the fakepath problem occured precisely because Web Developers Are
>> Stupid, maybe an easy way out would be to spec a method to get the real
>> value (or write it boldly into the spec annotations) ?
>
> File.name -- http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

Think about how this will affect web development 20 years from now.
Inexperienced web developers will try to use the more intuitive
property foo.value, not realizing that they should use
foo.files[0].name instead. They may not know that foo.files[0].name
exists, or they may assume that it behaves the same as foo.value. Some
of those developers will think that the compatibility problems that
led to fakepath still exist, and will use
foo.value.substr(foo.value.lastIndexOf("\\") + 1) despite the
potential problems if the filename actually contains a backslash. In
all, HTML will be harder to learn and bad designs will continue to be
made.

Actually, I just realized one reason why Firefox's omission of
fakepath hasn't caused widespread compatibility problems. Think about
it: if there are no backslashes in the file name, then
foo.value.substr(foo.value.lastIndexOf("\\") + 1) will work perfectly
happily with both "C:\fakepath\upload.txt" and "upload.txt", because
lastIndexOf will return -1 if no backslashes are found. Clearly, the
affected web pages are doing a bit more than just trying to extract
the file name or extension. Can you please share the list of web pages
you found that are affected by this problem, so that we can see
exactly what they're trying to do?

On Mon, Sep 7, 2009 at 9:56 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
>
> On Mon, Sep 7, 2009 at 4:24 AM, Alex Henrie <alexhenrie24 at gmail.com> wrote:
>
> > Also, I suspect that if the manufacturers of
> > the affected routers aren't interested in releasing updates to make
> > them work in non-fakepath browsers like Firefox, they may not be
> > interested in releasing updates for them at all.
>
> IIRC, the problem is that you can't upload the new firmware to the
> router at all, so the manufacturer can't release an update to fix it.
> It can only make sure it's fixed in new models.

You know, if the manufacturers cared they could release a program that
updated the router without using the broken web interface.

> > Essentially, you are choosing to trade long-term good design for
> > short-term compatibility.
>
> Browser vendors cannot sacrifice compatibility for long-term goals,
> because their users will rebel.  Any standard that demands
> incompatibility with existing content will be ignored by implementors,
> as XHTML was, and thus useless to authors.  That's the fact of the
> matter, whether we like it or not.  New APIs can be introduced, but
> old ones can't be changed in incompatible ways.

CSS2 demanded incompatibility with IE6 and IE7's previous
implementations. IE8 resolved these problems and IE8 users haven't
taken to the streets of Redmond with pitchforks yet. I'm asking the
same thing: take good behavior from Firefox, Safari, and Chrome and
get it working in IE and Opera too. It's not impossible, and it's well
worth it in the long term.

-Alex