Wandering Thoughts archives

My likely Firefox 3 extensions

My current personal version of Firefox is more than a little bit behind the times, so I've been looking at upgrading to Firefox 3 (I compile my own version with various hacks, and it's easiest to build from the bleeding edge CVS sources). As a result, I spent part of today trying various of my essential extensions to see which of them still work.

Here's the current state of affairs:

• NoScript has been updated for the current Firefox 3 beta and works fine. It's under active development.
• Nightly Tester Tools has also been updated for Firefox 3. All I use it for is overriding extension compatibility testing, which works fine.

• Stylish and CookieSafe only claim compatibility with earlier Firefox 3 versions, but seem to work fine anyways.

• All-In-One-Gestures works but has at least one glitch, where the close window gesture (one of my most used gestures) now only closes tabs. Unfortunately it hasn't been updated since 2006, so if I want full Firefox 3 compatibility I'll have to do it myself (and I may well).

Since I'm addicted to both mouse gestures and scrolling pages with the middle mouse button, I'd probably need both Grab and Drag and FireGestures to really replace AiOG. The good news is that both have been updated recently and have some degree of Firefox 3 compatibility already.

I no longer care about the PrefBar extension; these days, when I want to browse without my filtering proxy I just fire up the system version of Firefox with a different configuration.

(I've found it very handy for testing to have a more or less stock Firefox setup that doesn't keep any state. As a bonus, it's good for browsing random sites that want JavaScript, cookies, and so on without having to care what they're going to try to stick me with.)

An idea: only use URL fragments as an implementation detail

There are a number of awkward things about URL fragments, including that they commit you to a certain implementation of your page structure if you are going to provide cool URLs. At the same time, I believe that they're the only way to make a reference to a part of a page, so they're pretty essential if you want to aggregate information on a page but still be able to point to specific bits.

For example, WanderingThoughts uses URL fragments to point to the comments on a specific entry and to point to specific comments; as a deliberate decision, comments only get shown all together and with the entry itself. As usual when software uses fragment identifiers, the URLs that DWiki to point to a page's comments or a specific comment directly include the URL fragment itself.

The more I think about this, the more I think that it is a mistake. URLs that appear in browser address bars are public, but URLs that appear in <a href>s are even more public, and that's not what I should be encouraging with URL fragments.

My current idea on the way out is to make the official URLs for these things be synthetic regular URLs in some appropriate format, and have these synthetic URLs generate HTTP redirects to the actual URL fragment version. This tries to turn the URL fragment itself into as much of an implementation detail as possible, so you can later change things and have at least some URLs keep working.

On the other hand, this might be an unnecessary complication given that it doesn't completely solve the issue, since people will still see the fragment in the URL when they get to the actual page (and bookmark it and so on).

A small annoyance with HTML

One of the things I don't like about HTML is its peculiar restrictions on anchors (<a> elements), specifically named anchors. Named anchors are what you use to specify the target of '#fragment' URL fragments, and the restrictions matter because they constrain where you can point such fragment URLs.

There are two annoying restrictions: anchors cannot be nested, and anchors must include something inside them; they cannot be empty. That anchors cannot nest constrains your ability to make a fragment target wrap arbitrary content, for example a sentence, since the sentence might contain links.

(If you want to wrap an anchor around just a link, you can merge the two by putting the 'name=...' on the link <a>. But this doesn't work if the link is only part of the text you want to anchor to.)

That anchors must contain something clashes with the fact that often anchors are logically attached to positions, not things. Attaching them to a thing related to the position works, sort of, but it is an annoying hack. I do not want to anchor to the first word or letter of a paragraph; I want to anchor to the start of the paragraph itself.

(Technically you can make arbitrary elements into named anchors by giving them a suitable id attribute, except that this may have other side effects. And it only works at the start of elements.)

I will freely admit that both of these are more of a problem for systems that automatically generate HTML (like mine) than for people who are authoring it by hand.