Markus Siebeneicher devised a document format to allow a webmaster to express the structure of his website – i.e. a sitemap – in a medium-independent way. He also wrote a Firefox extension, Navibar, that would take this sitemap and display it as a sidebar. This would help a webmaster to factor out repetitive navigation menus from all his pages, and separate the style of navigation from its content, e.g. an alternative extension might pop up a menu from a toolbar.
The extension was first released probably around mid-2005(?).
If a new, maintained extension using an existing or new sitemap format appears, please let me know! Not A9 SiteInfo, though, unless it improves. (Actually, the format isn't bad; just the extension that reads it.)
In fact, a new project has appeared. You may prefer to switch from Navibar to Standard-Navigation (although it's still in development) which I've got myself involved in.
Someone commented that they'd rather invest their time into
creating a good menu with xhtml/css
instead of learning to
write a Navibar sitemap file. Fair enough, but my experience of
navigation menus built into pages is not good – they take up
valuable space (often in some atrocious fixed-width design), and
there's no way to turn them off, being completely coupled to the one
way in which they are presented. They also tend to be repeated on
every page in the site, and often appear first in the page (after
turning off the bad CSS), so they get in the way of the actual content
lower down the page.
On the other hand, a sitemap file is a way of separating style/presentation from content. The Navibar extension presents the sitemap in a sidebar. Another extension could be written to present it another way, e.g. as a menu button. A speaking browser could present the links in a way which clearly indicates that they are for site navigation, because it can directly infer that purpose from the sitemap file – something it can't do with an embedded HTML menu. In summary, the visitor chooses how the sitemap is rendered, if at all.
Here's what I've found so far. I expect there are more, but it's hard to look for them directly via Google…
It would be nice to list a few more… Let me know, please!
You'll notice very few English-language sites in that list. Perhaps this is due to guides to Navibar being written in languages other than English – because an extensive site for that already existed – and these persisting after that extensive site had vanished.
I liked Navibar! So I started using it in my sites. Unfortunately, the documentation for the extension (at http://navibar.oaklett.org/ – detailing how webmasters and websurfers should exploit it – disappeared some time around mid-2006! Indeed, the entire oaklett.org domain seems to have gone, along with any chance of contacting the author through the published email address.
(Actually, the author, Markus Siebeneicher, has got in touch with me, and has provided some helpful information — Thanks!)
Yet the extension is still available from the Mozilla Add-ons site, so websurfers can still install it. But without the documentation, webmasters won't know how to use it, so then websurfers will never find sites which exploit the sitemap format, and so the installation will never be engaged.
This page aims to provide replacement documentation, albeit rather sparse, but just enough to make the extension worthwhile. It also might be useful to another developer who would be inspired to do an alternative extension that can read the same kind of sitemap file as Navibar, but present it in a different way, such as a menu hierarchy from a configurable toolbar button. (Nudge!)
A website maintainer might wish to provide a sitemap to allow visitors to navigate around his site easily. The three steps involved are:
Writing a sitemap — Navibar's native RDF/XML format is described.
Serving a sitemap — Make sure that browsers can access the sitemap file.
Attaching a sitemap to a page — Cause the browser to load and display the sitemap when the user visits pages within the site.
The Navibar sitemap format allows you to express a collection of related links (which I'll call entries) in an arbitrary hierarchy. It even allows parts of the hierarchy to be logically duplicated in several places, without actually being duplicated in the sitemap file.
Although the represented sitemap is hierarchical, the format is flat RDF. Your file will initially look something like this:
<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:map="http://www.oaklett.org/map/1.0#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<!-- Insert entries here in any order. -->
</rdf:RDF>
You can then insert entries in any order — it will not affect the order of the represented sitemap, but you need at least one description for each distinct node (including leaves) in the tree.
Each entry appears as an <rdf:Description>
element, for example:
<rdf:Description rdf:about="mydomain:c6:c3"> <dc:title>Farquart's Tubular Emporium</dc:title> <dc:identifier>http://www.farquart.com/</dc:identifier> <map:icon>http://www.farquart.com/favicon.ico</map:icon> </rdf:Description>
You need to give each entry an internal identifier as the value of the rdf:about attribute (mydomain:c6:c3:e29 in the example above), and it must be unique within the sitemap. It allows any number of other entries to refer to it, making it a child of each of them in the hierarchy. It is the association by internal reference, rather than by XML structure, which allows an entry to appear at multiple points in the sitemap (although, I admit, it does make it more verbose and less intuitive).
Any URI (or IRI?) will do for the rdf:about attribute, pretty much, so long as it has no chance of clashing with anything else. Maybe urn:farquart-com:blah is more robust, but putting everything under mydomain: seems to have worked for me! And that probably came straight out of the original documentation.
The content of each entry is a set of Dublin Core elements. The main ones to have, as seen in the example above, are these:
This is the text that will appear in the menu entry for this description.
This is the address (a URI) of the page that selecting this description should take the visitor to. A URI relative to the sitemap is now permitted (since version 0.10.2, I think).
Although the sitemap is intended to allow the visitor to navigate easily within your site, there is nothing to stop you referring to external sites. You might re-iterate the external sites which your site refers to, for example.
Not from the Dublin Core, this specifies an icon to be used beside menu entries. It needs to be a full URI, unfortunately, not one relative to the sitemap file.
With one exception, a node will not be displayed unless it contains both dc:title and dc:identifier. If you need an entry that has children or a (sub)menu, but doesn't have anywhere to point to, you could use null: — not ideal, as it generates a nasty pop-up when you click it, but the entry will be displayed without going anywhere misleading.
Here are a couple of questions for you:
XML element names are case-sensitive, while DC element names are case-insensitive. Presumably, they should be normalized to lower case to turn them into XML, right?
Some DC elements are defined as subelements, e.g. Relation.isPartOf. How is the dot to be translated? As a colon? As a hyphen-dash? As an underscore? A dot appears to be allowed in XML 1.1, so maybe there's no problem.
Fortunately, you don't require this sort of element type to get basic things working anyway.
You can now combine several entries as siblings of each other by
making them children of another node (the parent). The parent node's
<rdf:Description> must contain a
<map:container> or
<map:embedded> element, which lists references to
the child nodes. For example:
<rdf:Description rdf:about="mydomain:c6:c3">
<dc:title>Farquart's Tubular Emporium</dc:title>
<dc:identifier>http://www.farquart.com/</dc:identifier>
<map:container>
<rdf:Seq>
<rdf:li rdf:resource="mydomain:c6:c3:e53" />
<rdf:li rdf:resource="mydomain:c6:c3:e54" />
<rdf:li rdf:resource="mydomain:c6:c3:e55" />
</rdf:Seq>
</map:container>
</rdf:Description>
A <map:container> causes the entries for the
contained references to appear as children in the collapsable
hierarchy visible in the Navibar sidebar. The effect is comparable to
expanding or collapsing a folder in the bookmark sidebar. On the
other hand, a <map:embedded> causes the entries to
appear in the context menu of the parent entry. If such a sub-entry
itself has a <map:embedded>, it will appear as a
submenu.
An entry can have both types of sequence. I'm not sure, however,
whether a <map:container> is accessible from an
entry which itself is inside <map:embedded>.
Multiple <map:embedded>s or
<map:container>s are not permitted. (I don't know
what happens if you put several <rdf:Seq>s in a
single <map:embedded> or
<map:container>. I'll have to try it out
sometime.)
Ah, just seen an archive of the original specification —
<map:container> indicates that the child items
should appear in the same view as the parent;
<map:embedded> indicates that the children should
appear in some new kind of view. That implies that grandchildren of
<map:embedded> should themselves be in a
<map:container>, though it doesn't clarify what
should happen with other combinations of ancestry, or with multiple
<map:*>s of the same type.
The original specification also uses <rdf:Alt>
(for a set of alternatives) and <rdf:Bag> (for an
unordered set, perhaps implying that the extension should remember
personal sorting preferences) instead of
<rdf:Seq>.
Finally, and most importantly of all, you need to specify the root node. This does not need a dc:title or dc:identifier, but it does need a certain internal identifier, urn:sitemap:root. For example:
<rdf:Description rdf:about="urn:sitemap:root">
<map:container>
<rdf:Seq>
<!-- references to top-level entries -->
</rdf:Seq>
</map:container>
</rdf:Description>
It needs at least one <map:container> for the top-level, uncollapsable entries. A <map:embedded> will probably be ignored, I suppose.
That's it!
A Navibar sitemap file is optimally served as the MIME type application/rdf+xml. A few other, less specific types might also work.
Being rather verbose, Navibar sitemap files can get quite big, so
compression would be desirable. Happily, it turns out that
gzip-ing the file and transmitting it with a
Content-Encoding: x-gzip header functions perfectly well.
Firefox probably decompresses it transparently before Navibar even
sees it.
The configuration to achieve this when serving a sitemap file with (say) a .rdf suffix from Apache HTTPd is as follows:
AddType application/rdf+xml .rdf AddEncoding x-gzip .rdf
Note also that language-based HTTP content negotiation also works happily with Navibar.
While the Navibar extension supports four methods of associating a
sitemap with one or more pages, it is my opinion that two of these are
flawed in design, and a third is flawed in implementation. This
leaves one method which I recommend: place a <meta>
element inside <head> to refer explicitly to the
sitemap file. For example, if the sitemap is in the file
sitemap.rdf under the same virtual path (i.e. in the same
directory on most systems), use this:
<meta name="navibar-sitemap-url" content="sitemap.rdf">
A relative URI appears to be acceptable for the content attribute.
The other methods, which I deprecate, are:
Send an HTTP header navibar-sitemap-url. For example, in Apache, you should be able to add to your site's .htaccess file:
Header: append navibar-sitemap-url /path/to/site/sitemap.rdf
(Perhaps a full URI is required.)
This seems flawed in implementation, since the extension seems to send an almost duplicate request to obtain the header, rather than use the response to the first request, and gets confused by HEAD requests too. Comments in the source code indicate that the author knows that it would be preferable to get the header from the original HTTP interaction.
In design, however, it would seem to be more flexible than the <meta> option, as it is not tied to HTML.
Place a sitemap under a ‘magic’ name (sitemap.rdf) in the same directory.
You don't have to link to the file explicitly, but the method is not flexible enough to deal with sites that exist at more than one virtual level.
I'm also not keen on the idea that the browser should download something it hasn't been specifically told to — it means that an extra request will be issued to a site at every virtual level which the websurfer visits. Since this will not exist in most cases, the server's error log may fill up with irrelevant entries.
Place the sitemap under a magic name in the document root of the website, i.e. under /sitemap.rdf.
I find that this depends on a particularly inflexible definition of ‘site’ – everything under the same virtual host – and, like the previous method, it also means a request is made for something not explicitly linked from the page, generating spurious server log entries. It's already bad enough that we have /favicon.ico doing this (and /robots.txt, to a lesser extent).
(Entirely incidentally, you can tell Firefox not to fetch unsolicted /favicon.ico icons by visiting the raw configuration page (about:config; you might have to type it in directly) and disabling browser.chrome.favicons. You still need to enable browser.chrome.site_icons if you want to see explicitly requested icons.)
You can use the first of these deprecated methods (HTTP header),
but don't rely on it. If you use the <meta> method as recommended, the header
will only have any meaning for non-HTML pages.
Do not employ the last two methods! They are strongly deprecated. See also:
I hope sites that currently provide Navibar sitemaps using one of
the last two methods already will consider placing explicit
<meta> tags in the <head> element of each of their
pages, then users can afford to switch off this misfeature.
If you currently rely on the last method, all it takes is to add:
<meta name="navibar-sitemap-url" content="/sitemap.rdf">
For the last-but-one method, use similarly in each page:
<meta name="navibar-sitemap-url" content="sitemap.rdf">
Markus designed some icons for web designers to place on their pages to show that Navibar is supported. I did my own too:
![[Navibar feature icon]](http://www.comp.lancs.ac.uk/~ss/icons/navibar-logo-new.png){kind=icon}
Once installed, Navibar will sit quietly in your browser, and can be set up to automatically display sitemaps (in a sidebar) when you visit sites that have them. You can basically forget about it most of the time, and it will spring into action when it has something to offer.
However, there are some aspects of configuration which you should check immediately after installation.
If you wish, customise your toolbars to include the button which activates and deactivates the sidebar. It's a blue circle with two joined, white arrows.
Determine whether you want to use a sitemap automatically whenever it is available, or just when you ask for it, i.e. manually. (In the latter case, you'll either need the toolbar button, or you'll have to use the statusbar icon.)
In Navibar's configuration, look under the General tab, in the General section, and enable or disable the first option as appropriate: Automatically open/close Navibar…
Select the methods which you want Navibar to use to determine whether a sitemap is available and obtain it.
This last point is very important. As you browse with Navibar enabled, it will try to obtain a sitemap for each page you visit using upto 4 methods. Two of these are quite aggressive, and will cause Navibar to ask the server for a file which will likely not exist. This means, every site you visit that doesn't provide a sitemap will end up with an error message in its logs — possibly several, each few days that you visit, and this is then multiplied by however successful Navibar becomes at being deployed.
The other two methods are benign, as they get their information from the page that has already been delivered. Unfortunately, one of these doesn't work very well, and could cause problems — leaving only one real option.
Navibar looks for a sitemap in upto four places, according to configuration. As a websurfer, I recommend this configuration (under the Loading Phase Steps section of the Sitemap Source tab):
Disable the HTTP Header option — it's a good method, but has a flawed implementation.
Enable the HTML Meta-Data option — the optimal method, at least for HTML sites (i.e. almost everything).
Disable the relative path option — a flawed design which will usually result in a lot of failed HTTP requests.
Enable the absolute path option — similarly flawed, but it shouldn't generate so many failures. Also, many sites that support a sitemap have done so by assuming that this method is enabled, so disabling it will likely mean that you miss a lot of opportunities to exploit existing sitemaps.
However, you should seriously consider switching this method off, at least at some point in the future. I hope these notes will encourage designers of new sites to avoid depending on this method, and of existing sites to switch to the Meta-Data method. Then all Navibar users will be able to abandon the absolute-path method without fear of missing anything.
I suppose that the package will no longer be maintained, so the compatibility information will not be kept up-to-date. It appears, however, that the latest version remains compatible with Firefox 3.0, and so you just need to update the install.rdf file manually:
Unzip the navibar-0.10.3-fx.xpi file into an empty directory.
In the file install.rdf, search for the line containing maxVersion, and change it to read:
<em:maxVersion>3.0.*</em:maxVersion>
Zip the files back up into navibar-0.10.3-fx.xpi, and ask Firefox to install it.
I've managed to hack in a few extra features, but I've not released a new version with them yet — still trying to fix a small point.
I've worked out how to get Navibar to load from a file: URI. (The successful return code for such a URI is 0, rather than 200 for http:.)
I've managed to get null: entries to have no effect when you click on them.
I've almost worked out how to accept relative URIs in the
sitemap document, for dc:identifier and
map:icon. One thing that isn't working is that the icon
URI isn't resolved when displaying the actual sitemap in the sidebar
– I just can't work out where that happens; got it working
everywhere else (page info; context menu).
Something I haven't even started: the Server Spy extension manages to retrieve the Server header from the HTTP request, and display (a portion of) it. (But perhaps it just issues a new request…?) Can we do the same with Navibar, but for the navibar-sitemap-url header?