form button, target new window, beat google toolbar 4

[1DMF]

hi,

How can you make a normal form button, that onclick targets a new window, that beats google toolbar pop-up blocker and is still X/HTML 1.1 strict compliant?

I did it as a form and had a submit button and used JS to attached the target attribute to enable X/HTML validation, but google sees a form being submitted to a new window as a popup.

if it sees a submit button to submit a form that must be clicked as a pop-up , why doesn't it just go the whole hog and deactivate every anchor while it's at it!


"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[1DMF]

onclick="this.target='_blank'" <- this does work? I use it for the privacy policy anchor also.

we know that the JS is attaching the attribute 'Target' to the tag as the popup blocker is being triggered and if the target wasn't attached, the PDF would open in the current window instead without any problems.

P.S. Can you drink a pint of Marmite?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[Foamcow]

OK.
The reason the this.target='_blank' doesn't work with my solution is because it isn't actually opening a window. All it is doing is instructing the browser to send the result of the regular link request to another window. However, the return false; effectively cancels the regular link behavior.

The window.open method sort of combines the window opening with an http request.

The only way of opening a new window and have it load something into that window with Javascript, as far as I am aware, is to use window.open.

You might be able to write a function to create the named window with the target method and then perform an http request to get something into it. But that really is well into the Javascript forum.

It also seems like alot of messing around for not much real benefit since there is no guarantee something else won't block it and of course without Javascript your whole application will fail (covered earlier).


If you are trying to get around Norton's prevention of this behaviour then forget it. You shouldn't be doing it anyway. The person with Norton on their machine has it there to stop people opening new windows. Regardless of your motive, they don't want it. Don't try to change it, it's not your place to do so.

You will have to rely on either:
1. The user allowing the popup
2. Ignore the non-validation or use a DocType that permits the target attribute.
3. Rethink the process to make it more linear and thus negate the need for convoluted methods of opening windows.


<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.

 

[1DMF]

you forgot an option

4. Do it the way I've done it and use JS to scrollTo #q3 instead of document.location.href='#q3'.

The PDF doesn't get blocked and the page jumps to Question 3.

OK point taken about NO JS , NO Deal!

I can see what your saying on one hand with Norton, the problem lies that this option is on always and every user I've had to deal with that has Norton doesn't know how to configure it otherwise.

Until I re-wrote our members area a few had to hold CTRL for any of the menu options to work, what a nightmare that was!

I do think that the KeyFacts (IDD) should and needs to be in a separate window, and the compnay who i'm doing the site for requested it that way also, so I think i've found a compromise.

Thanks as always for your valued input.

1DMF

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.