Following the opening new window philosophy thread, I'm curious to know if
there are blockers out there that *kill* links that trigger popups (do not
open a new window, do not call the href value either).
I can understand the logic behind ignoring window.open (even in an
anchor), but then I think
I can understand the logic behind ignoring window.open (even in an
anchor), but then I think a return false statement should be ignored as
well.
Are you sure? There's no reason for such an action.
--
Jan Brasna aka JohnyB :: www.alphanumeric.cz | www.janbrasna.com
Jan Brasna wrote:
I can understand the logic behind ignoring window.open (even in an
anchor), but then I think a return false statement should be
ignored as well.
Are you sure? There's no reason for such an action.
Jan,
I'm not sure I understand your question regarding what you've quoted.
Do you mean there is no reason for ignoring the return false statement?
Yes. I can't see any reason why a browser/plugin/firewall etc. should
ignore an independent part of a JS code.
--
Jan Brasna aka JohnyB :: www.alphanumeric.cz | www.janbrasna.com
Jan Brasna wrote:
Do you mean there is no reason for ignoring the return false
statement?
Yes. I can't see any reason why a browser/plugin/firewall etc. should
ignore an independent part of a JS code.
I see one. In that particular case, such behaviour makes sure that the user
still can reach
That's why I didn't really see the need for testing for window.open to
begin with, because in my mind a blocker that ignores window.open in an
anchor should honour the href value.
IMHO the blocker should just return negative result for window.open,
nothing more. Since the construction return
On 16/08/05, Thierry Koblentz [EMAIL PROTECTED] wrote:
I see one. In that particular case, such behaviour makes sure that the user
still can reach the href value. IMO, it makes sense,
and AFAIK, that's how Opera's blocker works. It ignores *both* statements,
window.open *and* return false.
Gez Lemon wrote:
I've no idea whether Opera does ignore return false statements, but it
would be outrageous if it did as it completely violates ECMA-262.
Ignoring whether or not it's good practice to have JavaScript
statements in an inline event handler, it is legal, and each statement
should
In this particular case, if you consider normal to arbitrary ignore the
window.open statement [...]
It does not ignore it! The method is fired successfully, but the
environment processing it just does not open new window and tells the
method to return false. It is not ignored in any way.
On 16/08/05, Thierry Koblentz [EMAIL PROTECTED] wrote:
I'm talking about a simple:
onclick=window.open(this.href,'myPopup'); return false;
In this particular case, if you consider normal to arbitrary ignore the
window.open statement, then why do you consider outrageous to ignore
return false.
Jan Brasna wrote:
In this particular case, if you consider normal to arbitrary ignore
the window.open statement [...]
It does not ignore it! The method is fired successfully, but the
environment processing it just does not open new window and tells the
method to return false. It is not
It does not ignore it! The method is fired successfully, but the
environment processing it just does not open new window and tells the
method to return false. It is not ignored in any way.
The environment processing it just does not open new window vs. it
ignores it...
Is that supposed to
Gez Lemon wrote:
In this example, Thierry, there are two completely separate
statements. Programmatically, they're not dependent on each other, and
should be executed sequentially. Any structured scripting/programming
language that breaks the sequence construct is broken. It's a
fundamental
Jan Brasna wrote:
Sorry Thierry, I really don't understand you on this. As I wrote - the
browser doesn't (==shouldn't) ignore anything. Fullstop.
NP, see my answer to Gez.
I think I know now why the return false statement is not respected.
Eg. older Operas.
That'd show that they considered
14 matches
Mail list logo