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 **
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
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
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
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
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
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
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
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
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
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: >> 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
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 **
[WSG] "window.open" and popup blockers
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 a "return false" statement should be ignored as well. AFAIK, that's Opera's behaviour... 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 **
