Can pop up killers interfere with DHTML layers?

[Umbra]

1) Does anyone have evidence of pop up killer software that interferes with DHTML layers (ie, Javascript toggling CSS visibility or display?)

2) What techniques would a popup blocker use to distinguish between DHTML fly-by ads and standard uses of DHTML?

My purpose is not to learn how to create css popups that get around pop up blockers. I honestly want to ensure our "legitimate" DHTML is not being blocked. I am aware of the endless war between advertisers and ad killers. The popup killers have won the battle against Javascript pop up windows. So is it safe for webmasters to count on popup layers, and for how long?

[Rambo Tribble]

Virtually all popup blockers act on the window.open() method. Scripts that do not use window.open() should not be affected by popup blockers (that said, there is bound to be some hack-job blocker out there that is the exception).

[rocknbil]

I have to ask - isn't is the window.open() method in combination with some other events, such as onLoad or the absence of a user event?

The reason I ask is this is of large concern to me on some older projects and I can't seem to find any blocker problems . . . .

[Rambo Tribble]

Most popup blockers do distinguish between user initiated events and script initiated events and block only the latter, but I've seen exceptions (though specifics don't come to mind).

[hommealone]

Hi. Rambo tribble wrote:

Virtually all popup blockers act on the window.open() method. Scripts that do not use window.open() should not be affected by popup blockers.

Can you advise about specific other types of scripts that are not "window.open() method" scripts? What would those be? Where could I find examples?

I need to fashion links which our dealers can use in their websites that will open "PopUp" windows to "product information" pages from our webserver. I'd like them to be blocked by as few PopUp blockers as possible. (Do you think that the fact that the link is pointing to off-site content will more likely trigger popup blockers?

[Rambo Tribble]

As mentioned, most popup blockers do distinguish between a window.open() invocation that was triggered by a user clicking on a link vs. one triggered by an event like onload. It is the latter that gets blocked, though I seem to recall at least one of the cruder blockers interfering with the former case, it was an exception.

Bear in mind, popup blockers are only one problem; some users have JavaScript turned off altogether.

[hommealone]

Thanks. I went searching for javascripts today and I did find some that work by other means instead of the window.open() method. Any guess if those would be any less likely to trigger PU blockers? (Any method I use will be triggered by clicking on a link.)

Bear in mind, popup blockers are only one problem; some users have JavaScript turned off altogether.

I've seen some code written so that non-javascript-enabled browsers will treat the (clicking-on-link)event by just opening a plain new window or performing the event simply as a regular click. Know anything about that?

[Bernard Marx]

Popups may be your only option - without some server involvement.

Any methods I can think of that import content into a layer
- invisible iframe
- XMLHTTP
will not work across domains. So your clients wouldn't be able to draw in content from your domain - clientside anyway.

It is possible to use XMLHTTP on the server, if equipped.
..but then, I suppose they'd all have to implement it.
Hmmm..
<edit>
There's always "iframe in a layer".

I've seen some code written so that non-javascript-enabled browsers will treat the (clicking-on-link)event by just opening a plain new window or performing the event simply as a regular click. Know anything about that?

<a href="page.html" onclick="window.open('page.html','pop','height=etc...');return false;">

..stick a target attribute in there if you want a new window for the JS-disabled action.

[Rambo Tribble]

To elaborate on Mr. Marx's suggested use of the target attribute, if your link has the attribute/value of target="_blank", a new window will be opened with the contents of the link's address, as the default action. By placing an onclick event handler to open a popup window and returning false, you will open a popup and cancel the default action, if JavaScript is active.

I believe, however, that the target attribute is deprecated in XHTML.

[Umbra]

To elaborate on Mr. Marx's suggested use of the target attribute, if your link has the attribute/value of target="_blank", a new window will be opened with the contents of the link's address, as the default action.

OK, so this is going off-topic a bit, but I discovered that at least one web filtering software will block anything that has target="_blank". Replace it with target="something" and it works fine. It was pretty ridiculous too, because this particular example was a thumbnail image that could be clicked to open a larger version of the image in a popup. Not only was the popup blocked, the entire thumbnail image was filtered out by the program! That's a silly default behaviour if you ask me.

[hommealone]

Bernard; Rambo Tribble; Umbra; Thank you all very much. This info is all helpful to me. Couple more questions:

1)

I believe, however, that the target attribute is deprecated in XHTML.

Is this definitely true?; and if so, what would happen if someone put code such as:

<a href="page.html" target="_blank" onclick="window.open('page.html','pop','height=etc...');return false;">

into a page written in xhtml? Would it then not validate? Would it not work or display correctly?

2)

at least one web filtering software will block anything that has target="_blank". Replace it with target="something" and it works fine.

Not off-topic at all! Could you be more specific about what that "something" might be, and how I might need to "define" or "create" it? Sorry, but there's a lot of basic stuff like this that I don't know yet. : )