Anchor Markers

We’ve had a bug open for quite a long time about implementing the W3C Common User Agent Problems recommendation from 2001 to highlight the target of intra-page named anchors.

Someone recently posted their ideas in that bug; I don’t think much of their UI, but I think it would be great if Firefox had a solution for this. (It would be nice also to style internal links slightly differently, perhaps with a dotted underline, so people don’t do “Open In New Tab”, and end up with five copies of the same large page.)

Is there an extension which does this? If not, does anyone feel like knocking one up?

One implementation method would be to highlight and then fade out the elements contained in the <a name=””> tag. However, this might not work everywhere because of the following pattern:

<a name=”heading”></a>

People do this a) to make sure the heading is visible on the page, and b) because people used to write bad CSS which caused hover effects to apply to anything within an <a> tag, whether it had an href or not. But maybe this problem isn’t a showstopper.

11 thoughts on “Anchor Markers

  1. All early versions of Dreamweaver would insert an empty named anchor tag pair rather than surrounding the heading text. This is before CSS, so there must be some other reason.

    I just tried in Nvu, and it too inserts an empty named anchor in front of the text you’ve selected rather than surrounding it, either before the H3 tag or within it.

    I think fading in an anchor at the destination is a nice thing to do. But I agree it would also be nice to style an intra-page hyperlink differently so there’s a hint what form of link you’re clicking.

  2. the use of empty anchors is fairly old-school. should time be invested in working around this outdated markup practice, or should it instead be spent considering the more up-to-date practice of targetting ID/fragment identifiers and then using the :target pseudoclass for simple visual feedback?

  3. Regarding highlighting – how can you be sure you don’t choose a highlight that conflicts with the page itself, especially internal anchors. After all, dotted underlines are the default styling for abbr tags.

    As far as internal anchors go, you completely missed the point. If a person wants to middle-click a link, they want to middle-click it. They don’t want to think, “bummer, stupid internal link, I can’t view that right now”. Having something in a new tab is handy, and you’re not relying on Back/Forwards to flick between pages or parts of the page.

    One simple idea would be page cloning: a middle-click on an internal anchor creates a tab that contains a simple reference to the parent tab. No need to re-render anything – it simply draws in as if it were that other tab. Form contents, scroll position and selection etc need to be separate, so hopefully those all sit at a higher level in the object hierarchy, with just the page data itself being referenced by the new tab.

    That way, middle-click works as desired and expected, and instantly. It’s like doing New View in an art package or text editor — same document, new view.

    The harder part is the stupid case of image searches where you hit two images that both open the same page (both images were on that same page). That’s a harder case: is it valid, if the user asks for a given page, to simply clone the existing window? Faster, yes, cheaper, yes, but if they wanted to see a new copy and compare to one from a few minutes ago, side by side … oops.

    But of course, hitting refresh for any tab would break the cross-tab reference.

  4. I suspect the easiest way to imply something is an internal link is to animate a scroll down to it when its clicked.

    I also think that perhaps a different cursor rather than a different underline would be better, as people might mistake them for those dodgy text ads.

  5. Peter — if you scroll only, then it breaks for items at the end of the page. The browser can’t scroll past the end of the page, but you assume that the item to be at the top of the window. In fact, it could be anywhere between the top, and the bottom of the window. This case is the fundamental reason why I had the idea in the first place.

    Using CSS to highlight the item also carries risks for (as mentioned) empty anchor tags, as well as for anchor tags that contain images. Worse, CSS is an extremely flaky beast and applying extra CSS to a page could temporarily damage formatting: the page won’t be built to expect random extra styling applied.

    While Gervase is publicly opposed my own design (an arrow) I’m intrigued as to how one could find any better solution to this. An arrow carries no risks about having to understand link dimensions, page content or existing styling and style clashes.

    (* Note to self: Gervase’s site is not UTF-8 aware (!) — do not use fancy type *)

  6. The Link Alert add on does a really nice job of indicating what type of thing lies at the other end of a link. Perhaps that could be extended to include a local anchor icon.

  7. Daniel: Mozilla’s CSS implementation is not “an extremely flaky beast” and, in fact, the CSS standard is specifically designed to allow extra style sheets (e.g. for accessibility) and other “random extra styling” to be added by the user agent. So there’s no problems there.

    B C: Yes, I use Link Alert already. I think it has an icon for “local link”. But I don’t like that approach for general use; I think it would confuse people. Also, the problem with a different cursor (as Peter Hewitt also suggested) is that you only see it’s an internal link when your mouse is over it, which may not give you time to register and change your plan before you click.

    Daniel: Thanks for dropping by; now you have, I guess I owe you a better explanation of why I don’t like your arrow. Basically, I think it’s ugly :-)

    Whoever suggested using :target is right – that’s the mechanism we should use. But there’s still a question of what the styling should be.

    For internal links, perhaps a long-dashed underline? ___ ___ ___ – no-one uses that yet. And it’s close to the standard underline, implying that it’s almost the same as a normal link. Dotted might do – yes, it’s the default styling for , but in black. In this case, the link would be coloured (normally blue).

  8. No, CSS is a flaky beast. CSS 2 is deeply complex and a small change to styling can unexpectedly break things. The most notable example is border: adding a simple 1px border to an element will drastically change its layout, for example how margins interact and whether backgrounds extend into margin areas. Slapping some new style on the target of a link could be nasty, and you have to always be sure it won’t clash or conflict with the page style or content. The arrow solves that problem nicely by not interfering with the page’s content, and solves the horizontal bar problem by showing you which column you want, and where to start reading. It also solves the flaw of empty tags. Pretty much, just works. Alexander Clauss never commented on why he reverted it to a horizontal bar, which is useful.

    The fact that one specific arrow is ugly does not justify a damning “I don’t think much of their UI”. That’s not a nice way to write it. An arrow is a very good approach, even if my hollow triangle looks like arse (which it does, but that was never the point).

    Internal links, as far as I’m concerned, don’t count and I don’t really want to mess with them. Middle-click is a sacred concept that a different link decoration won’t solve. Decoration would now mean … argh, internal link, now what, guess I can’t use that properly, hang on, where am I … click it, now I have to click Back to get to where I was … but I wanted to read that part in a minute and set it aside for then … so, how do I go back to it ….. do I temporarily bookmark that link + fragment anchor? Or just open a fresh tab anyway?

    It’s not going to do anything more than make you more aware of the basic failings of the browser UI, whereas normally you’d only be troubled if you’re re-opening a huge page into a new tab (or a medium page on a slow PC — i.e. what I get). The aim is to actually make internal links usable instead of a road sign that reads, “Warning, one of those stupid internal links ahead”.

    I did experiment with manually highlighting them in-page, but it looked so hideous I gave up. And I had no ability in CSS to indicate if the link was to an earlier or later part of the page :/ So I had this crazy double-head N/S arrow by the link to say, “this goes to somewhere else on this page”. ( a[href^=”#”]:after { content: url(…) … }, or some such … )

  9. Daniel: I think you are being unfair to the authors of the CSS specification. Exactly which changes have an effect on layout is well-specified. Of course adding a border does; but equally, changing the background colour does not.

    I didn’t mean to be “damning” about your UI. I just think putting big arrows on the page doesn’t look nice.

    I don’t understand your “stream of consciousness” with respect to the idea of different styling for internal links. Let me restate my idea: have internal links within a page use a slightly different underlining style. Then people would notice that and consciously choose to left-click rather than middle-click, to avoid having six copies of the same page in six different tabs. Those who didn’t notice the difference would be no worse off than now.

  10. There have been several different extensions that among other things style internal links differently, usually by inserting a little graphic after them, either all the time or on hover (depending on the extension). I don’t at the moment remember the names of these extensions, but I can assure you that they do exist. They generally also style links conditionally in other ways, e.g., put a little PDF icon by PDF links, or a little nofollow icon by nofollow links. For an extension, which the user installs knowingly, the little graphic is a better solution than different underlining, because it’s more robust in the face of arbitrary page CSS. I’m not sure you’d want to do that to the browser’s default styles, though; I suspect a lot of people would find it distracting. I also agree with the comments that dotted underlining would get confused with other things, like inane “contextual” adverts and entities with title attributes.

    There’s a third reason why people put an empty anchor before headings: some (most? all?) HTML DTDs do not allow heading elements inside of anchor elements. The better workaround to my way of thinking is to put the anchor element inside the heading element, but not everyone figures it that way. Some people think of the named anchor as an inherently top-level thing, something that should always be a direct child of the body element, because the way they used named anchors is to divide the document body into its sections as per the table of contents. I don’t think that was necessarily the intention of the spec, but I think it’s a pretty common way of looking at it. (In any case, I don’t see any good reason why you *shouldn’t* be able to put headings inside of anchors, but then I’m one of those weirdos who wants to put block-level elements inside of paragraphs too, so apparently I don’t think like the people who designed HTML.)

    > If a person wants to middle-click a link, they want to middle-click it.

    Generally, but there might be exceptions. For instance, there are times when I intend to read an entire document, and in these cases I would, if I knew that the links were all internal, not click them at all, because I’m planning to read the whole document. So I’d just scroll down past the TOC and start reading. But if I don’t know that the links are internal, and I want to read it all, the web has me conditioned to middle-click every single link in the whole table of contents until I realize what’s going on.

    There are other problems caused by this “I didn’t know it was an internal link” phenomenon. For instance, people (well, kids) often come into the public library and use the internet because they want the hints and/or cheat codes for a video game they’re playing. For reasons that escape me, some very popular sites for these things are basically single-document sites, one giant enormous HTML page with a TOC at the top and sections stretching down the page, topped with named anchors, for each and every video game in the history of the universe (or so it seems). The user finds the game they want in the TOC, clicks, sees the beginning of the stuff they want, and hits print. This will run the printer out of paper every time, usually *before* the user figures out that the stuff that’s printing isn’t, in fact, anything they wanted. They never understand why they got the wrong stuff.

    I don’t know of a good default UI for this, but yeah, it would be Really Nice if you could tell by looking that the links are internal to the current page.

    > One simple idea would be page cloning

    That’s an interesting idea, but I’m not sure how practical it would be. Remember that it’s not 1994 anymore, so the style and even the contents of the page might change, for various reasons, after the user middle-clicks the link.

    > I suspect the easiest way to imply something is an internal
    > link is to animate a scroll down to it when its clicked.

    That only works if the link is to open in the current tab.

    > The browser can’t scroll past the end of the page

    That’s a bug. It’s a common bug shared by MANY (possibly most) modern applications, probably caused by something to do with the scrollbars in major widget libraries, but it’s a bug nonetheless. Software certainly *can* be designed to scroll all the way down so that the last line of the document is at the top of the screen, and has been doing so for decades. Any software that displays text *should* be able to do this, because it makes reading the end of the page more convenient for users who like to scroll line-by-line as they read. Web browsers have a more specific *need* to be able to do this, because of named anchors.

    > Also, the problem with a different cursor … is that you only see
    > it’s an internal link when your mouse is over it, which may not
    > give you time to register and change your plan before you click.

    I don’t think that implies that a different pointer is a bad idea, only that it may be inadequate by itself. Having a different pointer over internal links strikes me actually as a good idea, that could be used in conjunction with whatever else. After all, there are various visual cues that help you figure out which parts of a web page are links, but the most reliable way is to see if the pointer changes to the pointing-finger icon when you hover there. Everything else can be, and often is, styled away by CSS (or deprecated physical markup if the webmaster is still using old SGML-based versions of HTML, which is still disturbingly common).

  11. Styling the underline on local links differently has been one of mpt’s feature requests for a long time. :) See his comments in bug 59109.

    Wrt styling affecting layout: The ‘outline’ property can draw a “border” around the element without affecting layout at all. It’s designed for UI interactions like this.