On Thu, 26 Mar 2009, Randy Drielinger wrote:
With the risk of not being compliant with other OS's, but isn't using
file://localpath/real_file_name.extension (so using file://localpath/
by default) the solution for the original suggestion?
This ensures not breaking anything on existing
Am Dienstag, den 24.03.2009, 08:18 + schrieb Ian Hickson:
According to Microsoft:
http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx
...the problem was with a significant number of sites (e.g. education
products, several movie sharing sites, etc) and
Randy Drielinger ra...@prowebdesign.nl wrote:
With the risk of not being compliant with other OS's, but isn't using
file://localpath/real_file_name.extension (so using file://localpath/ by
default)
the solution for the original suggestion?
This ensures not breaking anything on existing
] C:\fakepath\ in HTML5
Randy Drielinger ra...@prowebdesign.nl wrote:
With the risk of not being compliant with other OS's, but isn't using
file://localpath/real_file_name.extension (so using file://localpath/
by
default)
the solution for the original suggestion?
This ensures not breaking
for the whole workaround.
my 2cents
- Original Message -
From: ddailey ddai...@zoominternet.net
To: Ian Hickson i...@hixie.ch; wha...@whatwg.org
Sent: Wednesday, March 25, 2009 11:26 PM
Subject: Re: [whatwg] C:\fakepath\ in HTML5
While on the topic, something vaguely similar came
The long and short of it with the c:\fakepath\ issue is that some browser
vendors have reported compatibility problems with not having this. I
acknowledge that there is some skepticism about whether this is a serious
enough issue to warrant this ugly hack, but given that the concerns were
-
From: Ian Hickson i...@hixie.ch
To: wha...@whatwg.org
Sent: Wednesday, March 25, 2009 5:39 PM
Subject: Re: [whatwg] C:\fakepath\ in HTML5
The long and short of it with the c:\fakepath\ issue is that some browser
vendors have reported compatibility problems with not having this. I
acknowledge
On 24.03.2009, at 8:09, Ian Hickson wrote:
(I would expect Firefox, Safari, and Chrome to follow suit; Firefox
for
compatibility, and Safari and Chrome for privacy.)
FWIW, WebKit returns just the file name now.
- WBR, Alexey Proskuryakov
On Mon, 23 Mar 2009, Alex Henrie wrote:
On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson i...@hixie.ch wrote:
I agree. Unfortunately, sometimes we are unable to make choices that
end up with a nice language. :-(
Well, why not? Is HTML5 supposed to be perfectly compatible with HTML4?
No, but
Ian Hickson wrote:
That's encouraging.
According to Microsoft:
http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx
...the problem was with a significant number of sites (e.g. education
products, several movie sharing sites, etc) and devices (e.g. popular home
routers).
Ian Hickson wrote:
Maybe someone from Opera could let us know which sites caused them to do
this? Was it many, as with Microsoft?
I did a quick search through our bugs and found this site that breaks if
only the filename is returned because there's an onsubmit script that
checks the value
Which sites? Any site that *requires* a Windows path clearly isn't
interested in inter-operating with other browsers/platforms; heck, it means
they've limited their testing to just Windows/IE. Don't punish the rest of
us for their poor testing/programming.
My friend ! Welcome to the
Lachlan Hunt wrote:
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return
On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Sure it is. You just need a browser that'll allow you to do a firmware
upgrade to fix it. Which means that if one gets such an upgrade shipped
before all browsers stop sending paths, things seem to be ok. I agree
So instead of fixing the web, we're fixing the spec (and thus implementing
fakepath in browsers)?
- Original Message -
From: Lachlan Hunt lachlan.h...@lachy.id.au
To: Ian Hickson i...@hixie.ch
Cc: wha...@whatwg.org
Sent: Tuesday, March 24, 2009 11:00 AM
Subject: Re: [whatwg] C
Randy Drielinger wrote:
So instead of fixing the web, we're fixing the spec (and thus
implementing fakepath in browsers)?
It's purely a question of what browser makers are prepared to implement.
The spec has to reflect a consensus amongst browser makers so that it
actualy gets implemented,
Am Dienstag, den 24.03.2009, 16:06 +0100 schrieb James Graham:
If you don't
want the fakepath thing (and I agree it is ugly), try convincing the
known-broken sites to change (citing the fact that they may break in
Firefox could give you quite some leverage here).
From what I remember,
Ian Hickson wrote on 3/24/2009 12:09 AM:
The original plan was to just have the filename. Unfortunately, it turns
out that if you do that, there are certain sites that break, because they
expect the path (and they expect a Windows path, no less). This is why
Opera and IE8 return a fake
On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Sure it is. You just need a browser that'll allow you to do a firmware
upgrade to fix it. Which means that if one gets such an upgrade shipped
On Tue, 24 Mar 2009 17:23:20 +0100, Alex Henrie alexhenri...@gmail.com
wrote:
On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren ann...@opera.com
wrote:
Microsoft did. And nothing changed in well over a year. (They say so in
a comment on the blog post.)
Perhaps the buggy code was only sent
Bil Corry wrote on 3/24/2009 11:01 AM:
Ian Hickson wrote on 3/24/2009 12:09 AM:
The original plan was to just have the filename. Unfortunately, it
turns out that if you do that, there are certain sites that break,
because they expect the path (and they expect a Windows path, no
less). This
On Tue, Mar 24, 2009 at 10:34 AM, Anne van Kesteren ann...@opera.com wrote:
Example: A site lets a user upload a file and write some comments
associated with that file. On the browser side, a new input element is
dynamically created with the name and id Notes for
C:\fakepath\upload.txt. On the
On Tue, Mar 24, 2009 at 11:24 AM, Alex Henrie alexhenri...@gmail.com wrote:
I mean, if the browser used C:\fakepath\upload.txt in both
JavaScript and DOM then there would be no problem in this example. But
mixing C:\fakepath\upload.txt and upload.txt creates additional
complications.
Whoops,
On Mar 24, 2009, at 12:31 AM, Alexey Proskuryakov wrote:
On 24.03.2009, at 8:09, Ian Hickson wrote:
(I would expect Firefox, Safari, and Chrome to follow suit; Firefox
for
compatibility, and Safari and Chrome for privacy.)
FWIW, WebKit returns just the file name now.
It should also
Dear WHATWG,
Recently section 4.10.4.3 of the HTML5 specification was changed to
recommend that C:\fakepath\ be prepended to the DOM value of file upload
input elements. For example, when uploading /home/alex/upload.txt,
JavaScript will see C:\fakepath\upload.txt. This is now implemented in IE8
On Mon, 23 Mar 2009, Alex Henrie wrote:
Recently section 4.10.4.3 of the HTML5 specification was changed to
recommend that C:\fakepath\ be prepended to the DOM value of file
upload input elements. For example, when uploading
/home/alex/upload.txt, JavaScript will see
On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson i...@hixie.ch wrote:
I agree. Unfortunately, sometimes we are unable to make choices that end
up with a nice language. :-(
Well, why not? Is HTML5 supposed to be perfectly compatible with HTML4?
-Alex
Ian Hickson wrote:
The original plan was to just have the filename. Unfortunately, it turns
out that if you do that, there are certain sites that break, because they
expect the path (and they expect a Windows path, no less).
I don't believe I've seen many bugs along these lines for Firefox...
On Tue, Mar 24, 2009 at 1:09 AM, Ian Hickson i...@hixie.ch wrote:
The original plan was to just have the filename. Unfortunately, it turns
out that if you do that, there are certain sites that break, because they
Chance of this happening is only for intranet site.
So if browser vendors want to
Ian Hickson wrote on 3/24/2009 12:09 AM:
On Mon, 23 Mar 2009, Alex Henrie wrote:
First, this change is dishonest. It tells JavaScript that the file is
stored somewhere that it is not. And why say anything, true or not,
about where the file is stored at all? All JavaScript needs to know is
30 matches
Mail list logo
