[whatwg] "C:\fakepath\" in HTML5

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'