Reinventing Fire

Idiri Firefox Extension

July 31, 2007

Filed under: Browsers,Technical — Magister @ 7:29 pm

Firefox is my browser of choice. I really like Opera, and it has excellent SVG support, but I’m a creature of habit, and I can’t shake using Firefox. One of my favorite things about it is that you can trick it out to fit how you use it. I’ve installed quite a few Extensions (community-made bits of browser functionality) that I use all the time. They have become such a part of my browsing experience that I have even forgotten they aren’t standard, and when I had a hard-drive crash and had to reinstall, I was a bit at a loss why FF didn’t have some of the core functionality I’d come to rely on… until I reinstalled the extensions. I’ve even made one for my last employer, and in my spare time, I’ve been working on an image- and SVG-specific extension for Firefox, which I’ll be releasing shortly.

One of the other things I love about FF is the context-menu option for “View Selection Source”. I use it to figure out how certain bits of a document are marked up (though I also use Firebug for that). In my standards work, I also find myself needing to cite particular sections of large documents, such as technical specifications or documentation. I cite them to point out errors, to show where a bit of functionality is specified, to help out people with questions by pointing them to a reference, to defend my interpretation of a technical issue, and all sorts of other geekademic occasions. Since these documents are usually quite long, it’s necessary to get as close as possible to the relevant section when supplying a link, and fortunately, specifications tend to be very well marked-up, with logical document structure and plenty of ID attributes for ease of linking. View Selection Source is really great for that, because I can select a section header, open up the partial source in a new window, find the id, select it, append it to the original URL preceded by an octothorpe (“#”), and use that as a reference link; of course, sometimes the id isn’t where you expected it to be, and you need to look around for it a bit…

Okay, you see my problem. As relatively easy as View Selection Source makes the task, it’s still a bit… shall we say, labor-intensive. To be honest, it’s not quite as cumbersome as it sounds, and I’m so used to having to kluge around like that when programming that it somehow never occurred to me that it could be easier.

It just got easier. I spent a few hours putting together a Firefox Extension that automates this process. You just right-click on the section you want to link to, and select “Copy section link”. Idiri, my extension, automagically finds the nearest preceding link to where you’ve clicked, and copies it to your clipboard. It also highlights the element that it found an id on, as a visual indicator that it’s done its job and to let you know where you’ll be linking to. Simple.

You can download Idiri (from “id” for identifier, and “iri” for “internationalized resource identifier”, a fancy way to say URL or Web address), and let me know what you think. More details below…

I don’t know if this will be generally useful to most people. I think other standardistas will use it for specifications. I’m not sure how well (or how consistently) other documents of the Web are marked up, so it could be kind of a niche use case, but I’m hoping it does someone else some good. I know it doesn’t work with Wikipedia (or any other MediaWiki-based site) because they use a rather eclectic markup, but maybe I’ll solve that in a future version.

In case you don’t quite know what I’m talking about as far as section linking goes, let me explain. You’ve probably seen this before: you click on a link, and it jumps to a specific section of a page (in the same page or in a new page), rather than the top. The Web address looks something like this: http://www.w3.org/TR/html401/intro/intro.html#fragment-uri. The last bit, after the “#”, is called a “fragment identifier”, and it indicates a subsection of the document. Hidden behind what shows in the browser, there is code called markup that classifies the text (which may change the visual appearance, such as making it bold with a larger font size, or may just tell the browser to treat it special without changing how it looks). There’s a couple different ways of marking a section as linkable in this way, but the modern method is to simply use an id attribute on any element (Wikipedia uses the older way, an <anchor> element, for backwards compatibility with older browsers). Idiri finds these ids systematically, by looking first at the element you clicked on, then at each of the previous elements, and then to the parent element, etc., until it finds an ID; if it doesn’t find any, it just gives you the bare IRI.

Comment and suggestions are most welcome. Also, if you can think of a way to make it accessible, please let me know, since right now it’s only a context-menu option.

Update: I thought of a reasonably clean way to catch the majority of cases where an anchor element is used instead of an ID (as in MediaWiki), so I updated Idiri. I’m sure it still won’t catch all cases, but it should work a little better.

8 Comments

  1. Hy Doug, I do the kludge you mentioned multiple times a day. Heck, multiple times an hour. This is a great productivity extension.

    Mind you, other browsers don’t even have ‘view selection source’ yet.

    Comment by Chris Lilley — August 2, 2007 @ 8:46 am

  2. Hey, Chris-

    Yeah, I think that it would be great to see “View Selection Source” in Opera, Safari, and IE, too… but honestly, since I made this extension, I’m not sure how much I’m going to use it anymore. I’m frankly surprised that Idiri’s functionality isn’t standard in browsers already (and I hope it will be).

    I updated Idiri to fix some bugs that would make it fail silently and seemingly randomly… v1.1 is much more robust, and now it seems to work very consistently with a wide variety of documents, including Wikipedia and its kith and kin. Then I spent another hour on it for v1.2 to add the ability to select text, and have both the section link and the text selection copied to the clipboard (as text, not as markup). If you don’t select text, it just copies the section link, as before.

    Writing extensions is a lot of fun. I’ll keep my eye on other standardista productivity features I can throw together.

    Comment by Schepers — August 3, 2007 @ 12:59 am

  3. Uploaded v1.4, which covers anchor-style links and name attributes (as opposed to ID attributes) more robustly. Thanks to Fantasai for pointing me to CSS2.1, where it wasn’t working before. v1.3 was mainly a bug-fix for documents without anchorpoints (element IDs or names).

    Comment by Schepers — August 3, 2007 @ 11:42 pm

  4. Very cool. I use the same “View Selection Source” thing all the time to grab the name or id when I link. I’m not a standardista but I link to standards, wikis and whatnot in my blog all the time. Having “Copy Section Link” on the context menu saves me another step, thanks.

    Comment by Rob Russell — August 30, 2007 @ 4:50 pm

  5. Hey Doug,

    I agree – this functionality should be part of the standard browsing experience. Especially with small screens becoming the norm – how many times have you linked to a document and said “search for XXXX”. This becomes increasingly important as the mobile web continues to accelerate.

    In that vein, I had started an extension to add XPointer support to Firefox for HTML documents – then Rob turned me on to your extension. Anyway, FXPointer works in a very similar way but allows you to link to an arbitrary section of a document – even if there are no IDs in the doc, like some guilty W3C specs ;)

    Anyway, at the moment it only supports the element scheme (which is sufficient for “frozen” documents like specs), but I hope to continue to expand it to support the xpointer scheme one day.

    It’s still very much in a ‘pre-Alpha’ state but check it out. Oh, also there are equivalent Opera UserJS that allow the same functionality (though less integrated).

    Comment by Jeff Schiller — October 30, 2007 @ 8:24 am

  6. [...] The Opera web browser really puts the other guys to shame when implementing open standards. I wholeheartedly agree with Doug that it’s a shame that I can’t customize Opera’s chrome the way I can with Firefox (you can only go so far with User JavaScript and widgets) – it would easily become my default browser (and not just the browser I test advanced features in). Anyway, those guys at Opera have released a development build of Opera 9.5 that supports video in the browser. This is a big step forward for the open web. [...]

    Pingback by Something Witty Goes Here » Opera 9.5 Beta: Now With Cracklin’ Video — November 9, 2007 @ 7:32 am

  7. There is other one neat functionality in current Firefox you apparently wasn’t aware of: built in window.find() method, which is, in fact, just an API for “that old-fashioned Ctrl+F” dialogue and its action. When I accidentally found this, I’ve written userscript which uses it for (what else, than :] ) pointing to phrases in pages.
    Recently I’ve, also accidentally, got knowledge of xPoniter (googling for “anchor xpointer firefox” brought me to this gorgeous site) and its implementation in Firefox (for XML). Gonna install “FXPointer Extension” right after posting this comment :]

    Comment by Michal Čaplygin — January 12, 2008 @ 12:55 pm

  8. I think these other extensions that pinpoint specific words are great examples of web technology, but I stand by Idiri. Idiri relies only on the lowest-common-denominator of Web resources: the link and anchor. A link composed by Idiri works in pretty much any browser. It doesn’t depend on the link recipient having a specific browser feature or extension.

    Heck, a link from Idiri even works in Internet Explorer! And probably even Lynx.

    Another challenge with word-index systems like “find” or certain applications of XPointer is that content is often more mutable than structure. Let’s say you point me to a typo by linking to a specific misspelled word… that link is dereferenced once I fix the typo. (Ooooh, a paradox! er…) Also, revisions or different versions of a document may change where a word is located, or the frequency of that word. While in a way this makes the word-indexed link more likely to resolve to some content, it also means that it may not point to the content intended.

    I think there are benefits to both approaches, but the robustness still makes me prefer Idiri. Oh, that, and the fact that I wrote it.

    Comment by Schepers — January 13, 2008 @ 6:25 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress