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 ******************************************************
