CSS-driven link tails

[dartar]

Wikka currently gives admins the option to configure a specific tail for external links in the configuration file. The tail is currently rendered through a <span> that displays the tail as configured in the config file. It would make more sense IMO (especially as soon as we allow multiple CSS stylesheets) to render it through an a.ext:after selector. Tails are part of presentation, not content, and they should consequently be handled by CSS. Furthermore, at the moment only external links have a dedicated class and tail. If the link parser is modified, dedicated classes, titles and tails could be given to specific kinds of link.

Refs

 http://wikkawiki.org/LinkTails

[JavaWoman]

Instead of an a.ext:after pseudo selector, it's also possible to change (left or right) padding and add a background image. The advantage would be that more (older) browsers support this.

[DotMG]

I'm experimenting the use of favicon before the external link. See the top referrers at  http://baiboly.dotmg.net 's homepage. When a link is external, the link is prepended with it's favicon. In my site, I tried it only for the top referrers but it can be extended to the Link() function if it sounds pretty to you all.

On this site, I supposed the favicon is located at /favicon.ico, but some sites, like wikkawiki.org use another location thru <link rel='icon' ... . I asked Peter Andrews ( http://iconsurf.com, <pa @ ICONSURF.C0M>) if he could provide a free service that redirects an url like http : / / iconsurf.com/i/wikkawiki.org to http : / / wikkawiki.org/images/favicon.ico, as he has created a database that have the required information to do that for his search engine. He agreed the idea was exciting, and asked me to recall if he might forget about that. With such a service, it will be easy for us to prepend external link with correct favicon.

The idea is excellent IMO, because it's mine, and if I can convince you all, Wikka will be the first CMS to exploit favicon like this.

[DarTar]

[copying followups to this proposal from mailing list]

---

From: DarTar

Mahefa, here's a couple of remarks on your proposal to retrieve remote favicons and display them as link tails:

• This feature makes IMO an unnecessary use of JS for merely decorative purposes.
• It clutters the page with graphical elements on which wiki owners have no control.
• It blurs the distinction between (decorative) favicons and (semantically meaningful) link tails.
• Semantically meaningful link tails (i.e. visual cues that increase what Nielsen calls "proximal information scent") can be produced with pure XHTML/CSS.

For the above reasons, I'd like to see a stronger case before implementing this in Wikka.

---

From: JavaWoman

Sorry guys, I've been away for a bit (an extremely looong Easter weekend, hiking, catching some weird bug - and now struggling to catch up again). So here goes...

Much as I like the idea of Favicons (and my instruction page about implementing them is still visited a lot!), on this issue I have to say I agree with all of Dario's points - and I have another one to add:

• It's going to be very, very costly - even if done server-side:
  • you could query the site for a file named favicon.ico (that's at minimum a HEAD request to check whether the file exists)
  • even *if* the file exists, you don't know it's going to be the correct one for the page you're linking to: to check that, you need to actually retrieve the page, and parse the head section to see if there is a <link rel="shortcut icon" href="..."> tag - that's a second request but you need a GET this time
  • if there is such a link tag, you need to reference that file instead of a favicon.ico (even if that exists)
  • if favicon.ico does *not* exist, you'll still need to retrieve the page (GET request) and parse it to see if there's a "shortcut icon" link tag

So you will always need at minimum a HEAD request and a GET request and have to parse a part of the page (possibly a large part of the page), just to find a valid favicon URL. And even then: not every site uses one - but you can only be sure of that after doing the analysis.

Instead, I'd like to see this:

• automatically add a class "ext" to any external link (as a hook for styling)
• automatically add a title "external link" to any external link (for added accessibility and to communicate "external-ness" to those who cannot see images or have turned them off) - or add this to any already-specified title
• use CSS (using the "ext" class hook) to pad the link and add a tiny icon as a background image in that space (it can be an extremely small graphic, and the browser will be able to cache it as well); using padding and background image it's easy to change the stylesheet to either make it a link "head" or a link "tail" (so wiki owners and even end users will have control over how it's rendered!)

This could possibly be extended a bit for different *types* of external link (for instance a different icon for "real" interwiki links); to do this add an *extra* hook by adding an extra class, e.g.,

<a href="http://wikipedia.org/" class="ext wiki" title="external 
link">Wikipedia</a>

The stylesheet designer can then decide whether or not to use a different graphic or just ignore the "wiki" class and style only the "ext" class.

Such a solution will be fast, flexible, lightweight, user-friendly and accessible.

[anonymous]

A note of warning about using CSS-driven link icons (though I'm still fully in favor of it): one reason it would be useful to supplement these with a (PHP-generated) title attribute - as in my example code - is that the CSS "content creation" needed for the icons does not work in all browsers, and adding padding to make place for the icon (for inline elements) also does not work in all browsers, as I found when implementing external link icons on my travel blog. We may have to exclude certain browsers, since an icon that overlaps the link text is at least ugly and not exactly helpful either...

[JavaWoman]

Oops - that last comment was from me - I hadn't noticed I was no longer logged in.

Changing type to enhancement.

[DarTar]

(In [488]) First draft of link tail support, refs #35

[DarTar]

(In [489]) Replacing hardcoded external link tail with CSS-driven link icon (using the background method to start with, but probably switching to :after/:before pseudoclasses later), refs #35

[DarTar]

(In [495]) Adding link tail for Author profiles and starting applying FormatUser() method, refs #221 and #35

[DarTar]

(In [496]) Actually formatting the UserName from the UserSettings is a bad idea (the userpage is no more displayed as missing!), reverting part of the previous change, refs #221 and #35

[DarTar]

A few notes.

The new Link() method accepts an extra class parameter (default is empty) that can be used to override the CSS selectors generated by the method itself. This is used, for instance, to style user pages with a dedicated class (they would be styled as plain internal links otherwise). The new method also adds a further check for external links: if a full URL refers to the same server, the {{{ext}} class is not added.

[DarTar]

(In [515]) Link icons, refs #35

• adding link icons for interwiki and mailto links;
• lighter icon for standard ext link;
• fixed hover bug with author icon in header.

[DarTar]

(In [530]) better icon for mailto links, refs #35

[DarTar]

(In [1111]) Changing position of link icons to avoid conflict with punctuation, refs #35

[DarTar]

(In [1112]) Restricting external link icons to main content, refs #35

[DarTar]

Changing milestone to 1.1.6.6 - I am adding to 1.1.6.6 simple link tails (without icons) using the semantically valid :after pseudoclass, to avoid the ugly infinity symbols hardcoded in the output (based on .exttail). As a consequence, .exttail will become obsolete as of 1.1.6.6.

[DarTar]

(In [1296]) CSS-driven link tails and new Link() method (this is my last minor modification before the release), refs #35

[DarTar]

Tested:

• installing a fresh package
• upgrading from 1.1.6.5
• upgrading from 1.1.6.0

obsolete config options correctly removed, no issue to report.

[DarTar]

(In [1302]) porting link icons from trunk (CSS-generated content is inconsistent across platforms), refs #35

[BrianKoontz]

How do you get the user.gif to display? Everything else looks fine to me.

[DarTar]

that requires the application of FormatUser(), which means patching a lot of handlers/actions. I don't think it's a good idea to backport this into 1.1.6.6.

[BrianKoontz]

OK, then let's consider this passed for testing for 1.1.6.6, and bump it back to 1.1.7 for later consideration, since there appears to be a bit more work required for full implementation.

[NilsLindenberg]

(In [1314]) refs #35 undefined constant fix

[DarTar]

Retargeting to 1.3. Code for this ticket may have already been committed to trunk, from which 1.3 will be branched. Consider backporting urgent issues to 1.2.X