
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 7, 2009, at 3:53 PM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, Sep 8, 2009 at 3:56 AM, Aryeh Gregor <span dir="ltr"><<a href="mailto:Simetrical%2Bw3c@gmail.com">Simetrical+w3c@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Browser vendors cannot sacrifice compatibility for long-term goals,<br> because their users will rebel.</blockquote><div><br>We can sacrifice *some* compatibility for *some* long-term goals. We do it all the time, even Microsoft. It's all about tradeoffs.<br><br>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.<br></div></div></blockquote></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>