Open
Bug 68402
Opened 24 years ago
Updated 2 years ago
W3C CUAP: Highlight target of intra-page [named] anchors
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
NEW
People
(Reporter: gerv, Unassigned)
References
(Blocks 1 open bug, )
Details
[ 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
location.
Techniques:
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.
Reporter | ||
Comment 1•24 years ago
|
||
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.
Gerv
Comment 2•24 years ago
|
||
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.)
Reporter | ||
Comment 3•24 years ago
|
||
How persistent would this line be? It obviously shouldn't print. Do we remove it
when the user scrolls?
Gerv
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).
Comment 5•24 years ago
|
||
The W3C (UAAG) says blinking is bad, and I agree ...
Comment 6•24 years ago
|
||
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
Comment 7•24 years ago
|
||
Many pages use empty named anchors. I've even heard several people say they
thought named anchors had to be empty.
Reporter | ||
Comment 8•24 years ago
|
||
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.
Gerv
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...]
Comment 10•24 years ago
|
||
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 mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Reporter | ||
Comment 12•24 years ago
|
||
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
this.
Gerv
Comment 13•24 years ago
|
||
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
Comment 14•23 years ago
|
||
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: http://bugzilla.mozilla.org/show_bug.cgi?id=68402#c6 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?
Comment 15•22 years ago
|
||
.
Assignee: mpt → attinasi
Component: User Interface Design → Layout
QA Contact: zach → petersen
Updated•22 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Comment 16•22 years ago
|
||
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):
http://www.mozilla.org/newlayout/xml/
The code to do the selection is around here:
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsPresShell.cpp#4058
CSS3 has :target selector which would probably be the best thing to implement
and use: http://www.w3.org/TR/css3-selectors/
Reporter | ||
Comment 18•22 years ago
|
||
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:
http://daniel.glazman.free.fr/weblog/targetExample.html
which wouldn't work nearly so well if the target was highlighted by selection.
Gerv
Comment 19•22 years ago
|
||
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.
Comment 20•22 years ago
|
||
Issue raised to CSS WG. Please stay tuned.
Comment 21•22 years ago
|
||
To glazou, since he's handling the spec end of this.
Assignee: attinasi → glazman
Priority: P3 → --
Target Milestone: Future → ---
Comment 22•20 years ago
|
||
*** Bug 269172 has been marked as a duplicate of this bug. ***
Comment 23•17 years ago
|
||
I independently considered the need to mark the target of an anchor, as documented here: http://telcontar.net/Misc/random/anchorjumphelper.php
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.
Comment 24•17 years ago
|
||
(In reply to comment #20)
> Issue raised to CSS WG. Please stay tuned.
What happened?
Updated•15 years ago
|
QA Contact: chrispetersen → layout
Comment 25•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: daniel → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•