[whatwg] Fakepath revisited
alexhenrie24 at gmail.com
Mon Sep 14 12:17:33 PDT 2009
On Mon, Sep 7, 2009 at 12:56 PM, Aryeh Gregor<Simetrical+w3c at gmail.com> wrote:
> On Mon, Sep 7, 2009 at 2:41 PM, Alex Henrie <alexhenrie24 at gmail.com> wrote:
>> CSS2 demanded incompatibility with IE6 and IE7's previous
>> implementations. IE8 resolved these problems and IE8 users haven't
>> taken to the streets of Redmond with pitchforks yet.
> IE6 and 7 weren't even compatible with CSS1 in many ways. On the
> other hand, all other browsers overwhelmingly were. It would have
> been impossible to do anything that didn't either break IE, or break
> everyone else, *dramatically* (as in "everyone has to rewrite all
> their pages" dramatically). Since the behavior of everyone else was
> already specced, and IE's wasn't, and IE was the one that implemented
> the spec incorrectly to start with, the decision there was to stick
> with the already-specced stuff, and IE changed to accommodate it.
> I don't know why you think there wasn't massive backlash against
> Microsoft for their incompatible changes, either. IE7 adoption was
> very slow, and one reason I've often seen given is lack of
> compatibility with intranet sites. You might want to read this post
> by Chris Wilson:
That's a really interesting post. As you know, after that was written
the IE team came to a compromise where IE would be standard by default
but provide a compatibility view to work with broken pages. I'm not
saying that every browser should implement a compatibility view, but
IE does seem to be the browser that's affected the most by this and
fakepath would fit very well with its compatibility view's goals.
On Mon, Sep 14, 2009 at 5:39 AM, Eduard Pascual <herenvardo at gmail.com> wrote:
> Considering that
> "pre-HTML5" browsers (like IE 6 and 7 or FF2) are going to stay there
> for a while, approaches like substr(12) or any other means of just
> trimming "C:\fakepath\" just won't work. Last indexof("\\") would
> break on any browser that doesn't include path at all (that's what
> fakepath is addressing, after all)
Actually, lastIndexOf can work quite well, as long as there are no
backslashes in the file name. Both
return "upload.txt" because lastIndexOf returns -1 if nothing was
found. The problem appears to be web pages adding additional "checks"
that don't always hold up.
On Sun, Sep 13, 2009 at 8:01 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Mon, Sep 14, 2009 at 1:12 PM, Ian Hickson <ian at hixie.ch> wrote:
>> Here are some bug reports that I believe are caused by this issue:
>> Based on this my guess is just that people haven't filed this bug because
>> they haven't thought of it as a browser bug (notice how nobody in those
>> threads even mentions the browser).
> You may be right, although the first thread mentions browsers. I don't know
> if that's enough to explain why I can only find two Mozilla bugs related to
Thanks for the data. So, the list of known affected devices is:
On Sun, Sep 13, 2009 at 3:50 PM, Ian Hickson <ian at hixie.ch> wrote:
> There are basically only two arguments:
> Aesthetics: Having the fake path is ugly and poor language design.
> Compatibility: Having it increases compatibility with deployed content.
> In HTML5's development, compatibility is a stronger argument than
> aesthetics. Therefore the path stays.
Then for however long we use HTML, we will always remember that we
have to work around fakepath because someone decided that
compatibility with a handful of badly designed pages in 2009 was more
important than having good design in 2090.
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg