JaySmall.com/old

Following is Issue 42 of The Sensible Internet Design Letter [ [url=/index.php?id=C0_4_1]archive[/url] | [url=/MyMail/]subscribe[/url] ].

Getting a fine-how-do-you-do from the Web's most pervasive scripting language, richest design tool.

I am not an expert developer in either [url=http://devedge.netscape.com/central/javascript/]JavaScript[/url] or [url=http://www.macromedia.com/devnet/mx/flash/]Flash[/url]. 'Nuff said. But I work with both technologies enough to know a few tricks for making them behave better within Web sites.

I'm about to share some of those tricks, but only if you promise:

1. To send along any suggestions for improvements or tweaks.
2. Not to call or write asking for technical support to implement these ideas. They're concepts that work for me, on my sites, in my server environments, with my browsers. They should work for you, too, but refer to the first paragraph of this newsletter for the reason I can't be the help desk for these ideas.
3. Not to call or write berating me for misguided applications of, misunderstanding of or general misinformation about either technology -- unless you are also prepared to offer better ideas.

Whaddya expect? It's a free newsletter. So, with those caveats, onward:

Polite pop-ups

Though [url=http://www.greeblie.com/arch/001494.html]Netizens[/url] [url=http://www.zdnet.com/anchordesk/talkback/talkback_191315.html]have[/url] [url=http://forums.teencentre.net/showthread.php?t=4133]long[/url] [url=http://www.simtel.net/product.php?url_fb_product_page=62862]burned[/url] [url=http://jenett.org/asap/]up[/url] [url=http://pub19.ezboard.com/fwarhammerforums27276frm4.showMessage?topicID=18.topic]their[/url] [url=http://pub147.ezboard.com/fmonklybusiness43508frm19.showMessage?topicID=24.topic]keyboards[/url] explaining how and why they hate them -- and Mozilla, Safari, Opera and now the Google Toolbar for Internet Explorer all have blockers for them -- Web designers still have need to create pop-up windows from time to time.

Fine. But the job of launching a pop-up window from a Web page link falls to JavaScript.

Two techniques to launch pop-ups are common. Both work in most browsers with JavaScript enabled. But only one also works in most Web clients that either don't support JavaScript or have it turned off. On my own sites, that means less than 2 percent of the total audience, but others have pegged this number Internetwide at more than 10 percent.

For the JavaScript-able majority, let's say I want to make a pop-up window I'll call jayWin, 300 pixels wide by 200 high, that the user can resize. And into that window I want to place a page on my site called blah.html.

Wrong - the pseudo-link: A pseudo-link activates the Javascript in the href, the portion of the link tag (<a ...>) normally used to say what page to go to when the link is clicked:

<a href="javascript:window.open('blah.html','jayWin',
   'width=300,height=200,resizable=yes');">link</a>

If you have JavaScript and click a link that's formed this way, you'll get the pop-up window in most cases. But if you don't have JavaScript, it's a dead link. You get nothing, and no explanation.

Right - using the onclick event handler: Or you can launch the pop-up using a JavaScript event handler, in this case onclick.

<a href="blah.html" onclick="window.open('blah.html','jayWin',
   'width=300,height=200,resizable=yes');return false;">link</a>

This method tells JavaScript-friendly browsers to open the pop-up when you click the link (onclick, get it?). No JavaScript? No problem. Your browser would still see the page linked in the href and go to that page in the current window. Ahh, that's better!

By the way, I'm far from the first person to discuss the difference in these two pop-up link techniques. If you're interested in the details, read more thorough tutorials by [url=http://www.evolt.org/article/Links_and_JavaScript_Living_Together_in_Harmony/17/20938/]Jeff Howden[/url] and [url=http://diveintomark.org/archives/2002/06/26/day_13_using_real_links]Mark Pilgrim[/url].

Nix pops nicely

Now that you've opened that pop-up window, you might want to provide a link somewhere in it to let users close it. Here it doesn't matter much whether you use the pseudo-link or event handler. The link serves only one purpose: to fire up the JavaScript command to close the window:

<a href="javascript:window.close();">Close Window</a>

But if this link won't do anything for visitors without JavaScript support, why show it to them at all? I suggest using JavaScript to hide JavaScript from non-JavaScript browsers. Confused? Just do the link this way:

<script type="text/javascript">

<!-- //hide from non-javascript browsers

document.write('<a href="javascript:window.close();">Close Window</a>');

//-->

</script>

JavaScript-ready browsers will process the document.write instruction and spit out a working link that will close the window if clicked. Non-JavaScript browsers won't see the contents of this script, and since the contents are worthless without JavaScript support, no harm done except a few extra bytes of data in the page.

This also works, by the way, if you use JavaScript in a link to send the contents of a Web page to a printer. In this example, just to be different, I used the onclick event handler and a pound sign in the href, which has the effect of returning the browser to the top of the current page after printing:

<script type="text/javascript">

<!--

document.write('<a href="#" onclick="window.print();">Print this page</a>');

//-->

</script>

Friendly Flash

I've been working on a trade association site redesign project that's about to launch. Some of the pages have promotional tiles or posters done in Macromedia Flash.

Longtime readers know [url=http://smallinitiatives.com/2003/02/06/iadontahateaflashaiajustahateawhataitadoesatoadesigners/]I don't hate Flash, I just hate what it does to designers[/url]. That aside, I also like to be sure my Web page formatting meets World Wide Web Consortium standards for Extensible Hypertext Markup Language ([url=http://validator.w3.org/]validator[/url]) and Cascading Style Sheets ([url=http://jigsaw.w3.org/css-validator/]validator[/url]).

Unfortunately, the Macromedia-recommended set of tags required to insert a Flash file into an HTML page includes tags (such as <embed>) that aren't part of the standards.

I wanted to find a way to insert those tags for users with Flash players installed, while hiding them from the validator and from browsers with inadequate or no Flash support.

Enter JavaScript again. I started from a [url=http://www.dithered.com/javascript/flash_detect/index.html]script written by Chris Nott and Alastair Hamilton[/url], which detects the presence and version of a Flash player in a browser and puts out different bits of instructions or text depending on what it finds.

I modified the script so that, if Flash Player version 4 or later is detected, the tags to call in a Flash file are inserted. If not, the user gets a simple message indicating the browser won't support the Flash file.

It's a pretty hefty script, so instead of putting the whole thing in the <head>...</head> of every HTML document that needs it, I call it in using a link tag. Then I need a second bit of JavaScript to initiate the main script and put the desired Flash file name, width and height attributes in the right places.

The modified JavaScript Flash detector is here: [url=http://smallinitiatives.com/javascript/examples/flash_detect.js]http://smallinitiatives.com/javascript/examples/flash_detect.js[/url].

The related bit of script that goes in the body of a Web page is here: [url=http://smallinitiatives.com/javascript/examples/flash_load.txt]http://smallinitiatives.com/javascript/examples/flash_load.txt[/url]

But what about ...?

I'm sure you're getting ahead of me now, wondering what happens for people who have appropriate Flash capabilities but no JavaScript capabilities. Right now they see ... nothing. I'm open to suggestions.

It's a Web site manager's gamble. How many people do you know with JavaScript off but Flash on?