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/ (so using file://localpath/
> by default) the solution for the original suggestion?
>
> This ensures not breaking anything on existing websites and is a far
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 sharin
s-platform uniform (expected) behavior.
With the risk of repeating myself, are we forcing the specs to cover all
possible exceptions JS-programmers create?
- Original Message -
From: "timeless"
To: "Randy Drielinger"
Cc:
Sent: Sunday, March 29, 2009 9:47 AM
Subject
Randy Drielinger wrote:
> With the risk of not being compliant with other OS's, but isn't using
> file://localpath/ (so using file://localpath/ by
> default)
> the solution for the original suggestion?
>
> This ensures not breaking anything on existing websites and is a far more
> logical name for
the whole workaround.
my 2cents
- Original Message -
From: "ddailey"
To: "Ian Hickson" ;
Sent: Wednesday, March 25, 2009 11:26 PM
Subject: Re: [whatwg] "C:\fakepath\" in HTML5
While on the topic, something vaguely similar came to mind.
If we make a
HTML?
- Original Message -
From: "Ian Hickson"
To:
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
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
rais
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 be
On Tue, Mar 24, 2009 at 11:24 AM, Alex Henrie 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, that should h
On Tue, Mar 24, 2009 at 10:34 AM, Anne van Kesteren 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 server
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)
On Tue, 24 Mar 2009 17:23:20 +0100, Alex Henrie
wrote:
On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren
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 to IE, and Firefox got more
reasonable
On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren wrote:
> On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky 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 sto
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
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,
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,
So instead of fixing the web, we're "fixing" the spec (and thus implementing
fakepath in browsers)?
- Original Message -
From: "Lachlan Hunt"
To: "Ian Hickson"
Cc:
Sent: Tuesday, March 24, 2009 11:00 AM
Subject: Re: [whatwg] "C:\fakepath
On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky 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
they're not as happy as
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();
retur
Ian Hickson wrote:
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)". The blog post above
> 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
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 for
On Tue, 24 Mar 2009, Julian Reschke wrote:
> 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, se
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)".
On Mon, 23 Mar 2009, Alex Henrie wrote:
> On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson 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 it _is
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
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 kno
On Tue, Mar 24, 2009 at 1:09 AM, 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
Chance of this happening is only for intranet site.
So if browser vendors want to support it,
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 Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson 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
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 "C:\fakepath\
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
32 matches
Mail list logo
