by Danny Goodman
Managing browser-specific features has been a
problem for Web authors and Web masters ever since the first HTML extension
found its way into early browsers. With each new generation of modern browsers,
the universe of visitors to our pages fragments ever more, forcing us to
make difficult decisions about how to treat a variety of browsers. If you're
to sorting out browser versions.
Another dream tactic is to employ a script to
too, isn't possible: Any standard HTML in a document will appear in all
DETERMINING THE REAL NEED
I believe you can adapt one of these methods to
fit most script vs. non-script situations -- including those that might
otherwise seem hopeless. Solutions range from the very simple to ones that
take a fair amount of forethought and careful execution. In all cases,
A BRANCHING INDEX PAGE
In keeping with my belief that scripting should work silently in the background, without great fanfare, I avoid deploying index.html pages that rely on the site visitor knowing about his or her browser. While Web page authors are extremely sensitive to browser brands and levels, the increasingly large audience of non-nerds surfing the World Wide Web has little, if any, emotional attachment to the browser being used at any moment. To provide an index.html page with two or more links labeled for specific browsers won't help someone who doesn't know exactly what's inside his or her WebTV box.
(Aside: The height of geek bravado must be a site I visited recently [URL withheld so as not to embarrass the page's author] that provided a link labeled for users who had browsers that were HTML 3.2-compatible and a link for those whose browsers weren't up to that level.)
But you can craft the index.html page to branch to many different tracks through your site. The tactic is based on first displaying a nearly content-less index.html page that isn't the true home or welcoming page to your site. Instead, it displays a lone image of any size (perhaps a logo) in the same page location as that image appears in the true home page for each of your browser-dependent tracks.
Let's look at a typical index.html page that provides branches to two tracks in a site: A scripted track that starts at home1.html and an unscripted track that starts at home2.html. The HTML is shown in Example 1.
Let me add the following four points about Example 1:
destination as follows (as you normally would):
<A HREF="nonJSCatalog.html">Product Catalog</A>
page, you need to add a special enhancement to the onClick= event
handler for this link: return false. Just as a form's onSubmit=
event handler cancels the submission of the form if its final statement
evaluates to return false, so, too, does a link ignore the HREF
attribute if the onClick= event handler ends that way. Therefore,
<A HREF="nonJSCatalog.html" onClick="location='JSCatalog.html';return false">Product Catalog</A>
Without the return false statement, the
visitor will end up at the HREF attribute's location. You can still add
onMouseOver= and onMouseOut= event handlers to the link to
In Example 3, the button object does not have
an explicit event handler in its tag. Instead, the reference to the
doIt() function defined earlier in the document is assigned to the
onclick property of the button. (The property name for an event handler
is always in lower case). The <SCRIPT> tag for this assignment must
come after the <INPUT> tag that creates the button to make sure the
button object exists before its event handler property can be set. In the
to user action in any way.
This technique won't work all the time, of course.
or the user will see next to nothing on the page. But it means that I can
keep the need for parallel pages at a minimum, simplifying the maintenance
THAT ELUSIVE SCRIPT