[whatwg] "C:\fakepath\" in HTML5
Anne van Kesteren
annevk at opera.com
Tue Mar 24 07:15:33 PDT 2009
On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Sure it is. You just need a browser that'll allow you to do a firmware
> upgrade to fix it. Which means that if one gets such an upgrade shipped
> before all browsers stop sending paths, things seem to be ok. I agree
> they're not as happy as they could be, but they're ok. In addition, is
> the expected lifetime of the affected device comparable to the expected
> time it takes to deploy the new behavior in browsers? If so, it's worth
> it to contact the device maker and ask them to fix things in their next
> model instead of working around them.
Microsoft did. And nothing changed in well over a year. (They say so in a
comment on the blog post.)
> As far as the "significant number of sites" above... I wonder whether
> there's UA sniffing going on here that causes some of these to assume
> certain things about IE only. We've certainly seen quite a number of
> issues along those lines: we fix a bug, and discover that sites had
> written special browser-specific code taking advantage of that bug.
Opera was the first doing this and we hit a few issues as well so we
decided to go with a simple prefix (C:\fake_path\ changed to C:\fakepath\
now per discussion with Microsoft). It looks a bit ugly, but it's not at
all the issue that same make it out to be I think. (E.g. the initial email
claimed this inconsistency between the DOM and HTTP would cause issues for
Web application developers...) Furthermore, once we get interoperable
support for <input type=file multiple> and the fileList proposal starts
moving we can provide cleaner access directly to the file name there.
--
Anne van Kesteren
http://annevankesteren.nl/
More information about the whatwg
mailing list