Browser wars BS

[Markbnj]

Bah, this stuff drives me nuts. I have a link wrapping and image and caption inside a div. The link uses window.open() to open a slideshow in a popup window. Here's the code...

<a href="javascript:window.open('/slideshows/blahblah','slides','width=850,height=700,toolbar=0,location=0,menubar=0,resizable=0,scrollbars=0,status=0,titlebar=0')">
<div style="margin-left:25%; margin-right:25%;">
<img src="http://www.markbetz.net/wp-content/gallery/miscellaneous-article-graphics/link_image.jpg" />
<br />
<span style="margin-left:50px;">Click here to launch the slideshow</span>
</div>
</a>

Don't ask me about that stupid br tag before the caption span... I added that to get the caption under the div in IE, something else that drove me nuts. Probably there's a better way.

The real problem is the behavior of the window.open() call. On Chrome it works exactly as it should. Click the link and the popup opens with the slideshow. On IE9 and Firefox it first opens a blank white window with the word [object] (Firefox) or [object window] (IE) at the upper left, and then pops the slideshow window over that. I can't figure out why that would happen. Anyone have any clues?

 

[PhatoseAlpha]

I *think* the issue is that the window.open actually returns an object. You call window.open, it opens a window as it's supposed to....and the returns the window object. The link therefore transfers you over to that returned object, and you get [object] in your browser.

The solution seems to be to wrap the window.open in a function that doesn't return anything, and call that from javascript instead.

 

[Markbnj]

I *think* the issue is that the window.open actually returns an object. You call window.open, it opens a window as it's supposed to....and the returns the window object. The link therefore transfers you over to that returned object, and you get [object] in your browser.

The solution seems to be to wrap the window.open in a function that doesn't return anything, and call that from javascript instead.

Interesting. I guess Chrome eats that object. I did want to put the open in a function but I had a hard time figuring out where to inject the script in the wordpress theme. When I added script tags to header.php it messed up the site rendering.

 

[DaveSimmons]

You could try href="#" onclick="<code>" so no navigation takes place.

 

[Markbnj]

You could try href="#" onclick="<code>" so no navigation takes place.

I ran into an issue with that, or a variant actually, in Chrome. I had href="javascript:void(0)" and onclick="yadayada" and Chrome threw an error "Refused to execute a javascript script. The source of the script was found in the request." What I could find on this seems to indicate that calling out to a function is the way to prevent it, but as I said earlier I was having problems injecting a function into wordpress' page output. I'll give it a try with the # in the href and see if the behavior changes.

Browsers suck.

 

[EagleKeeper]

Browsers suck.

You have a better solution?

 

[Markbnj]

You have a better solution?

No, but in all seriousness, when the debate comes up over whether HTML5 will ultimately replace native apps I think of all the bs we still have to go through, 15 years into the Internet revolution. Chrome, Firefox, and IE9 _still_ don't render compliant markup the same way. It's ridiculous.

 

[Markbnj]

You could try href="#" onclick="<code>" so no navigation takes place.

That appears to have done the trick, Dave. Thanks for the suggestion.

 

[Cogman]

No, but in all seriousness, when the debate comes up over whether HTML5 will ultimately replace native apps I think of all the bs we still have to go through, 15 years into the Internet revolution. Chrome, Firefox, and IE9 _still_ don't render compliant markup the same way. It's ridiculous.

Alas, this issue isn't isolated to web browsers. Pretty much any system that has to interpret some sort of standard string in one way or another is going to do things differently and have errors readily available. Compilers, Processors, etc. All have their own unique flaws the become readily available when a competitor produces a product that is supposed to be able to read the same string.

We are especially aware of this issue in browsers because of the frequency of interpretation that they do (and the fact that IE has been just terrible at it.)

 

[LokutusofBorg]

That appears to have done the trick, Dave. Thanks for the suggestion.

Just a word of warning, we had lots of these types of links in our app at work (href="#" onclick="..."), and we had to go through and change them all because of browser issues to the javascript void() version. The updated form passed all browser testing by our QA, so... I'm not sure why you are getting an issue trying to use it.

And yes, browser compatibility sucks rocks. I've wasted way too many hours of my professional life dealing with it.

 

[Woosta]

I would suggest attach the behaviour unobtrusively or you're mixing markup with behaviour ( BAD ). Unless you're dealing with some blackboxed FB-type code there really is no reason why you can't do this.

EDIT: I made a fiddle of this here: http://jsfiddle.net/jU6ja/5/

live demo: http://fiddle.jshell.net/jU6ja/5/show/

It's bad enough using inline event handlers, its not so great using the JS pseudo protocol, and while I don't know the technical details I'm pretty sure binding it the way I have it would avoid the oddity you're experiencing because the pseudo protocol points to the object returned from window.open.

And obviously the code has room for improvement... the method is defined as global, as a matter of fact the entire thing should be run in a private namespace, I could have used an elaborate event handler registration system, I could have used a context DOM node for efficiency, etc... And obviously you could easily just use jQuery and get it done in like 1 minute via

$('a.blah').click(function(e) {e.preventDefault();
var win = window.open ( this.href ); // and all the other sh!t
if ( win ) win.focus();
});

 

[EagleKeeper]

There are no honored standards to the HTML language. Therefore each browser implements it's own "better" mousetrap. And/or interprets how to implement a feature differently.

A+B == C does not mean that B + A == C

It should but...

 

[Markbnj]

I would suggest attach the behaviour unobtrusively or you're mixing markup with behaviour ( BAD ). Unless you're dealing with some blackboxed FB-type code there really is no reason why you can't do this.

Yeah, I agree in principle. For this one-off link though, I am not so concerned. Just wanted it to work.

 

[Oyster]

You know what the next big thing on developers' shit list is going to be? Touch Gestures. There is no fucking standard around this crap, and it is going to be worse than HTML. Just my two cents!

 

[Cogman]

You know what the next big thing on developers' shit list is going to be? Touch Gestures. There is no fucking standard around this crap, and it is going to be worse than HTML. Just my two cents!

After watching the new windows 8 preview, I have to agree. This is going to be a crazy mess that should have been sorted out as soon as the Iphone became popular.

(windows 8 preview thread http://forums.anandtech.com/showthread.php?t=2168987 )

 

[Kirby]

You have a better solution?

Everyone use Lynx?

 

[Ka0t1x]

There's actually vast developer notes and code samples in Apple's developer database for 'Safari Developers' on how to handle iOS touch inputs.

That being said, there's no standard afaik.

Edit:
There's always libraries like JQuery Mobile, but those are really only inputs/design stuff.