Heaven Ain't All That
Back in Developer Heaven and Microsoft have also thrown a spanner in the works. Remember I was trying to decide how to deal with user-defined links inside my Kiosk-mode application? No? Well, basically, a link to anything outside the app itself has to launch in a new browser or else the user is lost. In Kiosk-mode the application is the whole interface to that PC!
Well, thanks to your feedback I found a hack solution. Thanks to Microsoft having not given a toot for standards I could use multiple <base> tags on a page. As shown, you can switch from one base target to another. In my case I want any link inside the Body field to open in a new window. So I make this the default target, display the field and then switch back to the same window as the target.
It's simple. It works. It's a hack. Base tags are only supposed to appear once per page and only in the head. The alternative is to have one legal base tag in the head and make sure every link outside the Body field (be it an <a> tag or a JavaScript function) points to the same window. That's lots of work.
I was hoping I could avoid all this work by making use of this multiple base tag hack. Sometimes the fact that IE lets you get away with this stuff is a real Godsend. But. Microsoft are giving in to pressure by the looks of it and pay more attention to standards, starting with release 7 of IE. In the amusingly-titled blog entry All your <base> are belong to us they've gone and broken my hack. With not a care for backwards compatibility they announce that any page using more than one <base> tag will not work in IE7. A bit like taking sweets from a baby. In IE 7 only one tag is allowed and it has to be in the head.
Now I have to go to the client with tail between legs and see what they want to do about it. I can give it to them and it will work. But, as soon as IE 7 comes out, it will break and I can't live with than on my conscience. I'm a professional damnit!
Skip to the 
You can subscribe to an individual
Couldn't you use js to do a
var oLinks=document.getElementById("bodyField")[0].getAllElementsByTagName("A");
for(var i=0;i<oLinks.length;i++) {
oLinks[i].target="_blank"
}
Assuming you have put an ID on your field eg bodyField.
That should do it... no hacks!
That would work Chris. It's just me being weird and not wanting to use any onload iteration of elements. It just seems wrong to me. I'd rather make sure all the links point to _self before I opted for that. Just me being me.
Beware Jake - the base tag behavior is changed in IE7.
MS have corrected their "standards error".
So upshot is your hack might no longer work.
And I should read the end of your post!
Steve. The application has been delivered to the client for testing. I'm going to have to tell them about this issue and see what they say. Although I can see myself just going ahead and sorting it out. I get enough sleepless nights as it is.
I would think Chris's method would almost be perfect for your situation. I understand not wanting to use JS onLoad but your app is in a very controlled environment, so JS may give you exactly what you need without much fear of odd-ball browser settings issues. You could even add to the function and make only links to external sites pop-up in a new window and allow internal links (that the user may add to the body) appear in the same window.
@Steve
What are you doing on here trying to help Jake? Don't you have a new version of DominoBlog to get into production? :-)
@Jake
I know you don't like the onLoad JS function I use, but I couldn't come up with any other solution when I was looking at the same problem.
Sean---
Can't you iterate through the body when the user submits the form and set targets on all external links (and turn local ones into relative links at the same time)?
Ian. Yes and no. No because part of the app reads external emails, over which we have no control.
You'll shoot me, but what about a frame for the body? It can have its own page and its own base and be framed into the kiosk.
As I've recently noticed, Google does this to control the behavior of adWords.
Actually Jerry, I might consider that. An IFrame you mean? Don't see any harm in that. I'd rather not, but then I'd rather not have had to have two base tags outside the head. Life's rarely perfect. Thanks for the idea.
The only problem I can see is with scrolling. If the Body field gets big and needs to scroll, it should be the whole page that scrolls and not just the small section with the IFrame.
Here's what I did. I used the JS routine Chris posted, where the second line is changed to:
oLinks=document.getElementById(sTargetID).getElementsByTagName("A");
I called the function straight after the field appears. I didn't want to put it in the onload event as this waits for all images to load before firing. There's a chance users will click links well before this happens.
In the previous thread I mentioned wanting to take a shower to wash off the slime after taking advantage of the multiple base tag trick. Looks like MS just threw the cold water on you. And now you know where your towel is. It's in the JavaScript :-)
-rich
Yes, sorry, an IFrame with javascript in the containing form to request the content of the iframe from the google server on load. That step should only be neccessary when data comes from two different domains though as the src attribe for the iframe can be server generated. And you're right. It works for google precisely because the add space is a known, fixed size not prone to scroll.
I think the solution you've got is probably the better of the two given that constraint (scrolling).