1 You must be joking!

Please do not soil the whole idea of this article by using [removed] links which are dead without javascript turned on!

Why not point the links to the anchor in the headline of the section and add the javascript functionality onclick and onkeypress?

[url=”#head”]Link to headline[/url]

<h2 id=“head”>Headline</h2> or
<h2><a name=“head”>Headline</a></h2>

you can either add the handlers inline or you can do that with a nice loop like I explained here:
http://www.evolt.org/cleanmeanjs/ and used for example here:

http://www.onlinetools.org/articles/tourism/

posted at 07:30 am on April 16, 2004 by Chris

2 Easytoggle

Simon Willison wrote easytoggle (http://simon.incutio.com/archive/2003/11/06/easytoggle) which does exactly this, except that it’s easier to implement because it uses unobtrusive DHTML techniques.

posted at 07:35 am on April 16, 2004 by sil

3 Re: Easytoggle

Furthermore, it separates structure from behavior, something you can’t say about this article.

posted at 07:41 am on April 16, 2004 by Anne

4 Not sure about accessibility

Aaron,

The topic of reshaping HTML using DOM has been discussed a few times and it is very tempting to think that by augmenting HTML code with extra features after it is loaded you will be able to coerse certain applications such as accessibility readers into reading the original HTML code that was loaded, not the final version (the one that was modified with JavaScript). Unfortunately, it doesn’t work that way. While it may fool primitive validators such as Bobby, most modern readers will rely on DOM rather than original HTML text to parse the structure of the document.

What this means is that all of your JavaScript spaghetti will end up being read aloud by JAWS and confusing the poor souls who dared to step onto your page.

Don’t mean to be a party-pooper, but thanks but no thanks on the spaghetti-cake.

posted at 07:42 am on April 16, 2004 by Dimitri Glazkov

5 Not sure about usability, either.

Aaron,

Are you sure you want to venture into the territory of simulating a common browser behavior?

When the users click on a link, they typically expect the page to change and view content at the new location. Unless, of course, there is a visual indication (hint) of some sort that the click will reveal a menu or another gadget of that kind.

What you are doing is creating a “virtual browser” — clicking on tabs does not change the URL, but it does change the state of the page. It really is a cool trick, and I can see how this type of sub-navigational freature can be (and is) used in some places, but creating an illusion of a page change, IMHO, is going a little too far.

There are several other questions that arise from implementing such a solution (some of them are easy to address):

• What if I want to see the whole thing and scroll?
• What if I want to bookmark the “Decoration” part? I can do it with other pages on the World Wide Web, why not here?
• What if I click the back button while I am in the “Preparation” page? Why don’t I get to the “Ingredients” page?

• What if I try to open the “Prepartion” link in a new window (shift-click in IE)?

I am not against creating an illusion, but when everyboday can see right through it, they tend to throw rotten eggs at the magician.

posted at 07:57 am on April 16, 2004 by Dimitri Glazkov

6 Maybe I'm missing something but...

this does not seem like a good idea. As mentioned you are recreating a standard browser functionality. Prior to adding the CSS it was a good example of progressive disclosure and, with some tweaking making the entire text visible as an option, potentially useful.

I hate to criticize this as I have done little to actually build the soap box I’m preaching from., but I cringed when I got to the CSS example. It was as if I was using frames again. You’re seemingly simulating multiple pages as far as the user would spatially understand but killing niceties such as being able to bookmark a section.

In a larger scenario a user might want to send a section to a colleague only to end up sending them a link to the parent page; much like the curse of framed content.

It’s a nice and the DOM is great and all-powerful but the examples in this piece may only lead the uninitiated to copy them verbatim and assume they’re doing something good.

In short, maybe I’m letting the examples weigh in too heavily in my reading of this but I’m not seeing the benefits you’re touting.

posted at 08:40 am on April 16, 2004 by Mike Czepiel

7 Maybe not for whole pages, but for widgets

I agree that rewriting the whole page paradigm with some Javascript seems weird. I used my Back button out of habit when I read the examples and I knew how it worked. It would be surprising for most readers.

But this kind of thing might be perfect for a tabbed-container widget within a page. See [url=“http://www.sapdesignguild.org/resources/ma_guidelines_3/index.html”]SAP’s example[/url] (click on Application iViews for an example).

posted at 09:21 am on April 16, 2004 by Andrew

8 CSS only?

In the future when :target is better supported, you won’t even need scripting for this sort of thing. This works in Mozilla now and I’m sure will be in Opera soon enough:
div { display: none;
}
div:target { display: none;
}

posted at 09:27 am on April 16, 2004 by Vinnie Garcia

9 RE: CSS only?

Oops, the :target piece of that code above should be:

div:target {
display: block;
}

posted at 09:28 am on April 16, 2004 by Vinnie Garcia

10 RE: You must be joking!

Chris,

I understand your suggesting against using [removed] in links. However, I think you are missing an important point of the article: The original HTML uses anchors and Javascript is used to rewrite the links.

If users have javascript turned off, then the script that rewrites the links is never run, so all the links use anchors.

posted at 10:28 am on April 16, 2004 by David