Navigation to Prev/Next document Heading/Fragment




16 years ago
6 years ago


(Reporter: Stanimir Stamenkov, Unassigned)



Firefox Tracking Flags

(Not tracked)



(8 attachments)



16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030404
Build Identifier: 

Many documents contain "hidden" (not referenced by links) anchor points or
fragment identifiers which make easier access or better stated make
pointing/citing certain parts of a document more downright. Such are often
automatically generated by tools. For XML documents the fragment identifier part
of an URI is related to the ID attribute value of an element. In addition in
HTML documents the 'name' attribute of A elements is used.

It would be nice if there are options (either in the "Go" menu or in the "Site
Navigation Bar" or in both places) for going to the next or to the previous
fragment in a document therefore the URL in the location bar to reflect the new

In addition for HTML documents it would be nice to have similar functionality
for jumping between Heading elements just like if they have, even if they have
no, ID set. A HTML could contain no anchor or IDentifiable elements but it could
have pretty clean structure with parts delimited by Heading elements.

The later would not involve changing the URL so I'm not sure what would be best
implementation - if there should are only two options "Go to next
heading/fragment" and "Go to previous heading/fragment" or there should are four

For jumping between headings the only suitable solution is to jump to
next/previous heading in respect to the currently viewable part of the document
(in the view port) while for jumping between fragments it could be more suitable
to jump to the next/previous fragment in respect to the one pointed by the
current URL (no matter what part of the document of you've been scrolled to view).

Reproducible: Always

Steps to Reproduce:


16 years ago
Severity: normal → enhancement

Comment 1

16 years ago
Isn't this XLink (bug 15086 and bug 61664) ?

Comment 2

16 years ago
I believe this would use XLink in the context of an XML document, but anchors
exist in (non-X)HTML too.

Comment 3

16 years ago
Should this one be related to Bug 103053?

Comment 4

15 years ago
One simple example is with the "Mozilla Release Notes"
<>. There's a "Files Created or Used"
<#files> link in the contents table which takes me to the corresponding section.
After that section there is a "Profile Locations" one which heading is a named
anchor ("profileloc") but which otherwise have no direct link referencing it. I
use it often as reference to point someone to that particular info but I
wouldn't know it if I didn't look at the source and more important I should know
what to look for there.

If I have the ability to go through the document fragments (of course which
would be reflected with changing the location URL) I would easily find out
there's a direct link referencing that particular fragment and I could copy the
location and paste it where I need to cite it.

Comment 5

15 years ago
-> XP Toolkit/Widgets

Confirming. This sounds like a reasonable feature request.
Assignee: asa → jag
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
QA Contact: asa → jrgm


13 years ago
Blocks: 103053

Comment 6

10 years ago
Created attachment 326216 [details]
Fragment navigation sample

Sample fragment navigation.  I'm sure my JavaScript isn't perfect but I want to demonstrate what I'm after.

Comment 7

10 years ago
Created attachment 326219 [details]
 Fragment navigation sample (HTML)

Sample using attachment 326216 [details].  The "<" (next) and ">" (previous) buttons can be triggered using "," and "." access keys.

Comment 8

10 years ago
I'm working to prepare an example which takes heading elements not addressable with fragments into account.  The logic becomes a bit more complicated but not that much, I think.

Comment 9

10 years ago
Created attachment 326227 [details]
Fragment+heading navigation sample

In this example I basically keep additional 'anonymousAnchor' state holding reference to the element last navigated to, if it was not fragment identifiable.  Then use it (if set) as off point in navigating to the next/previous heading/fragment.

I've initially imagined it much more "dynamic" in the sense of using the page scroll position to find out which would be the next/previous heading to go to, but I haven't been able to define sensible algorithm in the cases where non-linear (like two-column) layout is used.

A thing to note in this example: when I scroll to a heading I don't "reset" the 'location.hash' as it causes unwanted flicker.  Leaving the fragment identifier in the location could be somewhat confusing this way.  May be an extension code could modify the location without causing document reload or scroll?  On the other hand it could be useful if the fragment is changed to reflect the nearest previous fragment the current heading follows after.

One more note: I haven't optimized the algorithm to not navigate to anonymous anchors (headings without identifier) if it isn't necessary as in:

<div id="...">


<h2><a id="...">...</a></h2>

so these cases need two clicks to navigate further.

Comment 10

10 years ago
Created attachment 326228 [details]
Fragment+heading navigation sample (HTML)

Example using attachment 326227 [details].

Comment 11

10 years ago
Created attachment 327241 [details]
Improved fragment+navigation sample

Improved sample which handles the cases outlined in attachment 326227 [details] including broken documents containing duplicate IDs (see the XML specification <>).

Comment 12

10 years ago
Created attachment 327242 [details]
Improved fragment+navigation sample (HTML)

Example using attachment 327241 [details].

Comment 13

10 years ago
Created attachment 327243 [details]
Improved fragment+navigation sample (HTML + CSS colums)

Another example using attachment 327241 [details].

Comment 14

10 years ago
I have few ideas and I'm currently thinking of an algorithm which would additionally take the scroll position into account and would allow navigation into documents which have only headings marked up (no fragment identifiers).  This is to handle the following scenario:

Heading 1
Heading 2
Heading 3
Heading 4

The user navigates to "Heading 2" then scrolls after "Heading 3" - navigating next should jump directly to "Heading 3".  The current "heading anchor" should still be used to handle possibly non-liner layouts like:

Heading 1     Heading 3
...           ...
Heading 2     Heading 4
...           ...

Comment 15

10 years ago
> The user navigates to "Heading 2" then scrolls after "Heading 3" - navigating 
> next should jump directly to "Heading 3".

I've meant to write: should jump directly to "Heading 4".

Comment 16

10 years ago
Created attachment 327353 [details]
Sample extension

This is my very first attempt at writing an extension, but at least it works with SeaMonkey 1.1.*.  It adds two buttons to the Link Toolbar which expose the functionality I've implemented.  I've refactored the main script to expose only the prev() and next() in public [1], but otherwise it is the same as in attachment 327241 [details].

Assignee: jag → nobody


8 years ago
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.