177265 - browsers have a terrible way of dealing with inline anchors (<a name=>)

Status: NEW

(SeaMonkey :: UI Design, enhancement)

Description

[Jan Van Looy]

There are three problems:
1. You lose any sense of space when jumping to an inline link. The screen simply
flickers and you are there. You have no idea of how far you jumped into the
document since the scroll bar functions relatively, i.e. you have no precise
indication.
2. The text above the inline link is cut off by the window as if only the text
beneath the anchor is important. One consequence is that inline linking has been
reduced to a “table of contents” device used for linking to headings (then the
text above is usually less important).
3. The inline link remains unclear when it is too close to the bottom of the
document. When the distance between the anchor and the end of the document is
smaller than the height of the window, the browser is unable to scroll down far
enough so that the inline link is at the top.
4. When you link to a word in the middle of a line the browser does not indicate
this. It only shows you the line where the anchor is placed (vertically), not
where in the line (horizontally).

Some ideas:
1. The browser could contribute to the user’s sense of space by scrolling to the
inline link in a certain amount of time. The speed of scrolling and the quick
view of the document should induce a nicer sense of movement. The back button
should do the same, but backwards.
2. The browser should not cut off the document right above the link. Screens
have better resolutions nowadays so at least one third of the screen can be left
above the anchor, if possible the entire containing element, e.g. the paragraph.
3/4. The exact location of the anchor could be indicated by a semi-transparent
arrow blinking slowly and disappearing when clicking the document. Then the
problem of the browser being unable to scroll down far enough is solved and
anchors in the middle of the window can be indicated.

Comment 1

[Aaron Lawrence]

Why not just highlight the anchor you just went to?

Comment 2

[Jan Van Looy]

You may be right, highlighting is probably more consistent with the browser
functions and concepts. I was looking for something else because I do not like
images being highlighted.

Comment 3

[Niklas Dougherty]

Autoscrolling will decrease performance and will make experienced users go nuts.
The vertical scrollbar will indicate where in the document the anchor is.

It is up to the web designer to implement the anchor so that the "text before"
may be included.

It is also up to the web designer to make his anchors visible, for instance by
using CSS:

a.hilite:hover {background-color: #dff; height: 1em}

Haven't tested this, but something like that would do.

Comment 4

[Jan Van Looy]

>Autoscrolling will decrease performance and will make experienced 
>users go nuts.
Perhaps, but I am not sure. It could be done in half a second to a second, about
the same time as to follow a link to another document. Colour, images, css all
slow down performance. They also annoy some "experienced users".

>The vertical scrollbar will indicate where in the document the anchor is.
An extra indication could reduce cognitive load, I believe.

>It is up to the web designer to implement the anchor so that the 
>"text before" may be included.
Then the target anchor loses its semantic value and becomes just another layout
element. As a designer I want to see my target anchor properly without having to
worry about it. I do not want to select some element above it so that my target
appears correctly. If I did, it would make my pages unmaintainable. What do you
do when you are editing text between your anchor and your target string?

>It is also up to the web designer to make his anchors visible, for instance by
>using CSS:
>a.hilite:hover {background-color: #dff; height: 1em}
I do not want to see the anchors when moving my cursor over them, I want to see
them when arriving (and then I want them to disappear again).

Comment 5

[timeless]

uid is being phased out.

Comment 6

[Michael Lefevre]

I can't see anyone implementing this, but confirming anyway, as I don't see a
problem with the request itself.

Comment 7

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".