Re: [whatwg] Fakepath revisited
On Mon, 14 Sep 2009, Eduard Pascual wrote: Now, maybe stepping on a side topic, I'd like to bring back a separate request: I think, if fakepath is to be included on the spec, that content authors shouldn't be left at their own risks. 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), as well as any browser that runs on Unix-like systems and provides full path (not sure if there is any current browser on this category). Is there any way we content authors can reliably retrieve a filename from scripts, other than special-casing several versions of each browser in existence? More specifically, would .files[0] work on those pre-HTML5 browsers? If it does, this is a non-issue. However, if it doesn't, I'd like to suggest adding an algorythm on the spec to deal with this task. Just like the spec offers algorythms for browsers to deal with non-compliant existing content, on cases like this it would be equally valuable to have algorythms for content to deal with non-compliant existing browsers. files[0] won't work in most legacy browsers. I've added an example of how to grab the filename. On Mon, 14 Sep 2009, Alex Henrie wrote: 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. If only this was the only thing for which we could say that. :-( -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fakepath revisited
On Mon, Sep 14, 2009 at 3:12 AM, Ian Hickson i...@hixie.ch wrote: Here are some bug reports that I believe are caused by this issue: http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routersmessage.id=135649 http://www.dslreports.com/forum/r21297706-Re-Tweak-Test-Need-help-tweaking http://www.rx8club.com/showpost.php?s=42aad353530dfa4add91a1f2a67b2978p=2822806postcount=3269 This is factual data, thank you. http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx This, on contrast, is not. It's an interesting read, and a good rationale, but it doesn't show any real-world example of what is causing the issue. From that page (or from all Microsoft's posts, mails, etc I have seen around the topic), the only proof they give about the problem actually exists was their own word. I won't say whether Microsoft's word on something should be trusted (there are enough MS evangelists and MS haters out there to guarantee perpetual disagreement on this), but just wanted to point out that such word is not the same as factual data. I would love more data. Although I'd also love it, I don't really need it. The few links you posted, quoted above, are enough to show that this is a real issue. That's all I was asking. Thanks again. Please, let me clarify that my examples of filenames containing backslashes were purely theoretical. I have no factual data to back them, and I don't really need it. Without actual examples on the need of fakepath, they were at the same position as the arguments standing in favor of fakepath. Their only goal was to encourage bringing specific data about the need for fakepath, and it has been achieved. Now, maybe stepping on a side topic, I'd like to bring back a separate request: I think, if fakepath is to be included on the spec, that content authors shouldn't be left at their own risks. 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), as well as any browser that runs on Unix-like systems and provides full path (not sure if there is any current browser on this category). Is there any way we content authors can reliably retrieve a filename from scripts, other than special-casing several versions of each browser in existence? More specifically, would .files[0] work on those pre-HTML5 browsers? If it does, this is a non-issue. However, if it doesn't, I'd like to suggest adding an algorythm on the spec to deal with this task. Just like the spec offers algorythms for browsers to deal with non-compliant existing content, on cases like this it would be equally valuable to have algorythms for content to deal with non-compliant existing browsers. I am Ok with working around content's brokenness when fixing the content is not an option; but that shouldn't be done at the expense of good content and careful authors. Regards, Eduard Pascual
Re: [whatwg] Fakepath revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/13/09 5:58 PM, Maciej Stachowiak wrote: In this case, I'd like to see a list of specific routers, sites etc that triggered the implementation of fakepath in Opera and IE. I'd like to crosscheck with our Bugzilla to understand why we haven't felt the need to do this in Firefox. For Safari/WebKit, we haven't seen specific bug reports that are clearly identifiable as this issue. But I'm willing to believe it is real. We Two bugs reports which we *know* we triggered when we removed the full path: https://bugzilla.mozilla.org/show_bug.cgi?id=436116 (BlackBoard) https://bugzilla.mozilla.org/show_bug.cgi?id=417715 (eBay) In both these cases changes in the website fixed the problem. - --BDS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKrk1uSSwGp5sTYNkRAo7VAKCE9m6VsOun/ul9Evj99ZaSq13XbwCeMIt/ jGLXrMHxEtoYfjqHruPqPwo= =j5fi -END PGP SIGNATURE-
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 12:56 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Mon, Sep 7, 2009 at 2:41 PM, Alex Henrie alexhenri...@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: http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html 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 herenva...@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 upload.txt.substr(upload.txt.lastIndexOf(\\)+1) and C:\\fakepath\\upload.txt.substr(C:\\fakepath\\upload.txt.lastIndexOf(\\)+1) 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 rob...@ocallahan.org wrote: On Mon, Sep 14, 2009 at 1:12 PM, Ian Hickson i...@hixie.ch wrote: Here are some bug reports that I believe are caused by this issue: http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routersmessage.id=135649 http://www.dslreports.com/forum/r21297706-Re-Tweak-Test-Need-help-tweaking http://www.rx8club.com/showpost.php?s=42aad353530dfa4add91a1f2a67b2978p=2822806postcount=3269 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 this. https://bugzilla.mozilla.org/show_bug.cgi?id=446167 https://bugzilla.mozilla.org/show_bug.cgi?id=505348 Thanks for the data. So, the list of known affected devices is: Linksys WRT110 Netgear WGR614v9 D-Link DSL-2640B On Sun, Sep 13, 2009 at 3:50 PM, Ian Hickson i...@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. `._.-(,_..'--(,_..'`-.;.' Indeed. -Alex
Re: [whatwg] Fakepath revisited
On Mon, Sep 14, 2009 at 3:17 PM, Alex Henrie alexhenri...@gmail.com wrote: 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. Yes. It's a pain, but that's life. Bad design decisions by implementors early in the web's life -- inventing new features without adequate planning and care to get a quick leg up on the competition -- have condemned it to be a mess forever. Unreasonable legacy baggage is hardly unique to the web, of course. We're currently communicating in a format that only allows 7-bit transmission over the wire and has no concept of authentication. One of the biggest contributing factors to the ubiquity of malware today is arguably the fact that the desktop system that won out happened to have been originally designed for use on non-networked single-user machines instead of networked multi-user machines. And so on. In an ideal world, we'd throw out HTML and replace it with something sane. We'd also throw out e-mail and replace it with something sane, and throw out all legacy Windows APIs and replace them with something better suited to today's world. And so on. Unfortunately, we do not live in an ideal world. Anyone who tries throwing out those things will just be ignored, because . . . their brilliant new product doesn't work with everything that already exists. Instead we have to hack on ugly nonsense so that the existing stuff continues to work, however stupid or wrong it may be in retrospect -- like Vista's elaborate efforts to trick legacy programs into thinking they're running as root and can write to C:\Program Files\. Or like base64 and SPF in e-mail. Or like C:\fakepath in HTML5. It would be nice if we didn't have to do this kind of thing. But we do.
Re: [whatwg] Fakepath revisited
On Mon, 14 Sep 2009 10:04:30 -0400, Benjamin Smedberg benja...@smedbergs.us wrote: Two bugs reports which we *know* we triggered when we removed the full path: https://bugzilla.mozilla.org/show_bug.cgi?id=436116 (BlackBoard) https://bugzilla.mozilla.org/show_bug.cgi?id=417715 (eBay) In both these cases changes in the website fixed the problem. Here are two that used to choke when they didn't get the full path. The first page is gone now. The second no longer seems to have the problem, but you can check the source to see some of the checks they make on the value to make sure. http://www.kingkrill.com/php/recipecontest.php http://www.freedfm.com/ -- Michael
Re: [whatwg] Fakepath revisited
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fakepath revisited
On Sep 7, 2009, at 3:53 PM, Robert O'Callahan wrote: On Tue, Sep 8, 2009 at 3:56 AM, Aryeh Gregor Simetrical +...@gmail.com wrote: Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. We can sacrifice *some* compatibility for *some* long-term goals. We do it all the time, even Microsoft. It's all about tradeoffs. In this case, I'd like to see a list of specific routers, sites etc that triggered the implementation of fakepath in Opera and IE. I'd like to crosscheck with our Bugzilla to understand why we haven't felt the need to do this in Firefox. For Safari/WebKit, we haven't seen specific bug reports that are clearly identifiable as this issue. But I'm willing to believe it is real. We sporadically get bug reports about specific routers, but we rarely have the resources to acquire the particular hardware and investigate the issue. Thus, the problems tend to remain unresolved unless it's a very popular piece of hardware and the bug keeps it from working at all. For what it's worth, I think fakepath is kind of gross, but far from the grossest compatibility hack in the Web platform. And in this case, input.files will give a cleaner and more capable API. So I'm ok with the hackery here. Regards, Maciej
Re: [whatwg] Fakepath revisited
On Sun, Sep 13, 2009 at 11:50 PM, Ian Hickson i...@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. I already posted an example showing how fakepath can easily break compatibility with well-written sites. I explicitly asked for counter-arguments to it and none has been provided, but the argument doesn't seem to be taken in consideration at all. Hence I'm wondering how the compatibility arguments are treated here. Is compatibility with an unknown-size niche of clearly bad-designed sites more important than with potentially thousands of well-designed ones? Opera has claimed that they are keeping fakepath just because Microsoft claims some sites need it. Microsoft hasn't revealed the list of such broken sites, nor even a figure about how many sites are involved. However this group is willing to bend a standard based only on the claims from a single vendor... not to mention that this is precissely the vendor that less commitement has shown over the last decade on the area of web standards implementation. In my opinion, this is exactly the same as spitting on the face of everyone who has ever put an effort on building an interoperable website. If there is a real compatibility issue, a claim that is currently held only by Microsoft, bring some factual data about it. Otherwise, including fakepath is equivalent to stupidifying the language (probably at the expense of breaking currently good sites), based only on a single vendor stating its unwillingness to implement the non-stupid alternative. Regards, Eduard Pascual
Re: [whatwg] Fakepath revisited
On Sun, Sep 13, 2009 at 6:23 PM, Eduard Pascual herenva...@gmail.com wrote: I already posted an example showing how fakepath can easily break compatibility with well-written sites. I explicitly asked for counter-arguments to it and none has been provided, but the argument doesn't seem to be taken in consideration at all. I don't understand what the incompatibility would be. You argued that it would be a pain for some existing sites, but not how it would break any existing sites. Existing sites already need to strip off leading paths, since all browsers except very recent ones provide leading paths in this DOM attribute. So what *existing* site could possibly break here? You seem to be saying something about filenames containing \, but since all existing sites must already strip out the path, those would already break. (Not that anyone uses files with such insane names in real life. Try running find / -name '*\*' on your local Unix system and tell me if it returns anything. I get nothing on my Linux desktop.) Hence I'm wondering how the compatibility arguments are treated here. Is compatibility with an unknown-size niche of clearly bad-designed sites more important than with potentially thousands of well-designed ones? No, if you can demonstrate an actual compatibility problem in practice, rather than a hypothetical issue that doesn't even appear to be compatibility-related (AFAICT). Opera has claimed that they are keeping fakepath just because Microsoft claims some sites need it. IIRC, Opera has some direct evidence that certain pages break. I don't think they're just taking Microsoft's word for it. However this group is willing to bend a standard based only on the claims from a single vendor... not to mention that this is precissely the vendor that less commitement has shown over the last decade on the area of web standards implementation. HTML 5 seeks to be a specification that all major vendors are willing to implement. Microsoft is the most important here, since it's the biggest vendor. Its actions and attitudes toward standards are irrelevant -- we're trying to build a useful standard, not wage a war.
Re: [whatwg] Fakepath revisited
On Mon, Sep 14, 2009 at 9:50 AM, Ian Hickson i...@hixie.ch wrote: In HTML5's development, compatibility is a stronger argument than aesthetics. Therefore the path stays. This is a very minor issue and I'm fine with adding this to Gecko, personally, except that first I really would like to see some specific examples of sites that need this. There remains the faint possibility that these sites already work in Firefox for some reason, and I'd like to understand why, or if they don't, then I'd like to understand why we haven't felt the need for this hack. Plus I think that in the spirit of making decisions based on data, we should expect actual data to be presented if possible, especially if requested, and here it seems like it should be easy, yet I asked for specific examples earlier and none have been forthcoming. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Fakepath revisited
On Mon, 14 Sep 2009, Eduard Pascual wrote: I already posted an example showing how fakepath can easily break compatibility with well-written sites. I explicitly asked for counter-arguments to it and none has been provided, but the argument doesn't seem to be taken in consideration at all. Hence I'm wondering how the compatibility arguments are treated here. Is compatibility with an unknown-size niche of clearly bad-designed sites more important than with potentially thousands of well-designed ones? Dropping part of the file name in the rare case of a filename that contains a backslash seems like less of an issue that failing to accept the upload at all. On Mon, 14 Sep 2009, Robert O'Callahan wrote: This is a very minor issue and I'm fine with adding this to Gecko, personally, except that first I really would like to see some specific examples of sites that need this. There remains the faint possibility that these sites already work in Firefox for some reason, and I'd like to understand why, or if they don't, then I'd like to understand why we haven't felt the need for this hack. Plus I think that in the spirit of making decisions based on data, we should expect actual data to be presented if possible, especially if requested, and here it seems like it should be easy, yet I asked for specific examples earlier and none have been forthcoming. Here are some bug reports that I believe are caused by this issue: http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routersmessage.id=135649 http://www.dslreports.com/forum/r21297706-Re-Tweak-Test-Need-help-tweaking http://www.rx8club.com/showpost.php?s=42aad353530dfa4add91a1f2a67b2978p=2822806postcount=3269 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). One of the sites I know aout that had this bug in Firefox and Safari was: https://www.freedfm.com/ ...but it has now been fixed (search for 'strFileName.indexOf(\\)' in the source -- it was commented out last year). Microsoft, in their blog post, refer to a number of other sites they tested, though they don't name them: http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx I would love more data. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fakepath revisited
On Mon, Sep 14, 2009 at 1:12 PM, Ian Hickson i...@hixie.ch wrote: Here are some bug reports that I believe are caused by this issue: http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routersmessage.id=135649 http://www.dslreports.com/forum/r21297706-Re-Tweak-Test-Need-help-tweaking http://www.rx8club.com/showpost.php?s=42aad353530dfa4add91a1f2a67b2978p=2822806postcount=3269 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 this. https://bugzilla.mozilla.org/show_bug.cgi?id=446167 https://bugzilla.mozilla.org/show_bug.cgi?id=505348 I guess we should just suck it up. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Fakepath revisited
On Sun, Sep 13, 2009 at 10:01 PM, Robert O'Callahan rob...@ocallahan.org wrote: I guess we should just suck it up. Cant we wait some more time before we change current behavior in Mozilla. I believe once IE8 is popular enough the firmware people will make change in their code and they will also test it in Firefox. I see many web site already started changing their code to match Firefox behavior.
Re: [whatwg] Fakepath revisited
On Sun, Sep 13, 2009 at 10:25 PM, Biju bijumaill...@gmail.com wrote: On Sun, Sep 13, 2009 at 10:01 PM, Robert O'Callahan rob...@ocallahan.org wrote: I guess we should just suck it up. Cant we wait some more time before we change current behavior in Mozilla. Also it wont solve all the path problem with Firefox. As many intranet sites expect to get user chosen network path. Which I believe IE8 is still providing, and Firefox is not.
Re: [whatwg] Fakepath revisited
On Mon, Sep 14, 2009 at 5:25 AM, Bijubijumaill...@gmail.com wrote: Cant we wait some more time before we change current behavior in Mozilla. I believe once IE8 is popular enough the firmware people will make change in their code and they will also test it in Firefox. Err, you're missing a key point: Microsoft *GAVE UP*. They're including fakepath because they tried removing it and found they couldn't. And the rest of us are willing to add this support for compat.
Re: [whatwg] Fakepath revisited
On Mon, Sep 14, 2009 at 5:31 AM, Bijubijumaill...@gmail.com wrote: Also it wont solve all the path problem with Firefox. As many intranet sites expect to get user chosen network path. Which I believe IE8 is still providing, and Firefox is not. OK, for this I'd like to have real data. Can you point to engineers from real companies willing to step forward and acknowledge that their sites really expect this behavior? MS has not indicated that this was a problem, and since they haven't, I think it's a reasonably safe assumption that this is not the case. File uploads can come from anywhere, and a web application that requires users to upload from a network path instead of a mapped network volume is so incredibly broken that I'm perfectly willing to let it break. There's a difference between hardware devices which will get limited updates if they can (the lack of fakepath means that they can't from some web incompatible browsers) and living CMS systems which will eventually have to work with IE8. The latter will eventually evolve to let people enter network paths by hand, maybe they'll even get cute and use a server credential to try to retrieve and preview the data specified by the user.
Re: [whatwg] Fakepath revisited
On Tue, 08 Sep 2009 00:53:17 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Sep 8, 2009 at 3:56 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. We can sacrifice *some* compatibility for *some* long-term goals. We do it all the time, even Microsoft. It's all about tradeoffs. In this case, I'd like to see a list of specific routers, sites etc that triggered the implementation of fakepath in Opera and IE. I'd like to crosscheck with our Bugzilla to understand why we haven't felt the need to do this in Firefox. We actually had pathless for a while and changed it to fakepath for compatibility with some sites that worked better in Internet Explorer and Firefox. Studying the sites we changed it for it seems to be no longer necessary for those, but changing it to pathless again does not seem worth it given that the IE Team apparently found more and that going forward authors should use input.files to be able to deal with multiple files as well. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fakepath revisited
On Fri, 04 Sep 2009 20:07:19 +0200, Alex Henrie alexhenri...@gmail.com wrote: implementing fakepath would require teaching every web developer to use foo.value.substr(12) or foo.files[0] instead of foo.value. Confusing and unintuitive behavior like this makes HTML more difficult to learn, and this added cost of learning should not be ignored either. IE7 (and IE8 in quirks and compat view modes) and earlier versions of Firefox (and earlier versions of WebKit?) exposed the full path, so Web developers already had to hack out a substring to get the file name. -- Simon Pieters Opera Software
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 12:35 AM, Simon Pieterssim...@opera.com wrote: On Fri, 04 Sep 2009 20:07:19 +0200, Alex Henrie alexhenri...@gmail.com wrote: implementing fakepath would require teaching every web developer to use foo.value.substr(12) or foo.files[0] instead of foo.value. Confusing and unintuitive behavior like this makes HTML more difficult to learn, and this added cost of learning should not be ignored either. IE7 (and IE8 in quirks and compat view modes) and earlier versions of Firefox (and earlier versions of WebKit?) exposed the full path, so Web developers already had to hack out a substring to get the file name. Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Fakepath will actually encourage developers to fall into this trap, which just goes to show that it is not a perfect solution. On Sat, Sep 5, 2009 at 7:46 PM, timelesstimel...@gmail.com wrote: On Sat, Sep 5, 2009 at 12:27 PM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Also, we could settle this. A sizable non-exhaustive list of problematic sites could end this discussion soon. Just sayin'. Let's get biblical. Precisely how sizable is sufficient for us not to destroy Sodom ? The fact is that we want users to be able to upgrade routers. Routers that users don't upgrade to later firmware are security nightmares. Firefox recently announced a feature to encourage users to upgrade Flash. Saying that we don't want our users to upgrade their routers would sound disingenuous right about now. And routers are interesting things, there have been some fairly cool attacks on them using browsers (kinda like Flash). From what I've seen, home router firmwares are rarely updated even though they should be. Also, I suspect that if the manufacturers of the affected routers aren't interested in releasing updates to make them work in non-fakepath browsers like Firefox, they may not be interested in releasing updates for them at all. A specific list of affected routers would go a long way to help us determine the frequency and severity of their vulnerabilities, and whether firmware updates are available to resolve them. Incidentally, it would be really cool if the routers automatically downloaded and installed their own updates. Automatic updates would provide much more consistent security than asking end users to regularly check for and install updates on their own. Sometimes it'd be nice if people were willing to trust browser vendors. Sometimes we aren't going to be able to release all of our research. But really, if there's a business case strong enough to prevent us from doing something we've announced we intended to do, and that something would have reduced our code complexity, you can be sure that it meant there was a reason. In all likelihood, the engineers hate the fact that they're doing it, but there's a reason, and it had to be pretty darn good for engineering to cave. (Speaking as an engineer who does not enjoy caving, but who is glad to be able to ship a product once in a while.) Essentially, you are choosing to trade long-term good design for short-term compatibility. It's the quick and easy path, and it's not a good idea. It would be like writing specifications for the IE7 (or IE6) rendering engine and then declaring them to be the new standard. Sure, sites that were only tested in IE7 would continue to work perfectly, and you could throw in some cool new features too, but it wouldn't fix the bugs that make IE7 hard to work with in the first place. IE8 tries to offer the best of both worlds by having a Compatibility View button--why can't fakepath just be another part of this one-click workaround? I know that I don't get to write the standard; the decision is ultimately not up to me. If the major browser vendors agree to standardize on fakepath then myself and other web developers will just have to live with it. All I can do is share my perspective and hope it makes a difference. -Alex
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 3:24 AM, Alex Henriealexhenri...@gmail.com wrote: Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Fakepath will actually encourage developers to fall into this trap, which just goes to show that it is not a perfect solution. Well, no, not really. If they're hacking out a substring, they'll *hack out a substring*, since the prefix is of a known fixed length. Just lop off the first 12 characters, and whatever's left is your filename. Splitting on \ is just plain silly in this instance. ~TJ
Re: [whatwg] Fakepath revisited
Am Montag, den 07.09.2009, 10:10 -0500 schrieb Tab Atkins Jr.: Well, no, not really. If they're hacking out a substring, they'll *hack out a substring*, since the prefix is of a known fixed length. Just lop off the first 12 characters, and whatever's left is your filename. Splitting on \ is just plain silly in this instance. As the fakepath problem occured precisely because Web Developers Are Stupid, maybe an easy way out would be to spec a method to get the real value (or write it boldly into the spec annotations) ? Also, I have all my important files in C:\fakepath\ you insensitive clod ! ;) Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Fakepath revisited
On Mon, 07 Sep 2009 17:38:39 +0200, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: As the fakepath problem occured precisely because Web Developers Are Stupid, maybe an easy way out would be to spec a method to get the real value (or write it boldly into the spec annotations) ? File.name -- http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 4:24 AM, Alex Henrie alexhenri...@gmail.com wrote: Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Unix also allows filenames to contain newlines, unprintable characters, trailing whitespace, and strings of bytes that don't represent any characters at all in common encodings. Not to mention that file extensions are often omitted. If web authors aren't prepared to deal with all those, then getting confused by backslashes isn't going to be a huge additional problem, I imagine. At least in your case the script will be left with a valid Windows filename, even if it's not the same one as on the user's filesystem. Also, I suspect that if the manufacturers of the affected routers aren't interested in releasing updates to make them work in non-fakepath browsers like Firefox, they may not be interested in releasing updates for them at all. IIRC, the problem is that you can't upload the new firmware to the router at all, so the manufacturer can't release an update to fix it. It can only make sure it's fixed in new models. Essentially, you are choosing to trade long-term good design for short-term compatibility. Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. Any standard that demands incompatibility with existing content will be ignored by implementors, as XHTML was, and thus useless to authors. That's the fact of the matter, whether we like it or not. New APIs can be introduced, but old ones can't be changed in incompatible ways.
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 9:41 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 07 Sep 2009 17:38:39 +0200, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: As the fakepath problem occured precisely because Web Developers Are Stupid, maybe an easy way out would be to spec a method to get the real value (or write it boldly into the spec annotations) ? File.name -- http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Think about how this will affect web development 20 years from now. Inexperienced web developers will try to use the more intuitive property foo.value, not realizing that they should use foo.files[0].name instead. They may not know that foo.files[0].name exists, or they may assume that it behaves the same as foo.value. Some of those developers will think that the compatibility problems that led to fakepath still exist, and will use foo.value.substr(foo.value.lastIndexOf(\\) + 1) despite the potential problems if the filename actually contains a backslash. In all, HTML will be harder to learn and bad designs will continue to be made. Actually, I just realized one reason why Firefox's omission of fakepath hasn't caused widespread compatibility problems. Think about it: if there are no backslashes in the file name, then foo.value.substr(foo.value.lastIndexOf(\\) + 1) will work perfectly happily with both C:\fakepath\upload.txt and upload.txt, because lastIndexOf will return -1 if no backslashes are found. Clearly, the affected web pages are doing a bit more than just trying to extract the file name or extension. Can you please share the list of web pages you found that are affected by this problem, so that we can see exactly what they're trying to do? On Mon, Sep 7, 2009 at 9:56 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Sep 7, 2009 at 4:24 AM, Alex Henrie alexhenri...@gmail.com wrote: Also, I suspect that if the manufacturers of the affected routers aren't interested in releasing updates to make them work in non-fakepath browsers like Firefox, they may not be interested in releasing updates for them at all. IIRC, the problem is that you can't upload the new firmware to the router at all, so the manufacturer can't release an update to fix it. It can only make sure it's fixed in new models. You know, if the manufacturers cared they could release a program that updated the router without using the broken web interface. Essentially, you are choosing to trade long-term good design for short-term compatibility. Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. Any standard that demands incompatibility with existing content will be ignored by implementors, as XHTML was, and thus useless to authors. That's the fact of the matter, whether we like it or not. New APIs can be introduced, but old ones can't be changed in incompatible ways. 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. I'm asking the same thing: take good behavior from Firefox, Safari, and Chrome and get it working in IE and Opera too. It's not impossible, and it's well worth it in the long term. -Alex
Re: [whatwg] Fakepath revisited
Oops... the following was meant to be a reply to all but I hit reply instead; so here it goes a copy for the list: On Mon, Sep 7, 2009 at 8:43 PM, Eduard Pascualherenva...@gmail.com wrote: On Mon, Sep 7, 2009 at 5:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 7, 2009 at 3:24 AM, Alex Henriealexhenri...@gmail.com wrote: Expecting developers to hack out a substring at all will only lead to more bad designs. For example, Linux and Mac OS allow filenames to contain backslashes. So if the filename was up\load.txt then foo.value would be C:\fakepath\up\load.txt which could easily be mistaken for load.txt. Fakepath will actually encourage developers to fall into this trap, which just goes to show that it is not a perfect solution. Well, no, not really. If they're hacking out a substring, they'll *hack out a substring*, since the prefix is of a known fixed length. Just lop off the first 12 characters, and whatever's left is your filename. Splitting on \ is just plain silly in this instance. ~TJ That wouldn't work. There is an important ammount of browsers that include the full path in the value. So web authors would need to know *a lot* of guesswork if they are to hack a substring from such value. They have to figure out whether they'll be getting a plain file name, a file name with a path, or a fakepath, and treat each case separately. If a site tries to just substring(12), it will break on any non-HTML5 browser (except on the corner case where the value contains a full path and it is exactly 12 characters long). If they try to split on \, they will break when a file on a non-Windows system contains that character. To put things on a more obvious shape, imagine the following scenarios: A file named up\load.txt (on a non-Windows OS) is given from an HTML5 browser. We get a value=C:\fakepath\up\load.txt. A file named load.txt, and located at C:\fakepath\up\ from a browser that includes full path. We get a value=C:\fakepath\up\load.txt. Two different file-names end up yielding the same value string. So, basically, it is impossible to reliably recover the name of the file from only the value string: there will be ambiguous cases. While the examples above may seem corner cases, they are just intended to show off the ambiguity issue. Ok, so some (horribly-designed) sites break without fakepath. Since the HTML5 spec likes so much to include explicit algorythms, is there any reliably algorythm that web authors can use to recover the actual filename? (Without having to assume that everybody switches immediatelly to HTML5-compliant browsers, of course.) If there isn't, then every other site (including all the decently-designed ones) that need/use the filename would break. What would be the point to keep compatibility with some bad-sites if it would break many good sites? Regards, Eduard Pascual
Re: [whatwg] Fakepath revisited
On Mon, Sep 7, 2009 at 2:41 PM, Alex Henrie alexhenri...@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: http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html One quote that stood out for me: IE7 did cause widespread disruption, as a case in point. I championed making those widespread changes to improve our standards compliance. In all seriousness, I've managed to hang on to my job, but sometimes I think only just. I cannot go to my team and say 'hey, we're gonna break the web again (and again and again), but it's okay because it's for a good cause.' The world doesn't work that way. I wouldn't be responsibly doing my job - that one where half a billion web users rely on my team to not hose compatibility with their banking web site, even if their bank doesn't know how to properly use CSS 'float'. In other words, Microsoft realizes it messed up with IE7 and wants to avoid a repeat experience if at all possible. Notice what elaborate compatibility measures they've added to IE8, making it behave almost exactly like IE7 in many cases. I'm asking the same thing: take good behavior from Firefox, Safari, and Chrome and get it working in IE and Opera too. It's not impossible, and it's well worth it in the long term. That's a fine position, but in the end, if the implementors won't implement it, it's not going to go anywhere.
Re: [whatwg] Fakepath revisited
On Tue, Sep 8, 2009 at 3:56 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: Browser vendors cannot sacrifice compatibility for long-term goals, because their users will rebel. We can sacrifice *some* compatibility for *some* long-term goals. We do it all the time, even Microsoft. It's all about tradeoffs. In this case, I'd like to see a list of specific routers, sites etc that triggered the implementation of fakepath in Opera and IE. I'd like to crosscheck with our Bugzilla to understand why we haven't felt the need to do this in Firefox. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Fakepath revisited
On Sep 2, 2009, at 11:07 PM, Alex Henrie wrote: HTML5 would declare IE and Opera's fakepath behavior to be standard and Firefox, Safari, and Chrome's behavior to be nonstandard. HTML5 assumes that Mozilla, Apple, and Google are willing to change their browsers' behavior to match IE and Opera. However, as far as I can tell, none of these companies plan to do so. Further, HTML5 expects us web developers to work around the fakepath behavior for the next 20+ years in the name of compatibility. As far as I'm aware, Apple does not have a problem with the fakepath requirement. Regards, Maciej
Re: [whatwg] Fakepath revisited
Am Freitag, den 04.09.2009, 12:07 -0600 schrieb Alex Henrie: On Thu, Sep 3, 2009 at 4:40 PM, Simon Pieterssim...@opera.com wrote: It should be noted that both IE and Opera first tried to use just the filename, but independently found that it was incompatible with existing content. And Firefox, Safari, and Chrome independently didn't find enough compatibility issues to worry about. Have the MSIE and Opera teams shared their data with the public about what products are defective ? Otherwise discussing this aspect seems moot, because then we have Look, we found, well, stuff. Its common and causes problems, believe us.. Not to accuse anyone of anything -- disclosing such information would just be professional and in the interest of a more rational debate --, but I take statements from MS about compatibility with more than a grain of salt. Also, we could settle this. A sizable non-exhaustive list of problematic sites could end this discussion soon. Just sayin'. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Fakepath revisited
On Sat, Sep 5, 2009 at 12:27 PM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Also, we could settle this. A sizable non-exhaustive list of problematic sites could end this discussion soon. Just sayin'. Let's get biblical. Precisely how sizable is sufficient for us not to destroy Sodom ? The fact is that we want users to be able to upgrade routers. Routers that users don't upgrade to later firmware are security nightmares. Firefox recently announced a feature to encourage users to upgrade Flash. Saying that we don't want our users to upgrade their routers would sound disingenuous right about now. And routers are interesting things, there have been some fairly cool attacks on them using browsers (kinda like Flash). Sometimes it'd be nice if people were willing to trust browser vendors. Sometimes we aren't going to be able to release all of our research. But really, if there's a business case strong enough to prevent us from doing something we've announced we intended to do, and that something would have reduced our code complexity, you can be sure that it meant there was a reason. In all likelihood, the engineers hate the fact that they're doing it, but there's a reason, and it had to be pretty darn good for engineering to cave. (Speaking as an engineer who does not enjoy caving, but who is glad to be able to ship a product once in a while.)
Re: [whatwg] Fakepath revisited
On Thu, Sep 3, 2009 at 4:40 PM, Simon Pieterssim...@opera.com wrote: On Thu, 03 Sep 2009 18:23:37 +0200, Alex Henrie alexhenri...@gmail.com wrote: On Thu, Sep 3, 2009 at 1:29 AM, Smylerssmyl...@stripey.com wrote: Like other compatibility mode behavior, implementation would be voluntary and not governed by the W3C. What other compatibility mode behavior? IE has a huge Compatibility View and lots of additional settings available. Firefox also has some about:config options available to tweak behavior, and Opera has their site blacklist. Our experience is that one behavior everywhere is preferable (it's more predictable, it's easier to test, it's less risk of introducing bugs, etc), and we try hard to have one behavior for all rendering modes for all sites and for both HTML and XML. We generally only have differences when we really have to for compatibility or for spec compliance. Whether or not you implement hacks for poorly designed router firmwares as you have done for other sites is entirely up to you. In general, users don't use bookmarklets or other tools to work around poorly designed pages. In general, users don't try disabling javascript. And in general, users don't ever try to update their router firmware in the first place. Those that do are likely smart enough to use Google to figure out how to work around the problem. It should be noted that both IE and Opera first tried to use just the filename, but independently found that it was incompatible with existing content. And Firefox, Safari, and Chrome independently didn't find enough compatibility issues to worry about. Ian wants to standardize on the stupider behavior and expects the remaining browsers to implement it. That's going to be a problem. Expecting Opera and IE to switch back to the incompatible behavior is not less of a problem. In addition to changing Firefox, Safari, and Chrome, implementing fakepath would require teaching every web developer to use foo.value.substr(12) or foo.files[0] instead of foo.value. Confusing and unintuitive behavior like this makes HTML more difficult to learn, and this added cost of learning should not be ignored either. -Alex
Re: [whatwg] Fakepath revisited
On Fri, 04 Sep 2009 20:07:19 +0200, Alex Henrie alexhenri...@gmail.com wrote: Whether or not you implement hacks for poorly designed router firmwares as you have done for other sites is entirely up to you. IE and Opera recognize that some web pages, in particular someold router firmwares, are poorly designed. These firmwares were designed to apply superfluous validation to foo.value, only allowing new firmware to be uploaded from Windows, and only in an old web browser which provides the full path to the file. I assume this claim comes from URL:http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx which does not actually say what you are implying. The reason behind browsers no longer revealing the real path is given here: For IE8 Beta-1, we closed off the information-disclosure problem whereby JavaScript can read the .value attribute of a file upload control and determine the full local pathname, which might include information like the user’s name, profile directory, etc. However, here is what the MSIE team actually says what they discovered when closing of that information loophole: Over the last few months, we’ve run into a significant number of sites (e.g. education products, several movie sharing sites, etc) and devices (e.g. popular home routers) that this security improvement breaks, because the sites use JavaScript to attempt to parse the filename (e.g. to determine its extension). Opera has independently arrived at a similar conclusion: That omitting a fake path causes web content way beyond what you say to break. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [whatwg] Fakepath revisited
Alex Henrie writes: A better solution exists: drop the fakepath requirement. Browsers that desire extra compatibility can add fakepath to their compatibility modes as they choose. Browsers have 'extra' compatibility is one of the things which currently causes the _most_ grief for many web developers: writing something to the spec is nowhere near sufficient to have confidence of it working as intended in all browsers. If one major browser implements non-standard behaviour for compatibility with existing content, it would have an advantage with users over other browsers -- those other browsers would likely want to implement it, to avoid losing market share. But browsers unilaterally implementing 'extra compatibility' means other browsers wanting to be similarly compatibile have to reverse engineer the first browser -- a time-consuming and brittle process, which in practice often leads to some edge cases where the behaviour is not the same. Also, it makes it hard for a new browser developer to enter the market, since being compatibile with real-world content involves implementing this undocumened behaviour. Like other compatibility mode behavior, implementation would be voluntary and not governed by the W3C. What other compatibility mode behavior? The bottom line is that no web developer wants to have a confusing, unintuitive, and very permanent standard. There is much evidence to suggest that web developers are not happy either with the previous situation of lots of browsers picking their behaviour independently, leading to differences between browsers. Don't punish all web developers for the poor past designs of the few. Unfortunately that's pretty much the modus operandi of HTML 5: standardizing previous stupidities so that we can all share in them. (We've already tried the alternative, and it's worse.) Smylers
Re: [whatwg] Fakepath revisited
Am Donnerstag, den 03.09.2009, 08:29 +0100 schrieb Smylers: Like other compatibility mode behavior, implementation would be voluntary and not governed by the W3C. What other compatibility mode behavior? Maybe he is alluding to the IE local zone ? -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Fakepath revisited
On Thu, Sep 3, 2009 at 1:29 AM, Smylerssmyl...@stripey.com wrote: Like other compatibility mode behavior, implementation would be voluntary and not governed by the W3C. What other compatibility mode behavior? IE has a huge Compatibility View and lots of additional settings available. Firefox also has some about:config options available to tweak behavior, and Opera has their site blacklist. But even without adding such settings to the browser, bookmarklets and other tools can help users work around poorly designed pages. In some cases, just temporarily disabling JavaScript may fix the problem. The bottom line is that no web developer wants to have a confusing, unintuitive, and very permanent standard. There is much evidence to suggest that web developers are not happy either with the previous situation of lots of browsers picking their behaviour independently, leading to differences between browsers. Don't punish all web developers for the poor past designs of the few. Unfortunately that's pretty much the modus operandi of HTML 5: standardizing previous stupidities so that we can all share in them. Yes, we need a standard. Currently there are two competing behaviors, each backed by multiple major browser vendors. Ian wants to standardize on the stupider behavior and expects the remaining browsers to implement it. That's going to be a problem. -Alex
Re: [whatwg] Fakepath revisited
On Thu, Sep 3, 2009 at 12:23 PM, Alex Henriealexhenri...@gmail.com wrote: Yes, we need a standard. Currently there are two competing behaviors, each backed by multiple major browser vendors. Ian wants to standardize on the stupider behavior and expects the remaining browsers to implement it. That's going to be a problem. Why is that expectation any more problematic than expecting IE and Opera to change? How reluctant are each of the major vendors to change their behavior?
Re: [whatwg] Fakepath revisited
On Thu, Sep 3, 2009 at 10:35 AM, Aryeh Gregorsimetrical+...@gmail.com wrote: Why is that expectation any more problematic than expecting IE and Opera to change? How reluctant are each of the major vendors to change their behavior? If the cost of changing the browsers is equal, why pick the worse behavior to standardize on? Why not pick the behavior that makes the most sense? The only reason seems to be to ensure compatibility with software that was designed to work only in certain web browsers, and choosing to make everyone cater to this poorly designed software, which has been disappearing because of its compatibility problems, is a poor design decision.
Re: [whatwg] Fakepath revisited
On Thu, Sep 3, 2009 at 9:29 AM, Smylerssmyl...@stripey.com wrote: If one major browser implements non-standard behaviour for compatibility with existing content, it would have an advantage with users over other browsers -- those other browsers would likely want to implement it, to avoid losing market share. But browsers unilaterally implementing 'extra compatibility' means other browsers wanting to be similarly compatibile have to reverse engineer the first browser -- a time-consuming and brittle process, which in practice often leads to some edge cases where the behaviour is not the same. Currently, all major browsers implement non-standard behaviour for compatibility with existing content, quoting your own words, or quirks modes, to use more common terms. Does the HTML5 spec define what should trigger each quirks mode and how browsers should behave when in those modes? If it did, then the fakepath could be treated as just another quirk, and end of the problem. But as far as I know the spec doesn't dig too deep (correct me if I'm wrong), so there are gonna be thousands or (quite likely) millions of sites that will break unless browsers special-case them as they currently do with their quirks modes. The barrier for entry for new browser vendors is already huge on this area, and stupidifying input type=file with fakepaths will *not* solve this.
Re: [whatwg] Fakepath revisited
On Thu, Sep 3, 2009 at 1:05 PM, Alex Henriealexhenri...@gmail.com wrote: If the cost of changing the browsers is equal Is it? What do the implementors on each side think? Just because the same number of lines would have to be changed doesn't mean the cost is equal, in terms of getting people to agree if nothing else. On Thu, Sep 3, 2009 at 1:24 PM, Eduard Pascualherenva...@gmail.com wrote: Currently, all major browsers implement non-standard behaviour for compatibility with existing content, quoting your own words, or quirks modes, to use more common terms. Well, with the advent of HTML 5, it's now *standard* behavior for compatibility with existing content. :) The overwhelming majority of compat stuff works in standards mode too, though, not just quirks mode. Does the HTML5 spec define what should trigger each quirks mode and how browsers should behave when in those modes? Yes. I don't know if the pages relying on fakepath would trigger quirks mode, though.
Re: [whatwg] Fakepath revisited
On Thu, 03 Sep 2009 18:23:37 +0200, Alex Henrie alexhenri...@gmail.com wrote: On Thu, Sep 3, 2009 at 1:29 AM, Smylerssmyl...@stripey.com wrote: Like other compatibility mode behavior, implementation would be voluntary and not governed by the W3C. What other compatibility mode behavior? IE has a huge Compatibility View and lots of additional settings available. Firefox also has some about:config options available to tweak behavior, and Opera has their site blacklist. Our experience is that one behavior everywhere is preferable (it's more predictable, it's easier to test, it's less risk of introducing bugs, etc), and we try hard to have one behavior for all rendering modes for all sites and for both HTML and XML. We generally only have differences when we really have to for compatibility or for spec compliance. But even without adding such settings to the browser, bookmarklets and other tools can help users work around poorly designed pages. In general, users don't use bookmarklets or other tools to work around poorly designed pages. In some cases, just temporarily disabling JavaScript may fix the problem. In general, users don't try disabling javascript. Unfortunately that's pretty much the modus operandi of HTML 5: standardizing previous stupidities so that we can all share in them. Yes, we need a standard. Currently there are two competing behaviors, each backed by multiple major browser vendors. It should be noted that both IE and Opera first tried to use just the filename, but independently found that it was incompatible with existing content. Ian wants to standardize on the stupider behavior and expects the remaining browsers to implement it. That's going to be a problem. Expecting Opera and IE to switch back to the incompatible behavior is not less of a problem. -- Simon Pieters Opera Software
