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
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
-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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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.
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
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
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
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,
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
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
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
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.
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
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
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
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?
41 matches
Mail list logo
