202958 - Navigation to Prev/Next document Heading/Fragment

Status: NEW

(Core :: XUL, enhancement)

Description

[Stanimir Stamenkov]

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
position.

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
options.

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:

Comment 1

[Jo Hermans]

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

Comment 2

[Garth Wallace]

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

Comment 3

[Stanimir Stamenkov]

Should this one be related to Bug 103053?

Comment 4

[Stanimir Stamenkov]

One simple example is with the "Mozilla Release Notes"
<http://www.mozilla.org/releases/mozilla1.3>. 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

[Jon Henry]

-> XP Toolkit/Widgets

Confirming. This sounds like a reasonable feature request.

Comment 6

[Stanimir Stamenkov]

Attachment: 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

[Stanimir Stamenkov]

Attachment: Fragment navigation sample (HTML)

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

Comment 8

[Stanimir Stamenkov]

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

[Stanimir Stamenkov]

Attachment: 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>...</h2>
...
</div>

and

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

so these cases need two clicks to navigate further.

Comment 10

[Stanimir Stamenkov]

Attachment: Fragment+heading navigation sample (HTML)

Example using attachment 326227 [details].

Comment 11

[Stanimir Stamenkov]

Attachment: 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 <http://www.w3.org/TR/xml>).

Comment 12

[Stanimir Stamenkov]

Attachment: Improved fragment+navigation sample (HTML)

Example using attachment 327241 [details].

Comment 13

[Stanimir Stamenkov]

Attachment: Improved fragment+navigation sample (HTML + CSS colums)

Another example using attachment 327241 [details].

Comment 14

[Stanimir Stamenkov]

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

[Stanimir Stamenkov]

> 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

[Stanimir Stamenkov]

Attachment: 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].

[1] http://www.crockford.com/javascript/private.html