Re: [WSG] window.open and popup blockers
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 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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? Thierry | www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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 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. 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. Thierry | www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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 !window.open(this.href) seems logical to me. -- Jan Brasna aka JohnyB :: www.alphanumeric.cz | www.janbrasna.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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. 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. 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 be considered standalone. It's up to the programmer to add the control structures to determine which paths are followed, not a browser based on the presence of a function call. For example, suppose I decided to use the return value of window.open to determine whether or not to add a block of content within the current document for user-agents that support scripting. If it ignores the return false, it will fetch the URL against my wishes, and my alternative content for user-agents that support scripting but have popups blocked will be lost. Best regards, Gez -- _ Supplement your vitamins http://juicystudio.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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 be considered standalone. It's up to the programmer to add the control structures to determine which paths are followed, not a browser based on the presence of a function call. Jan, Gez, 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. IMO, that's a smart way for a blocker to give control to the user over the popups without killing the links. I know Opera's blocker behaves this way, so if it violates ECMA-262 I believe it's for a good cause ;). FMI, do you actually know blockers that kill these links? Thierry | www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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. FMI, do you actually know blockers that kill these links? Eg. older Operas. -- Jan Brasna aka JohnyB :: www.alphanumeric.cz | www.janbrasna.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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. IMO, that's a smart way for a blocker to give control to the user over the popups without killing the links. I know Opera's blocker behaves this way, so if it violates ECMA-262 I believe it's for a good cause ;). 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 structured programming concept; statements are executed sequentially. If logic is required, then it should be added by the programmer using selection or iteration constructs, which may then cause the execution to take different paths. I would sooner programmers coded responsibly than have a browser that started to second guess what I was trying to achieve. The example I provided earlier is a good example of where the behaviour you're describing for Opera would be incorrect. Best regards, Gez -- _ Supplement your vitamins http://juicystudio.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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 ignored in any way. The environment processing it just does not open new window vs. it ignores it... Is that supposed to answer the question about the *return false* statement that is ignored by the browser (Opera in this case)? FMI, do you actually know blockers that kill these links? Eg. older Operas. That'd show that they considered previous versions of their blocker as flawed, no? Thierry | www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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 answer the question about the *return false* statement that is ignored by the browser (Opera in this case)? Sorry Thierry, I really don't understand you on this. As I wrote - the browser doesn't (==shouldn't) ignore anything. Fullstop. Eg. older Operas. That'd show that they considered previous versions of their blocker as flawed, no? Or it shows that they had to fix programmers' mistakes in the favor of the poor end users... -- Jan Brasna aka JohnyB :: www.alphanumeric.cz | www.janbrasna.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] window.open and popup blockers
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 structured programming concept; statements are executed
sequentially. If logic is required, then it should be added by the
programmer using selection or iteration constructs, which may then
cause the execution to take different paths. I would sooner
programmers coded responsibly than have a browser that started to
second guess what I was trying to achieve. The example I provided
earlier is a good example of where the behaviour you're describing for
Opera would be incorrect.
I understand the concept, and I don't think anybody would disagree with you.
Actually, that's why I thought Opera was a smart blocker, being able to
make a choice regarding 2 *separate* statements.
But I believe now that the reality is very different.
Jan said that the method was processed, but I start thinking that in fact
the blocker skips the whole thing as it would in the presence of a script
error.
I believe if the return false statement is ignored, it's simply because
the browser doesn't get to it, it's that simple.
I just tried:
window.open(this.href);alert('whatever');return false;
and didn't get the alert box
I think this is an important point, because as you said, it breaks the
sequence.
Best regards,
Thierry | www.TJKDesign.com
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] window.open and popup blockers
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 previous versions of their blocker as flawed, no? Or it shows that they had to fix programmers' mistakes in the favor of the poor end users... I'm not sure they fix anything actually. I think everybody out there using statements past a call to window.open is in trouble... Thierry | www.TJKDesign.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
