Window, dot open

Tuesday, May 24

The topic of opening new windows seems to come up pretty often, so I’ll attempt to provide a clear answer for everyone.

Frustrated designer writes:

I need to open up a new window and customize it’s appearance (i.e. remove the status bar). Ordinarily, this would be achieved with the help of JavaScript and Window.Open()—so much for cross-browser compatibility. Then there’s the old target=”_blank” anchor attribute, but this is disallowed by the DTD I’m using (XHTML1.1), that… plus it doesn’t offer a way to get rid of browser UI elements. What’s a jerk to do?

The short answer

Use the window.open() method defined as follows: window.open( URL, name [ , features [, replace ] ] ) making sure you create a valid anchor element with a valid href attribute. Instead of specifying the URL argument manually, use the DOM to read your href attribute like: this.href.

It should look like: onclick="window.open(this.href, '_blank'); return false;"

The long answer

Stick to what you know: create a standard anchor element with an href to your URL. Next, change this link so that it makes use of the onclick handler to call jabbascript’s window.open() method with a few arguments. We also need to make sure this onclick returns false to instruct the browser not to handle the link on its own.

Accessiblity gurus, please note that this is perfectly accessible despite the use of jabbascript. Even with jabbascript turned off in the client, any self-respecting browser will just handle the hyperlink as usual (because we have a ‘normal’ anchor element, right?).

If jabbascript is turned on (and come on, why should it ever be turned off?) it will respond to the onclick event and all will be right with the world.

You knew an example was coming, didn’t you?

onclick="window.open(this.href, '_blank'); return false;"

The explanation:

The first argument, this.href is key: By using this.href, we are accessing the value of the current element’s href attribute using the DOM. This means we don’t need to supply window.open() with the url manually—we stay DRY by using the href attribute in our link.

The second argument (the ‘name’ of the new window to be created) is given the special name (“_blank“) which serves to inform window.open() that it’s mission is to launch a new window (duh). Think of it like using <a target="_blank"> in older versions of html. Now stop thinking about it entirely.

Note again the return false follow-up to our call to window.open(). This is important as it prevents the browser from handling the link itself—If the onclick handler doesn’t return false, the browser will handle the click normally, and both windows will wind up at the url specified by the href attribute.

Controlling attributes

For those interested in controlling the attributes of the new window, there is an optional third argument that window.open() accepts—a string of properties for the new window.

Here’s an example of a call to window.open with the properties argument:

onclick="window.open(this.href,'_blank','width=500,height=500, menubar=no'); return false;"

It’s probably worth noting that, as per the xhtml spec, you need all your attributes to be lowercase (including attributes that pertain to event handlers). So, while onClick may work in most browsers, you’ll need to use onclick if you want xhtml compliance.

The end

While I generally try to avoid creating new windows for reasons I don’t care to get into, I do on occasion use this method as a straight-up replacement for target="_blank" when appropriate.

My dog’s breath smells like cat food.

DNS Cache Plotting

Sunday, May 08

My internet provider’s DNS servers are slow. At least, this is what I had come to believe when I set out in search of better ones. Aside from the fact that fast, reliable, public nameservers are scarce, I came away with more questions than I went in with.

I run a small network in my apartment building using a D-Link 802.11g router which lets me set nameservers that override any defaults that might otherwise have been garnered from my internet provider. My wish was to find a pair of addresses that I could query for once and for all and use them as my default servers at the router level.

A search for “public+name+servers” uncovers OpenNIC’s Public Name Servers but their site confuses me, especially when I read directly above a list of server addresses that,

...users may not query these servers directly, as they are intended for terminating recursive queries by the user’s nearest Tier 2 server.

If users aren’t permitted to query them, why are they listed on the public dns server page? What happens if I do use them—will I get in trouble? Further down in the page, there is a list of Tier 2 servers but there are none geographically close to me. Still, I tested them anyway and concluded that they were slower than my providers.

Frustrated, I had the sudden idea of using http://dnsstuff.com’s ISP Cached DNS Lookup to see which elite dns servers were considered ‘popular’ enough to have made the shortlist. The example above (google.com) produces acceptable results – most servers queried have this popular domain name cached and don’t need to look it up. The query times are also reasonable – if you look closely, you can start to see a pattern emerge. Some servers are ‘faster’ than others. Factor in the cache time too—the shorter it is, the more likely your queries are to be accurate.

In the google.com race, 14 of the 51 servers have a cached answer. Unless I’m horribly mistaken, this is a good thing. Why bother the root servers for such a common query with an ip address that’s quite unlikely to change?

Consider this query of backpackit.com. As of the time of this writing, only one server has this domain cached.

I began querying additional domains with increasing obscurity to observe the cache to popularity ratio and found interesting results. Mainstream domains, such as google.com, hotmail.com, and cnn.com are nearly always cached followed by domains like slashdot.org, which are cached by about half of the servers. Less popular domains like flickr.com, and del.icio.us are cached in only about one quarter of the instances, and finally domains like shiftmedia.net or even backpackit.com are not cached at all.

The list of knowledgeble servers whittled away as I offered more and more contenders – ibm.com, sun.com, textdrive.com, mozilla.org, debian.org, and my final query—rubyonrails.org – left only two servers remaining: SpryNet and UUNet, whom I pronouce the hippest domain name servers ever, for now.

Words

Sunday, May 01

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell. —William Strunk Jr. in Elements of Style, 1959

Bookmarklets

Sunday, May 01

I’ve been digging javascript a lot lately. Yeah, it’s always been around, lurking in the shadows of web development, but I’d never learned more than I needed to get by—open a new window here, select a group of checkboxes there, etc.

Inspired by the javascript remoting (AJAX) usage in Gmail, flickr, and all the apps resulting from the not so silent Ruby on Rails revolution, I’ve been mucking around with the old jabbascript more than ever.

I’ve also been reading a lot of other people’s work and making silly bookmarklets and things in my spare time for no good reason. If you don’t know what a bookmarklet is, then I’m not going to explain it. Move along.

New Instiki Page

Even though Backpack is quickly replacing Instiki for me, I still use Instiki a lot. This bookmarklet makes it easier to create a new Instiki page by using your selection as the title of the new page or prompting for one if there is no selection. Think of it like having a Backpack-style ‘Make a new page’ button for Instiki!

Tip: this bookmarklet assumes your Instiki wiki is running at http://localhost:2500/wiki/ if yours is not you’ll have to edit it (the bookmarklet, that is).

javascript:q = %22%22 + (window.getSelection ? window.getSelection() : document.getSelection ? document.getSelection() : document.selection.createRange().text); if (!q) q = prompt(%22[Instiki] You didn't select any text. Enter a page name:%22, %22%22); if (q!=null) location=%22http://localhost:2500/wiki/new/%22 + escape(q).replace(/ /g, %22+%22); void 0

Google Maps Search

Takes the current selection as a street address (i.e. 19 Strathcona) and then prompts for a city and state/prov (i.e. Fonthill, ON). If you don’t make a street selection, you’ll get prompted for one. I made this when my wife and I were searching for houses this spring and I wanted a quick way to look up addresses that I’d selected from the various real estate sites were were visiting.

Tip: you should customize this so it includes the city/state you’re likely to use most often to save yourself some typing.

javascript:q = %22%22 + (window.getSelection ? window.getSelection() : document.getSelection ? document.getSelection() : document.selection.createRange().text); if (!q) q = prompt(%22[Google] Enter a street address:%22, %22%22); c = prompt(%22Enter an city, state/province:%22, %22Anywhere, AZ%22); if (q!=null) window.open(%22http://maps.google.com/maps?q=%22 + escape(q) + %22, %22 + escape(c)); void 0

Whois Lookup from dnsstuff.com

Sometimes it’s handy to get whois information for the domain in your browser’s address bar. This bookmarklet will do just that, courtesy of http://dnsstuff.com.

javascript:location.href=%22http://dnsstuff.com/tools/whois.ch?ip=%22 + location.host + %22%22;