W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] Fakepath revisited

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 13 Sep 2009 21:50:55 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0909132139210.14605@hixie.dreamhostps.com>
On Thu, 3 Sep 2009, Alex Henrie wrote:
> 
> I would like to revisit HTML5 section 4.10.4.3, as circumstances have 
> changed since it was last discussed. For those of you not familiar with 
> the issue, section 4.10.4.3 defines the value property of <input 
> type="file"/> elements. This behavior is not currently consistent across 
> all browsers. For example, if I were uploading a file called 
> "upload.txt" into input element "foo", foo.value would be...
> 
> In Firefox 3: "upload.txt"
> In Safari 4: "upload.txt"
> In Chrome 2: "upload.txt"
> In Internet Explorer 8: "C:\fakepath\upload.txt"
> In Opera 10: "C:\fakepath\upload.txt"

I'm no fan of this feature -- I think it's quite silly -- but at the end 
of the day I'd rather have all the browsers do the same silly thing than 
have some do one thing and others do another. At least when they all do 
the same thing, we can be sure that sites will work the same everywhere; 
when they do things differently, who knows what will break.

Right now we're in a position where half the major rendering engines do it 
one way, and the other half do it another way. So we can't pick a side 
based on the most common behaviour.

If Opera or IE decided to not do this, then it would be clear: we'd not 
have the path. However, both have said they don't want to change this.

If WebKit or Firefox were to add this, then it would be clear: we'd have 
the fake path. However, the WebKit team is split, the Firefox team has 
indicated a preference against, and so far the status quo has prevailed in 
both cases.

So we have to look at the pros and cons and make a decision based on what 
the merits of each case are.

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.


> A better solution exists: drop the fakepath requirement. Browsers that 
> desire extra compatibility can add fakepath to their compatibility modes 
> as they choose.

This misses the point. HTML5 is intended to describe what browsers do in 
all modes, not what browsers do when in a special mode called "HTML5 
compliance". There is never the option of saying that browsers can violate 
the spec; that would defeat the whole point of having a spec.


> The bottom line is that no web developer wants to have a confusing, 
> unintuitive, and very permanent standard. Please remove this requirement 
> from HTML5 before it becomes a standard. Don't punish all web developers 
> for the poor past designs of the few.

Convince IE or Opera that they shouldn't do this, and the spec will 
change also.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 13 September 2009 14:50:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC