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

[whatwg] Fakepath revisited

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 13 Sep 2009 14:58:03 -0700
Message-ID: <C8E14192-DAFA-423C-9BA3-FAF75B733E06@apple.com>

On Sep 7, 2009, at 3:53 PM, Robert O'Callahan wrote:

> On Tue, Sep 8, 2009 at 3:56 AM, Aryeh Gregor <Simetrical 
> +w3c at gmail.com> wrote:
> Browser vendors cannot sacrifice compatibility for long-term goals,
> because their users will rebel.
>
> We can sacrifice *some* compatibility for *some* long-term goals. We  
> do it all the time, even Microsoft. It's all about tradeoffs.
>
> In this case, I'd like to see a list of specific routers, sites etc  
> that triggered the implementation of fakepath in Opera and IE. I'd  
> like to crosscheck with our Bugzilla to understand why we haven't  
> felt the need to do this in Firefox.

For Safari/WebKit, we haven't seen specific bug reports that are  
clearly identifiable as this issue. But I'm willing to believe it is  
real. We sporadically get bug reports about specific routers, but we  
rarely have the resources to acquire the particular hardware and  
investigate the issue. Thus, the problems tend to remain unresolved  
unless it's a very popular piece of hardware and the bug keeps it from  
working at all.

For what it's worth, I think fakepath is kind of gross, but far from  
the grossest compatibility hack in the Web platform. And in this case,  
input.files will give a cleaner and more capable API. So I'm ok with  
the hackery here.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090913/8d9b1c83/attachment.htm>
Received on Sunday, 13 September 2009 14:58:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC