Re: [whatwg] [html5] r3820 - [e] (0) step/min/max examples.
On Sun, 13 Sep 2009 09:50:29 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2009-09-13 00:50:28 -0700 (Sun, 13 Sep 2009) New Revision: 3820 Modified: index source Log: [e] (0) step/min/max examples. Modified: index === --- index 2009-09-13 07:40:08 UTC (rev 3819) +++ index 2009-09-13 07:50:28 UTC (rev 3820) @@ -35066,7 +35066,25 @@ /div + div class=example + pThe following date control limits input to dates that are before + the start of the 21st century:/p + + prelt;input name=bday type=date max=2000-12-31gt;/pre + + /div s/2000/1999/ -- Simon Pieters Opera Software
Re: [whatwg] [html5] r3820 - [e] (0) step/min/max examples.
On Sun, 13 Sep 2009, Simon Pieters wrote: On Sun, 13 Sep 2009 09:50:29 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2009-09-13 00:50:28 -0700 (Sun, 13 Sep 2009) New Revision: 3820 Modified: index source Log: [e] (0) step/min/max examples. Modified: index === --- index 2009-09-13 07:40:08 UTC (rev 3819) +++ index 2009-09-13 07:50:28 UTC (rev 3820) @@ -35066,7 +35066,25 @@ /div + div class=example + pThe following date control limits input to dates that are before + the start of the 21st century:/p + + prelt;input name=bday type=date max=2000-12-31gt;/pre + + /div s/2000/1999/ Since when? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r3820 - [e] (0) step/min/max examples.
On Sun, 13 Sep 2009 10:52:18 +0200, Ian Hickson i...@hixie.ch wrote: s/2000/1999/ Since when? Oops. I thought the 21st century started 2000, but it seems I was wrong. -- Simon Pieters Opera Software
Re: [whatwg] [html5] r3820 - [e] (0) step/min/max examples.
Quoting Simon Pieters sim...@opera.com: On Sun, 13 Sep 2009 10:52:18 +0200, Ian Hickson i...@hixie.ch wrote: s/2000/1999/ Since when? Oops. I thought the 21st century started 2000, but it seems I was wrong. Since almost everyone uses the zero-based-century convention it would be much less confusing to simply use a different example in which the common and pedantic definitions don't conflict.
Re: [whatwg] object behavior
Boris wrote: I'm not sure where this list of (extension,type) pairs comes from, but it looks like the plug-in provides it somehow (possibly even in that form, looking at http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsPluginsDirUtils.h#53). plugins register tripples: video/quicktime mov,qt,mqv QuickTime Movie mimetype, list-of-extensions, description https://developer.mozilla.org/En/NP_GetMIMEDescription
Re: [whatwg] HTML extension for system idle detection.
On Tue, Sep 8, 2009 at 9:58 PM, Jens Alfkes...@google.com wrote: The first statement implies that a web-app on your platform cannot implement the algorithm you recommend. Sure it can. The user is effectively idle, in that they are not using your web application period. That they might be watching a 2 hour long movie with the device or on a 2 hour W3 conference call is irrelevant, they are idle for the purpose of your web application and you *must* rely on the server to figure this out. This is functionally equivalent to someone having three devices, a Mobile Phone (TM), an Internet Tablet Device (TM), and a Pocket DVD Player (TM). In this case, the user stops using their Internet Tablet in favor of their Pocket DVD Player (TM) to watch the movie or their Mobile Phone (TM) for their two hour long w3 conference call. In all these cases, the web browser and its hosted app is idle and that's what the web server should conclude. The user's focus is not on the browser and in fact, the browser is effectively dead. The web-app would need to send a series of 'ping' messages to the server every n minutes as long as the user is using the device, so the server won't set the status to 'idle'. But if the user's doing something else on the device other than using that page, its JS won't run, so its timeout doesn't get a chance to send the message. Yes, because the web browser is idle which is the conclusion you must reach Basically, it sounds like a web-app on the n900 cannot make decisions based on overall idle time at all, only on idle time within its app. Yes, because for some insane reason we decided battery life was more important than Google Web Application (TM) support. I'm actually quite sorry about this, but it was a management decision. So it wouldn't make sense for the platform to implement this API. I'm not sure which API you're talking about. We ship Gecko + our API breaks. We're a non trivial mobile phone vendor. We're likely to continue to add similar breaks. In short, what I'm saying is that I'm objecting to a procedure for system idle, the concept is broken and it won't work, and i'll be forced to break it the day after it's integrated into Gecko and then people will wonder why it doesn't work. This is implementation feedback explaining why the feature doesn't work, isn't practical, shouldn't be implemented, and more importantly how there is a solution available today which works TODAY without requiring the addition of this broken API. Perhaps we're on the same page, in which case, great :).
Re: [whatwg] HTML extension for system idle detection.
On Sun, Sep 13, 2009 at 12:08 PM, Jens Alfke s...@google.com wrote: That is not what idle means to an instant-messaging/presence service like AIM or Jabber. The idle state means the user is not at the device, to the best of its knowledge. If the user is capable of receiving messages but does not want to be interrupted, that's called away or busy. If the user is not able to receive messages at all, s/he's effectively offline. Given that we are designing this API primarily for the benefit of IM apps, we need to end up with something that matches their semantics. It's only useful for IM apps to know that the user is present but not paying attention to them because they typically have the ability to obtain the user's attention somehow -- e.g., by popping up a window or causing something on the task bar to flash. As far as I know, web apps have no way to get the user's attention if they aren't using the web app, do they? I'd imagine popping up a window isn't reliable -- it might be stopped by a popup blocker, or the user might have all new windows going to tabs, or something like that. (Is there a new API for that, perhaps?) I'm fine with those statements as long as you append ...on our specific platform to each one. In the general case, however, especially on non-mobile platforms, they aren't true at all. In particular, the solution you describe is absolutely not a solution to the problem under discussion here, for any general purpose OS, because it does not match the long-established semantics of idle in instant-messaging/presence protocols, i.e. no detectable user interaction with the computer as a whole. I agree with this. If some platforms don't let applications run in the background, I don't see why that should prevent the creation of an idle detection API. It just wouldn't really work on those platforms, like a lot of other web app functionality (like checking for new mail in the background). The WHATWG is mainly trying to support rich applications for desktops or near-desktops, not a lowest-common-denominator feature set that will work even on minimal devices.
Re: [whatwg] HTML extension for system idle detection.
On Sep 13, 2009, at 9:51 AM, Aryeh Gregor wrote: As far as I know, web apps have no way to get the user's attention if they aren't using the web app, do they? GMail 'blinks' by alternating the window title between two states, which can be effective even if the animation in the window content isn't visible; but it's not that great a solution. Audio notifications are also possible. In HTML5 they won't even require a plugin :p I'd imagine popping up a window isn't reliable -- it might be stopped by a popup blocker, or the user might have all new windows going to tabs, or something like that. (Is there a new API for that, perhaps?) Yes, there is a notification API under review that tells the browser to pop up some kind of platform-specific notifier UI, like a task-tray bubble on Windows or a Growl-like floater on Mac OS. I haven't been paying close attention but I think a WebKit implementation is in progress. —Jens
Re: [whatwg] Setting document.location.hash to a not-yet-loaded element
On Thu, 3 Sep 2009, Aryeh Gregor wrote: Consider the following test page: !doctype html titletest/title scriptdocument.location = #frag/script div style=margin-top: 100em/div p id=fragJump to me!/p Observed behavior in both Chrome 4 and Opera 9.6 is that the browser jumps to the given fragment; Firefox 3.5 does not. I believe all versions of IE jump to the fragment as well, since MediaWiki relies on this, although I haven't personally tested. The issue is, of course, that at the time document.location is set, no element with id frag exists in the document. However, IMO it's expected that setting a fragment should cause the same behavior as if the user had navigated to the document with that fragment to begin with -- namely, that the UA jumps to the fragment when it loads. The current text of the specification appears to support Firefox's behavior [...] Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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] Setting document.location.hash to a not-yet-loaded element
I've filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=516293
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] HTML extension for system idle detection.
On Sun, Sep 13, 2009 at 7:08 PM, Jens Alfkes...@google.com wrote: That is not what idle means to an instant-messaging/presence service like AIM or Jabber. The idle state means the user is not at the device, to the best of its knowledge. If the user is capable of receiving messages but does not want to be interrupted, that's called away or busy. If the user is not able to receive messages at all, s/he's effectively offline. The user is idle until the user navigates away from the page. You'll probably still get a page navigation message. If you don't get one after four hours, you can choose to decide that perhaps the client disappeared. Given that we are designing this API primarily for the benefit of IM apps, we need to end up with something that matches their semantics. Sorry, design it without relying on help from browsers. Trust me on this. I spent several years immersed in IM protocols and was the tech lead on the first release of Apple's iChat client. I've only spent 3 years working for my present employer whose concern is focussed on battery life. I know that's a small amount of time to care about battery life, but i'm getting lots of push from people who think their entire life has been spent worrying about customers' batteries. Where's this sarcasm coming from? No sarcasm. I would use sarcasm if I meant to include sarcasm. HTML extension for system idle detection is the API under discussion. My point is that it is likely not feasible for your platform to support this extension, given what it's capable of providing. That doesn't mean the extension is somehow broken. My product is likely to be one where people would want to use your product, and the API will not work, which means you're going to have to work around this broken API anyway. Designing it is a waste of your time, since you're going to need to work around it anyway. You're going to need to have a working design which doesn't rely on cooperation from browsers. And telling web authors that they can rely on browsers to cooperate is just going to result in mobile users where communication products don't work, which is a great disservice to all involved. Web Devs will assume that whatever API you settle on will be universally available on modern browsers and that it will work. This won't be the case. If the device doesn't implement sufficient multitasking to allow the browser to remain active in the background, then from an IM perspective the state the browser goes into is offline, not idle, since the browser's incapable of receiving messages. (Or is it? On further thought, I'm unclear on this. You describe the socket remaining open, so if the server were to send data over it, would the browser wake up and allow the app to respond to it? If so, then it actually is an 'idle' state.) The socket should be alive, and yes the browser should process the pushed data, at least under certain circumstances. I'd expect js wouldn't receive the data immediately. But using socket tricks should enable you to classify the client as idle. If the user does switch back to the browser the user should be able to see html in e.g. an iframe if you happened to push data that way. You won't be able to use a flash object to trigger a notification while the browser is in the background. Support for audio was not in the last image I tested (it might appear in an update, depending on approval well beyond my control), but i'd assume we'd try to suppress it under the same circumstances that we'd suppress plugins (although in an initial update we might not). I'm fine with those statements as long as you append ...on our specific platform to each one. In the general case, however, especially on non-mobile platforms, they aren't true at all. So. There's long been this disaster of the web and the mobile web. I'm working to bring a normal web browser to a mobile device, with the hope that there would be only one web. If you add APIs which can't be safely implemented on mobile devices then you help with the continuation of the distinction between these two places, which is terribly unfortunate. Now you could shift the blame and say that my action of breaking the API is what is responsible for this, but the thing is that I don't have a choice, short of power of the air (TM) [it's funnier when you see devices which think they're charging without any wires -- I have one of those here]. Personally, I don't like breaking features, and I really wish we didn't have to break google apps, but battery life is critical for mobile devices, such as mine. In particular, the solution you describe is absolutely not a solution to the problem under discussion here, for any general purpose OS, because it does not match the long-established semantics of idle in instant-messaging/presence protocols, i.e. no detectable user interaction with the computer as a whole. sarcasm Ah yes, if we add this, does that mean you'll stop crashing Firefox by unloading the
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.
