[whatwg] "C:\fakepath\" in HTML5
Ian Hickson
ian at hixie.ch
Mon Apr 27 23:18:43 PDT 2009
On Thu, 26 Mar 2009, Randy Drielinger wrote:
>
> With the risk of not being compliant with other OS's, but isn't using
> file://localpath/<real_file_name.extension> (so using file://localpath/
> by default) the solution for the original suggestion?
>
> This ensures not breaking anything on existing websites and is a far
> more logical name for the whole workaround.
While this might have been better, I think that since IE8 and Opera have
both implemented and shipped this, a change would have to be really
compelling to be adopted. I'm not sure this is really compelling.
On Sun, 29 Mar 2009, Randy Drielinger wrote:
>
> My alternative (or any similar proposal) is way better than C:\fakepath,
> ensuring cross-platform uniform (expected) behavior.
How is a fixed "C:\fakepath\" prefix not cross-platform and uniform?
> With the risk of repeating myself, are we forcing the specs to cover all
> possible exceptions JS-programmers create?
We're forcing the specs to cover whatever is needed for an implementation
to support legacy content.
On Sat, 11 Apr 2009, Nils Dagsson Moskopp wrote:
> Am Dienstag, den 24.03.2009, 08:18 +0000 schrieb Ian Hickson:
> > > > According to Microsoft:
> > > >
> > > > http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx
> > > >
> > > > ...the problem was with "a significant number of sites (e.g.
> > > > education products, several movie sharing sites, etc) and devices
> > > > (e.g. popular home routers)". The blog post above includes a
> > > > screenshot of a firmware upgrade screen that has this problem.
> > > > This is not a site that could be fixed.
>
> Designating the router as element of the "trusted zone" (intranet) again
> (they reportedly took it out with IE8) should fix that, or shouldn't it?
> I'm not that familiar with MSFT software.
In general I don't think we should be encouraging more use of IE's modes.
They're a big enough mess as it is.
> > > > Maybe someone from Opera could let us know which sites caused them
> > > > to do this? Was it many, as with Microsoft?
>
> What we apparently do not have here is cold, hard data. As you said on
> many other occasions, use cases need to be laid out clearly.
>
> Since this (IMHO extremely confusing) inconsistent change will be
> enshrined for generations to come, I am against it - unless the number
> of (public !) sites is so big that we can't fix that problem otherwise.
I agree that better data would be great, but it's not clear how to find
this data. File upload controls tend to be hidden behind password-
protected pages and thus hard to discover.
> > I followed their lead because I have found that speccing something
> > that is already implemented is more effective than inventing new
> > syntaxes when it comes to getting implementations. In this particular
> > case, it also seems that the "./" syntax wouldn't in fact fix the bugs
> > that were found.
>
> Fixing the buggy web pages would also fix stuff. Why can't this be part
> of IE compatibility mode?
I'd rather not have to spec additional modes as well.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list