Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
The Internet

Journal aWalrus's Journal: Method for Improving anchor functionality

Anchors are sweet. But they can be troublesome. After taking a look at modulo 26's current Daily Flight, and recognizing the topic as one of my pet peeves, I was extremely pleased to see their suggestion for improving the anchor functionality. It's elegant and well thought out. However , I think the javascript that they provide could use some improvement.

Andy's code seems straighforward enough, but it has a big problem: It requires the use of two different id's for each anchor. One for the anchor itself (the one that will be used in the href) and one for the visual cue element (the one that contains the arrow / pointing device). This could rapidly become a hassle in a large document that includes links to multiple sections. We'll try to provide a simpler solution.

Our main intent is to make life easier for the designer, not necessarily for the developer (that's what geeks are there for after all, right?). Thus, we won't mind if we make a mess of Andy's nicely simple code. Also, we'll toggle a class attribute instead of an inline style. Because we can (and it scales better).

First off, we eliminate the need for a separate id to identify the visual cue. This allows us to have a standard cue element that we can add to all anchors. It will look like this:

<span class="alt">&#8658;&nbsp;</span>

The "alt" class is my css class for "alternative" elements. It has display:none; set, so it's not rendered by the browser. The ugly number is the right-pointing arrow character "" (you may see a square if your browser is not using Unicode). The other thing is a non-breaking space.

The lack of id introduces a new problem: what if there's more than one <span> inside the element we want to go to?. To solve this, we'll use extra functions provided by the DOM spec to fetch our visual cue element. Instead of trying to get to it directly, we'll get our anchor (for which we already have an id) and ask it for its inner <span> elements. Thus, instead of

cue = document.getElementById(cueId);

we'll have

anchor=document.getElementById(anchorId); spans=anchor.getElementsByTagName("span");

This returns a list of nodes [?] that we can go through. When we reach the one we want (we recognize it by its class attribute) we'll toggle its class by changing the className value. To be honest, I'd rather use

element.setAttribute("attr","value");

for consistency, but that call is not compatible with ie5.0/ie5.5 for the class attribute in particular.

The finished (and heavily commented) code can be seen here . The end result is that we need only specify an id for the element we're referencing with our anchor. The visual cue is placed in a <span> inside said element, regardless of what it is (it may be a <div>, <h1> or another <span> for all we care) and our call looks like this

<a href="#anchor" onclick="toggleAnchor(this);">...</a>

Notice that we pass the this keyword as parameter. That gives the script a reference to its caller, allowing it to read the href attribute of the caller to get the id of our anchor.

To see the script in action, go to the permanent original location of this rant here (because Slashdot does not allow this sort of thing going on in its pages).

Thanks galore to Andy Arikawa for his fine method. Hopefully you'll find this addition to it useful.

--- permalink for this entry at Overcaffeinated

This discussion has been archived. No new comments can be posted.

Method for Improving anchor functionality

Comments Filter:

I've noticed several design suggestions in your code.

Working...