[whatwg] Fakepath revisited
herenvardo at gmail.com
Mon Sep 14 04:39:31 PDT 2009
On Mon, Sep 14, 2009 at 3:12 AM, Ian Hickson <ian at hixie.ch> wrote:
> Here are some bug reports that I believe are caused by this issue:
This is factual data, thank you.
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 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
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.
More information about the whatwg