Noscope

Using Named Anchors in Flash

April 24th, 2004 by Joen flash, webdesign

Named anchors have existed on the web since early iterations. They are used to jump between sections of one page, most commonly seen as “back to top” links linking to “#top”.

For an example of how named flash anchors work, you can view My installments.

Flash got the ability to use named anchors in version 6 (or MX), as part of a larger focus on usability. Macromedia promised the ability to deep-link, bookmark, and use the browsers “back” button.

While they, technically, delivered what they promised, it didn’t really work as well as it could have. Thus, I haven’t seen named anchors used in a Flash presentation… ever.

1. The Problem

Well, first of all, it doesn’t work in Mozilla out of the box. You have to script your way out of it, which I will explain later in this article.

Secondly, the “back-button”, doesn’t work properly. Quite simply, a history of visited anchors is not kept up to date, meaning the back button will take you back to the previously Flash-authored anchor, not the correct past history state. Additionally, due to the JavaScript nature of Flash anchors, the back button might not always refresh the content.

*Note:* While there are solutions to making the back-button work, they are fairly complex, and beyond the scope of this article. Instead, I’ll refer you to other articles at the end of this one, that may solve that problem.

Finally, and probably the most important reason for named anchors not being adopted, is that they link _directly_ to the frame that has the anchor, meaning that any actionscript, preloading & other use of non-linear animation in Flash will not be triggered. Fortunately, this issue can be solved.

2. Benefits

Despite the above-mentioned cons, named anchors are still worth your time, because:

# They add usability
The end user is used to how the browser works, not necessarily how Flash sites work. Using named anchors will bring the experience closer to how websites are supposed to work

# They allow bookmarking
Visitors will bookmark things they like. Maybe they’ve found an article, or an image they like, and they’ll bookmark it. If this bookmark doesn’t later on take them where they expect to go, it’s bad karma.

# They allow deep-linking
Today, many websites spread via blogs, instant messaging & email. If people can copy your URL and paste it into their email or instant messaging client, or link to it via their blog, they will. But only if the link is deep, meaning it will bring you to the location where they copied the URL.

# They do not interrupt the flow of Flash
Music can play un-interrupted over several named anchors, when running in Flash. This means that, without using HTML frames, you can link to new URLs in your document, yet not stop the music playing. This was the main reason for using named anchors in my installments.

3. Creating Named Anchors

Making named anchors in Flash is as easy as pie:

Quite simply put: when you make a framelabel in Flash, you can tick off the small checkbox below the label name that says “Named anchor”. This will make the framelabel look like this:

For Internet Explorer only users, this is all you have to do.

3.1. Making it work in Firefox and other browsers

By default, the above mentioned code works in Internet Explorer.
For it to work in Mozilla and other browsers, we need to do some simple javascripting.

First of all, we need the script. It’s built-in to one of the Flash Publish templates, so let’s use that:

Publishing with this template, will add the following code to your document:

// This is only needed for Netscape browsers.
function flashGetHref() { return location.href; }
function flashPutHref(href) { location.href = href; }
function flashGetTitle() { return document.title; }
function flashPutTitle(title) { document.title = title; }

This javascript (when invoked) changes the addressbar to reflect the framelabel we’re on, as well as change to document title.

I personally added this code as well:

// Store document title so we can retrieve it
docTitle = document.title

It stores the current document title in a variable. The reason for this is, we’ll be changing this document title later on to reflect the named anchor. But instead of replacing the entire document title, we’ll just add it to what is already there.

With this javascript added, we’re close to the goal, but not there yet. We must call upon this javascript from within Flash. To do so, add this action to every anchor frame you have:

getURL("javascript:flashPutHref('#myframelabel');flashPutTitle(docTitle+' - myframelabel');");

… replace “myframelabel” with the label name of the anchor frame.

This code works in mozilla, but breaks Internet Explorer. What now? We must make sure this code is only run when not on explorer.

After some testing, I’ve found that systems that do not have “accessibility” usually need the code. Thus, the following code will make sure the javascript code is only run on systems that need it:

if(System.capabilities.hasAccessibility != true) {
getURL("javascript:flashPutHref('#myframelabel');flashPutTitle(docTitle+' - myframelabel');");
}

Perfect! This code will manually change URL and Title to reflect the framelabel we are on, but only in browsers that doesn’t do it automatically.

3.2. Update, May 6th 05: The Problem with Safari

Recent events have shown that Safari is having problems with deep links to named anchors. To put it simply, if Safari directly visits a named anchor such as @flashcontent.html#named_anchor@, it will go into an infinite loop. It seems that the either there is a bug in Safari, or it is simply the only browser that has problems with the JavaScript mentioned in section _3.1_. I hope to find a solution to this in the future. Until then, a quick fix is to use the following ActionScript in place of the ActionScript mentioned in the end of section _3.1_:

theOS = $version.substr(0,3)
hasAccessibility = System.capabilities.hasAccessibility
if(theOS != "MAC" && hasAccessibility != true) {
// Safari can't handle anchors, so we'll disable'em
getURL("javascript:flashPutHref('#"+theImage+"');flashPutTitle(docTitle+' - "+theImage+"');");
}

4. Utilizing “frame 1″ actionscript when using named anchors

As mentioned, Flash jumps directly to the named anchor, and skips any initial actionscript. This is a serious problem when working with actionscript. Nobody wants to have a new copy of all your actionscript on every named label…

The solution to this is using the benefits of the named anchors, but not following their rules to the dot. For instance, in the named label frame, type down a variable containing the name of the label, and send it to frame 1. Frame 1 will then distribute accordingly.

For instance, frame 5 has the named anchor “gallery”. When linking to mypage.html#gallery, it jumps directly to this frame. But gallery needs the actions in frame 1 (which it skipped jumping there). So instead of having the “gallery” framelabel actually be in the “gallery” section, we merely make it a dummy frame that stores where we want to go, and goes there later on. To do this, we type the following code in the dummy “gallery” frame:

theFrame = "gallery";
gotoAndPlay(1);

This stores the name of the frame we landed on in a variable, and manually proceeds to frame 1, where it gets all the actionscript it needs. Now that it has this actionscript, we want to send it to the REAL gallery section. To do this, we could use the following code:

gotoAndStop("real_"+theFrame)

This would send us flying to the frame label called “real_gallery”, just like we wanted from the beginning. This combines the best of two worlds.

5. References

* How to make the back button work in Flash, by Robert Penner.
If you want the back button to work perfectly, it currently seems as though the best solution is to use Flash’s @localConnetion@ (Thanks Udo).
* Enabling a back button within Flash
(Thanks Jason)
* Macromedia: Pet Market Back Button
(Thanks Udo)

6. Conclusion

Flash’s Named Anchors feature indeed promised more than it could deliver. Even so, with some work, some patience and a little help from your friends, they can help out immensely.

It is also important to note, that if you don’t mind that it won’t work on all browsers and the back button behaves a bit strangely, then you don’t have to read past section 3. It really should be enough.

Let’s hope that’s the case for all browsers in the future.