easytoggle and debugging in Safari
6th November 2003
I’ve been working on a new inobtrusive DHTML effect: easytoggle, which is an inobtrusive implementation of the common effect where links or tabs can be clicked to reveal part of a page while hiding the other parts. It’s similar in some ways to the Multi part forms with Javascript technique.
The idea is pretty simple—all you need are a bunch of links and a bunch of elements that should be toggled by those links. When adding special behaviour to links it is always a good idea to ensure that they still link to something sensible, so that in user agents without Javascript support they still do something useful. In this case, it makes sense for them to act as anchor links that point to the elements with which they are associated. With easytoggle, all you need to do is define the links, point them at an element with an ID and assign them the class ’toggle’. The script does the rest of the work. For example, for a simple set with only two panels the markup would look something like this:
<ul>
<li><a href="#p1" class="toggle">Panel 1</a></li>
<li><a href="#p2" class="toggle">Panel 2</a></li>
</ul>
<p id="p1">This is panel 1</p>
<p id="p2">This is panel 2</p>
That’s all it takes—the demo has a very slightly more complicated example.
I thought it was finished, until I tested it in Apple’s Safari browser. In Safari, the worst possible thing happens. The initialisation code which hides all of the panels after the first one works fine. Unfortunately, the code that causes the links to change which panel is visible fails silently, leaving only the first panel accessible to users with that browser. That’s a big problem.
It was at this point that I discovered that Safari’s support for debugging Javascript sucks rocks. Firstly, the browser gives no indication that a bug has been encountered. I’m sure this is a deliberate usability decision, but it also means users who encounter a bug won’t even know that there is a problem with the site. A quick Google led me to this page, which told me how to enable Javascript error reporting:
- In a command line shell, execute
defaults write com.apple.Safari IncludeDebugMenu 1
(apparently Safari Enhancer lets you do this from a GUI). - Reload Safari and check the “Log Javascript Exceptions” option in the newly enabled Debug menu.
- Start Console.app, which lives in /Application/Utilities. Note that this is not the same thing as the command line console. This took me a few moments to figure out. Macs remain a strange new realm of discovery.
- Javascript exceptions will now appear in the Console.app window.
Excellent—just what I needed to know. The entire error message I got when I clicked a link? (event handler):Undefined value
. Gee, thanks a lot Safari. If anyone has any ideas how I can fix the script in Safari (or at the very least prevent it from being unusable) please leave me a note.
Update: Thanks to a tip from David Lindquist, the updated version of the script now works in Safari. It’s a little bit uglier though.
More recent articles
- Weeknotes: Llama 3, AI for Data Journalism, llm-evals and datasette-secrets - 23rd April 2024
- Options for accessing Llama 3 from the terminal using LLM - 22nd April 2024
- AI for Data Journalism: demonstrating what we can do with this stuff right now - 17th April 2024
- Three major LLM releases in 24 hours (plus weeknotes) - 10th April 2024
- Building files-to-prompt entirely using Claude 3 Opus - 8th April 2024
- Running OCR against PDFs and images directly in your browser - 30th March 2024
- llm cmd undo last git commit - a new plugin for LLM - 26th March 2024
- Building and testing C extensions for SQLite with ChatGPT Code Interpreter - 23rd March 2024
- Claude and ChatGPT for ad-hoc sidequests - 22nd March 2024
- Weeknotes: the aftermath of NICAR - 16th March 2024