Page MenuHomePhabricator

Is it useful to have different icons for protocol, documents and media file external links?
Open, Needs TriagePublic

Description

Overview

MediaWiki core provides 'content-links-external' module, currently in use by every skin that loads it or loads 'content-links', for example in Vector or MinervaNeue.

This is an example of the icon and style treatment provided right now:

image.png (536×882 px, 84 KB)

Problem statement

The external links module is broken functionality from several angles:

1. The user benefit of having minuscule icons of questionable identification value is highly doubtful. When these icons where brought into place, different programs have been defaults to protocols and links, like an external PDF reader application. Nowadays browsers open a PDF by default themselves. Point in case of identification issue is English Wikipedia overwriting PDF icon styles with a custom Commons one, resulting in any desktop skin featuring this instead
image.png (268×772 px, 62 KB)
(Monobook showing oversized PDF icon)
2. The icons are not implemented scalable. Bad for theming and accessibility.
image.png (640×972 px, 90 KB)
(Note: Minerva Neue with skin overwrite of external icon. Showing non-scaled core 'mail' and 'document' icons)
3. The icons are not-theme agnostic. Every skin has to redefine them in order to fit into their visual appearance. And most don't.
4. The file and protocol definitions are somewhat arbitrarily chosen, far from complete and unmaintainedExample video files
1.mw-parser-output a.external[ href$='.ogm' ],
2.mw-parser-output a.external[ href$='.OGM' ],
3.mw-parser-output a.external[ href$='.avi' ],
4.mw-parser-output a.external[ href$='.AVI' ],
5.mw-parser-output a.external[ href$='.mpeg' ],
6.mw-parser-output a.external[ href$='.MPEG' ],
7.mw-parser-output a.external[ href$='.mpg' ],
8.mw-parser-output a.external[ href$='.MPG' ],
9.link-video {
10 background-image: url( images/video.svg );
11}
(Note the outdated character of listed video formats)
5. The icon treatment is limited to links that carry .external and are within .mw-parser-output. For example a normal email link without the class would not carry the icon.

Proposal

There are two different paths forward from my perspective:
Let's decide if

  1. this functionality should be carried on with in MediaWiki core? If that is really useful out-of-the-box for the average users. Or if that is skin territory
  2. icon treatment should be removed completely as core module and with that:
    1. Bring external link treatment back to skins Vector, MinervaNeue and Monobook
    2. Fix scaling issue
    3. Decide if any other protocol/file treatment makes sense. From my perspective the maintenance overhead and problems outlined above do not let this seem useful to carry further.
    4. Reach out to wiki communities about PDF icon

Goal

  • Decide if carrying it further makes sense for MediaWiki core
  • Update repos with decisions above

Event Timeline

Jdlrobson added a subscriber: Jdlrobson.

FWIW I believe the fact Minerva uses them is not intentional and a side effect (regression?) of 8c1afd97a3 . Both Vector (modern) and Minerva can happily (and possibly uncontroversially) remove these styles by explicitly adding content-links-external: false

this functionality should be carried on with in MediaWiki core? If that is really useful out-of-the-box for the average users.

The goal of the skin architecture is to reflect sensible defaults for the majority of skins (with an emphasis on Wikimedia production skins). Moving towards ResourceLoaderSkinModule has allowed skins to explicitly say what they want or don't want. As a general rule I think we should retain styles in core that are used by 2 or more skins in Wikimedia production.

So this answer comes from how many skins disable content-links-external. Right now, if you enable "content-links" but do not disable content-links-external you automatically get content-links-external. I think if we find most skin developers are not enabling/disabling content-links-external that will give us the answer here. Right now 13/81 skins are using them, but 6 of those are one of the 7 skins we enable in Wikimedia production (Timeless, Modern, Vector modern, Vector legacy, MonoBook, Minerva). I don't think we want to retroactively disable this behavior on MonoBook, Timeless Vector legacy, and Modern - it's not worth the hassle - so I'm untagging MediaWiki-Core-Skin-Architecture for now.

https://codesearch.wmcloud.org/skins/?q=content-links&i=nope&files=&excludeFiles=&repos=

Based on fuzzy memory, and a quick skim of the main discussion I recall...

The icons were all removed from Vector in 2014, in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/123817
There were many objections to parts of this (including from myself) in T56604: Large number of CSS rules for external links - that task initially started as a "clean up the related CSS" but got diverted into a mass icon removal. That old task thread is worth reading.
I think everyone agreed that it was time to retire the "https" padlock icon, but there was varying levels of disagreement about much of the rest.

There's a handy table of live examples at https://en.wikipedia.org/wiki/Help:External_link_icons#Example
From 2014 until late 2021 (IIUC, per archive.org) the only thing that Vector showed differently was 'external link' and 'PDF'.

At some point in the last year (?), they all reappeared again.
This made me very happy, as I frequently appreciate the indicators/warnings for mailto links and pdf links. E.g. Clicking a mailto link opens up my personal email program (Thunderbird) which is rarely what I want in a wiki-context.
Humans are inconsistent, and so some people will write link-labels that don't correctly indicate the actual destination, e.g. writing [mailto:foo@bar.com Alice Smith] which (onwiki) I might assume is a link to their userpage.

Many projects have implemented the custom "Adobe PDF" icon for PDFs, usually along with an optional parameter for indicating the size. One of the core concerns about PDFs (and direct multimedia links) is how much bandwidth they consume, which some people have to worry about due to limited data-plans. (E.g. Rowiki, Ruwiki, Slwiki, among others)

I rarely see the icons for externally linked multimedia filetypes (because they generally are not, and usually should not, be directly linked to), so when I do see them it is also a useful warning, both as a reader and as an editor. However, it is rare enough that they could possibly be re-removed. - The main use-case I can easily think of is pronunciations, but those are hosted on Commons and the "you're about to make noises come out of your speakers" warning-icon is implemented by a custom template at Enwiki (and elsewhere), e.g. in the lede sentence at Shibboleth.

Re: "Problem Statement #3" - I know the Modern skin uses custom styling for a few of the icons. I'd be curious if any/many non-Wikimedia skins do - if it's widespread, or used in a widely-used skin, then that might need to be considered. If not, then it could probably be safely removed.

At some point in the last year (?), they all reappeared again.

I can confirm this was also not intentional (and looks like a performance regression) Looks like this happened in July 58c87018 in legacy Vector, and 722b5fbf in modern Vector.

As a note, these icons also aren't accessible, so any indication they grant to the sighted user is missed out by the unsighted user.

Change 757023 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Opt out of external link icons

https://gerrit.wikimedia.org/r/757023

Change 757027 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] ResourceLoaderSkinModule: Opt-in policy shouldn't add features

https://gerrit.wikimedia.org/r/757027

Change 757027 merged by jenkins-bot:

[mediawiki/core@master] resourceloader: Change SkinModule list mode to not add implicit features

https://gerrit.wikimedia.org/r/757027

Change 757023 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Opt out of external link icons

https://gerrit.wikimedia.org/r/757023

@Volker_E leaving this open in case you wanted to think about reintroducing any of the new icons, but they have now been removed from Vector and Minerva.

I think the solution shown in the picture F34904681 is a good one. Are these symbols available on commons somewhere? I would like to know this because if they are removed (some are already removed on my wiki) I will change them in my private CSS.

@Krzysiek_123456789 Not that I'm aware of. They also have, and I'm aware that they seem to work for you, several design issues, like size, which for people with low vision are close to unrecognizable in their current sizing, and are wrong from an right-to-left language perspective (audio-rtl.svg). You can find them in this directory in case you want to upload them yourself.

@Volker_E Ok, thank you. It is only my personal opinion. It is very good
that upgrades are made to help people with difficulties, I appreciate that,
but for me these icons are just some kind of habit, that is why I want to
keep them in my wikipedia skin :)

wt., 22 mar 2022 o 22:27 Volker_E <no-reply@phabricator.wikimedia.org>
napisał(a):

Volker_E added a comment. View Task
https://phabricator.wikimedia.org/T298433

@Krzysiek_123456789
https://phabricator.wikimedia.org/p/Krzysiek_123456789/ Not that I'm
aware of. They also have, and I'm aware that they seem to work for you,
several design issues, like size, which for people with low vision are
close to unrecognizable in their current sizing, and are wrong from an
right-to-left language perspective (audio-rtl.svg). You can find them in
this directory
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/resources/src/mediawiki.skinning/images/
in case you want to upload them yourself.

*TASK DETAIL*
https://phabricator.wikimedia.org/T298433

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *Volker_E
*Cc: *Krzysiek_123456789, Izno, Jdlrobson, Lens0021, Masumrezarock100,
Liuxinyu970226, Ricordisamoa, tarlocesilion, Esanders, Aklapper, Quiddity,
Pginer-WMF, alexhollender_WMF, RHo, Mainframe98, Iniquity,
Jack_who_built_the_house, Maryana, Glaisher, Volker_E, Susie413113, G1964j,
Zekwn, the0001, Zabe, Manishagoenka, Selby, AndreCstr, caldera,
XeroS_SkalibuR, cristiana023, Demian, RhinosF1, DannyS712, Remagoxer,
Mirahamira, Markhalsey, Jayprakash12345, JGirault, Psychoslave, Wong128hk,
Dinoguy1000, Isarra, Jay8g