Open Bug 68402 Opened 21 years ago Updated 5 years ago

W3C CUAP: Highlight target of intra-page [named] anchors


(Core :: Layout, defect)

Not set




(Reporter: gerv, Assigned: glazou)


(Blocks 1 open bug, )


[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

1.1 When the user follows a link to a target anchor, highlight the target


        o Put the target location at a consistent location in the viewport
          (e.g., at the top of a graphical viewport).
        o Allow configuration to highlight (e.g., graphically, through
          audio cues) the target location. Ensure that highlight mechanisms
          do not rely on color alone and are distinguishable from other
          highlight mechanisms.
I think if the target is at the bottom of a page, we should scroll "beyond" the 
bottom and fill the blank viewport with a neutral colour. I hate the way other 
browsers do it, where (when the target is at the bottom) it just scrolls as far 
as it can, and I have to find the target myself.

This wouldn't be such a problem if we fixed the second part of this bug, though.

I suggest drawing a {1px dotted highlight} horizontal line through the viewport, 
at the place where the anchor begins.

(Yes, I know that wouldn't provide completely unambiguous marking of the anchor, 
where the anchor was inside a multi-column table, or there were multiple anchor 
targets in the same line, or blah blah blah. But that hardly matters.)
How persistent would this line be? It obviously shouldn't print. Do we remove it
when the user scrolls?

Acrobat Reader blinks (very briefly) an arrowesque triangle in the left margin indicating 
where the user should look (when the user is following a story thread).
The W3C (UAAG) says blinking is bad, and I agree ...
I suggest doing the same as when searching within the page: highlight the
anchor content (text between <a name=""> and </a>) the same way as it would
be highlighted when selecting by dragging the mouse.

Well, often the anchor content is empty, but that would be a problem of the
web author, IMHO.
Hardware: PC → All
Many pages use empty named anchors.  I've even heard several people say they 
thought named anchors had to be empty.
So... this means that when people realise that Mozilla does intelligent things 
when they aren't empty, they'll stop doing that, and do the right thing :-)

The above solution also has the considerable advantage that it is likely to be 
far easier to implement than any other suggested. 

i'd prefer a bullet target that appeared at the beginning of <a name>. Plus a 
highlight akin to macos hollow selection.  The normal selection is not the same 
as target selection and we shouldn't interfere w/ the user selection which is 
used for copy/paste.

As with all things, css styles should be able to alter or suppress...  To see 
the target icon that i'm thinking of, edit a page that has an anchor in 
nc4composer.  It wouldn't be unreasonable to have an opposite closing target 
tag [although it might be styled to hidden by default...]
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Hang on... if the user has just clicked a link, surely this will remove any 
highlighting he had. So, we can use the normal user highlighting mechanism for 

See also bug 32265, "RFE: jump-scroll should indicate already-seen area".
Summary: W3C CUAP: Highlight target of intra-page anchors → W3C CUAP: Highlight target of intra-page [named] anchors
It appears that this bug is somewhat fixed with the 2002031105 build on Win2K.
It puts the dotted line around the text enclosed by the named anchor. Try it
here: Unfortunately, it
appears that if the named anchor is empty it completely breaks for in-page
links, but including the #anchor in the URL works. Anyone know what bug caused
this to break for in-page links? Or should I log a new bug?
Assignee: mpt → attinasi
Component: User Interface Design → Layout
QA Contact: zach → petersen
Priority: -- → P3
Target Milestone: --- → Future
Amaya from the W3C inserts a small bullseye image when there is <a name= or
<(element name) title=.
Please note that we already have an implementation working for FIXptrs (we
*select* the target), and I have a patch going through reviews for XPointer (bug
182323). It could easily be modified to work for HTML as well. Although
selection might not be the best way to indicate this, I personally like this as
I have used a product that used to select target. 

This document mentions how to switch this on (see the section on XML Linking):

The code to do the selection is around here:

CSS3 has :target selector which would probably be the best thing to implement
and use:
Actually, dbaron implemented the target selector a week or two ago :-) But I
don't agree the target should be highlighted; there is a very compelling demo
from glazman here:
which wouldn't work nearly so well if the target was highlighted by selection.

Urglllll... I am with Gerv here. This is clearly a proof that accessibility
requirements are not always good to people not needing accessibility.
I do recommend raising
the issue of inconsistency between :target and this CUAP to the W3C through the
CSS WG. I'll do that myself, being Netscape/AOL rep in the CSS WG and being
the main editor of the CSS 3 Selectors module.

In the meantime, please refrain from highlighting the target of the fragment
identifyer of a URL. We have more to lose than to win here.
Issue raised to CSS WG. Please stay tuned.
To glazou, since he's handling the spec end of this.
Assignee: attinasi → glazman
Priority: P3 → --
Target Milestone: Future → ---
*** Bug 269172 has been marked as a duplicate of this bug. ***
I independently considered the need to mark the target of an anchor, as documented here:

As the page illustrates, the iCab Web browser on the Macintosh has a working implementation of this and has done for a while now. I was reminded of this earlier when staring at a page (the RSS 2.0 specs at Harvard) trying to figure out where on earth a link just took me on the page.
(In reply to comment #20)
> Issue raised to CSS WG. Please stay tuned.

What happened?
QA Contact: chrispetersen → layout
Blocks: 269172
You need to log in before you can comment on or make changes to this bug.