External links to .doc/.odf/.swf/image files should have their own custom icons
Closed, DeclinedPublic

Assigned To
None
Priority
Low
Author
bzimport
Commits
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Unknown Object (Commit)
Subscribers
DieBuche, gpaumier, waldyrious and 4 others
Projects
Reference
bz1578
Description

Author: flamurai

Description:
Right now, media links just display the external link icon. This is extremely
poor UI design. The CSS files should be updated to be able to parse links with
relevant extensions. As I see it, there should be three icons: audio, video, and
document (PDF).

I'm no CSS expert, but it seems to me as simple as:

#bodyContent a.internal[href $=".ogg"],
.link-audio {

background: url("audio_icon.gif") center right no-repeat;
padding-right: 16px;

}

etc. for the other two

I'm not sure what the browser support for $= is since it's CSS3, but I assume
it's the same as ^=, which is already used.

I'd patch it myself, but I'm new to this and don't know if there are any places
other than monobook.css this needs to be addressed.

This would also address bug 1311.


Version: unspecified
Severity: enhancement

bzimport added projects: MediaWiki-Parser, Design.Via ConduitNov 21 2014, 8:13 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz1578.
bzimport created this task.Via LegacyFeb 24 2005, 1:17 AM
Wikinaut added a comment.Via ConduitFeb 24 2005, 1:32 AM

(In reply to comment #0)

... As I see it, there should be three icons: audio, video, and
document (PDF).
#bodyContent a.internal[href $=".ogg"],
.link-audio {

background: url("audio_icon.gif") center right no-repeat;
padding-right: 16px;

}
I'm not sure what the browser support for $= is since it's CSS3, but I assume
it's the same as ^=, which is already used.
I'd patch it myself, but I'm new to this and don't know if there are any places
other than monobook.css this needs to be addressed.

This would also address bug 1311.

yes: http://bugzilla.wikipedia.org/show_bug.cgi?id=1311
and: http://bugzilla.wikipedia.org/show_bug.cgi?id=1254

This works for my Netscape 7.1 (AFAIK), but it does not work correctly for all
browsers, the Internet Explorer is a touchy thing. I am also not an expert.

I think, all bugs 1245, 1311 and this 1578 should be linked and treated
together, as they are similar.

Tom

bzimport added a comment.Via ConduitFeb 24 2005, 3:05 AM

flamurai wrote:

This bug contains bug 1311. I agree that they're all similar and should be
addressed in a similar way (mainly CSS, not through the PHP page rendering
engine), but I think this bug is more urgent than bug 1245 because it is a major
UI flaw having the external link icon display for things that aren't external links.

I don't think browser compatibility is a huge deal considering we're already
using CSS3 to display the external link icon. This isn't a make-or-break
feature, and there is no major UI flaw if the external link icon isn't
displaying at all.

I'll try to create some icons in the style of the monobook external link icon.

bzimport added a comment.Via ConduitFeb 24 2005, 3:06 AM

flamurai wrote:

I meant bug 1254... sorry about that.

bzimport added a comment.Via ConduitFeb 24 2005, 5:44 AM

flamurai wrote:

Thinking ahead, there's a minor issue with doing this in CSS: Both Ogg Vorbis
and Ogg Theora files use the ogg extension. There is no way to distinguish
between video and audio files just from the filename. Off the top of my head, I
can't think of a good icon that would work for both video and audio files.

However, for now I think it works to use an audio icon for ogg files and a
document icon for pdf files.

bzimport added a comment.Via ConduitFeb 24 2005, 5:48 AM

flamurai wrote:

Screenshot of proposed media links with icons

Attached:

bzimport added a comment.Via ConduitFeb 24 2005, 5:48 AM

flamurai wrote:

audio icon

attachment audio.png ignored as obsolete

bzimport added a comment.Via ConduitFeb 24 2005, 5:48 AM

flamurai wrote:

document icon

attachment document.png ignored as obsolete

bzimport added a comment.Via ConduitFeb 24 2005, 5:48 AM

flamurai wrote:

video icon

attachment video.png ignored as obsolete

bzimport added a comment.Via ConduitFeb 24 2005, 5:54 AM

flamurai wrote:

Patch to /skins/monobook/main.css

This patch adds two rules to main.css applying an audio icon to internal links
to ogg files and a document icon to internal links to pdf files. There is no
rule for video files since there is not yet an officially supported video
format for the Wikimedia sites.

attachment mediaicons.patch ignored as obsolete

bzimport added a comment.Via ConduitFeb 24 2005, 5:58 AM

flamurai wrote:

improved document icon (not in screenshot)

Attached:

bzimport added a comment.Via ConduitFeb 24 2005, 10:46 PM

flamurai wrote:

Patch to skins/monobook/main.css

Shrank padding of audio link by a pixel. (The rest of the icons have solid left
edges while this doesn't, so it appears to be farther away from the text even
though it really isn't.)

attachment mediaicons.patch ignored as obsolete

bzimport added a comment.Via ConduitFeb 26 2005, 3:12 AM

avarab wrote:

flamurai said:
"Thinking ahead, there's a minor issue with doing this in CSS: Both Ogg Vorbis"
"and Ogg Theora files use the ogg extension. There is no way to distinguish"
"between video and audio files just from the filename."

.ogm has been gaining ground as an extension for video files in the Ogg wrapper.

bzimport added a comment.Via ConduitNov 4 2005, 12:46 PM

zigger wrote:

*** Bug 3726 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitNov 4 2005, 12:50 PM

zigger wrote:

*** Bug 1311 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitJan 24 2006, 3:42 AM

ui2t5v002 wrote:

I'd like to add this to the site css for an audio link class:

.audiolink a{

background:

url("http://upload.wikimedia.org/wikipedia/commons/f/f7/Loudspeaker.png") center
left no-repeat !important;

padding-left: 16px !important;
padding-right: 0 !important;

}

though if something similar is being done elsewhere, I don't want the
implementations to conflict. Please comment:

http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#A_solution

Also, as an aside, for those who use Firefox and want an icon next to media
files, you can get the Target Alert extension. It's nice. :-)

http://www.bolinfest.com/targetalert/

bzimport added a comment.Via ConduitNov 10 2006, 2:58 PM

ui2t5v002 wrote:

The PDFlink, DOClink, and RTFlink templates perform the same functionality as
this bug. It has been suggested that we use CSS and templates to create icons
for *all* file types, in lieu of this bug being fixed. Should we go ahead with
this? Will this bug ever be fixed?

It would be more efficient and "proper" to actually fix the bug in Mediawiki,
but if that's never going to happen, we'll just do it with templates.

http://en.wikipedia.org/wiki/Template_talk:PDFlink#Other_link_templates

bzimport added a comment.Via ConduitNov 10 2006, 3:01 PM

ayg wrote:

IE7 now supports the appropriate CSS selectors to add icons to the end based on
filetype. This seems like a good idea, I'll see about adding this.

bzimport added a comment.Via ConduitNov 10 2006, 4:03 PM

ui2t5v002 wrote:

(In reply to comment #18)

IE7 now supports the appropriate CSS selectors to add icons to the end based on
filetype. This seems like a good idea, I'll see about adding this.

As I said, I've already done this for PDF links. Adding other file types would
be trivial, but doesn't solve the bug because it doesn't work on all browsers.

http://en.wikipedia.org/wiki/Template_talk:PDFlink#Changing_the_icon_and_using_it_for_.2Aall.2A_PDF_links

http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_2#Similar_for_PDF_files.3F

http://en.wikipedia.org/wiki/Template_talk:DOClink

To really fix the bug, Mediawiki needs to add a CSS class to each link depending
on its type (class="external text" should become either class="external PDFlink
text" or class="PDFexternal text" or something like that, depending on
implementation), and then the icon displayed will be determined from the
site-wide CSS.

For now, we are using templates to add the CSS class manually. We are going to
expand the templates to cover all file types if Mediawiki is not going to be
fixed any time soon.

bzimport added a comment.Via ConduitNov 10 2006, 4:06 PM

ui2t5v002 wrote:

Go to http://en.wikipedia.org/wiki/MediaWiki:Common.css and search for "Change
the external link icon to an Adobe icon for all PDF files" to see the current
implementation.

You should already be seeing PDF icons for PDF external links in IE7 if it
supports the selectors.

bzimport added a comment.Via ConduitNov 10 2006, 9:06 PM

ayg wrote:

Every major browser, to my knowledge, now supports the [href$=".xxx"] selector
in its latest versions. I don't think a class needs to be added when pretty
soon most people will be able to use the CSS rule; the code would be immediately
obsolescent, and it's no big deal if some people don't see the pretty icons. So
no, I at least have no intention to "fix" MediaWiki in the way you want, but I
do plan to fix this bug via CSS selectors such as the one you added to Wikipedia.

It remains necessary to find GPL-compatible icons for all the filetypes we want
to support, of course. Shouldn't be too hard for generic "document", "picture",
"sound", "video", but beyond that it could get tricky.

(In reply to comment #20)

You should already be seeing PDF icons for PDF external links in IE7 if it
supports the selectors.

I am.

bzimport added a comment.Via ConduitNov 10 2006, 9:20 PM

ui2t5v002 wrote:

(In reply to comment #21)

So
no, I at least have no intention to "fix" MediaWiki in the way you want, but I
do plan to fix this bug via CSS selectors such as the one you added to Wikipedia.

Ok. We'll do it with CSS and templates, then.

It remains necessary to find GPL-compatible icons for all the filetypes we want
to support, of course. Shouldn't be too hard for generic "document", "picture",
"sound", "video", but beyond that it could get tricky.

Flamurai uploaded icons to this bug report that match the icons included with
Monobook. I'm sure he'd create any others we needed.

Also, Michael180 created this set of icons specifically for Mediawiki:

http://commons.wikimedia.org/wiki/Category:Nuvola-inspired_File_Icons_for_MediaWiki

That page also mentions modifying ImagePage.php, which I hadn't noticed before.
What's that about?

bzimport added a comment.Via ConduitNov 12 2006, 3:27 AM

ayg wrote:

Hm, wait, this is for internal links? Do we want these icons for internal,
external, or both? Maybe some modified version should be used for external
links, incorporating the arrow we have now? I think it's best for internal and
external to display differently, but incorporating this data in links of both
kinds is a good idea. flamurai, would you be interested in making new icons to
incorporate "external sound, external video, external document" ideas?

(In reply to comment #22)

Flamurai uploaded icons to this bug report that match the icons included with
Monobook. I'm sure he'd create any others we needed.

Those are excellent, yes. Thank you for pointing them out.

Also, Michael180 created this set of icons specifically for Mediawiki:

http://commons.wikimedia.org/wiki/Category:Nuvola-inspired_File_Icons_for_MediaWiki

That page also mentions modifying ImagePage.php, which I hadn't noticed before.

What's that about?

That's a different issue. Those images are intended to be used to display on a
media page where the file can't be thumbnailed. See current behavior at, e.g.,
[[commons:Image:StephansdomAnnotated.pdf]] for ImagePage display. They're way
too big to scale well to the size needed for external link icons.

bzimport added a comment.Via ConduitNov 12 2006, 5:13 AM

ui2t5v002 wrote:

(In reply to comment #23)

Hm, wait, this is for internal links? Do we want these icons for internal,
external, or both?

External. There's no way to link to PDFs or DOC files internally.

Those are excellent, yes. Thank you for pointing them out.

They don't differentiate file type like the PDF icon we are currently using,
though. People except PDF icons to have some red in them.

That's a different issue. Those images are intended to be used to display on a
media page where the file can't be thumbnailed.

I see that now. The PDF icon actually looks pretty good scaled down, but the
others not so much.

bzimport added a comment.Via ConduitNov 12 2006, 8:36 AM

robchur wrote:

There's no way to link to PDFs or DOC files internally.

[[Media:Wiki this, wiki that.pdf]]

bzimport added a comment.Via ConduitNov 12 2006, 3:57 PM

ui2t5v002 wrote:

(In reply to comment #25)

> There's no way to link to PDFs or DOC files internally.

[[Media:Wiki this, wiki that.pdf]]

Hmmm.. But we don't allow PDFs to be uploaded. There are a few left over from
when we did, but that's a very small issue, and they aren't going to be linked
to from articles. No internal links have icons, but you want to change that if
the internal link leads to images or sounds? We already have templates for
displaying internal audio links with loudspeaker icons and internal video links
with film strip icons. With CSS changes applied to internal links, clickable
images would have a little image icon next to them, too. I was thinking
entirely of external links. Like flamurai said "it is a major UI flaw having
the external link icon display for things that aren't external links".

bzimport added a comment.Via ConduitNov 12 2006, 7:00 PM

robchur wrote:

Where "we" is Wikimedia, yes. But this is filed against MediaWiki in general,
and so it would be nice to fulfill it for all MediaWiki implementations, no? Any
road, I wasn't stating that I thought this should be applied to internal links,
I was correcting your apparent misconception as to the linking process.

bzimport added a comment.Via ConduitNov 12 2006, 7:18 PM

ui2t5v002 wrote:

(In reply to comment #27)

Where "we" is Wikimedia, yes. But this is filed against MediaWiki in general,
and so it would be nice to fulfill it for all MediaWiki implementations, no?

Of course.

Any
road, I wasn't stating that I thought this should be applied to internal links,
I was correcting your apparent misconception as to the linking process.

Ok. I guess the original comment was about internal links, while all of my
comments have been exclusively about external links. So different people are
talking about different things. This is how I'm imagining it *should* work for
Wikipedia:

  • Internal links should be icon-less like they always have been, and indicators

should be provided by templates like {{listen}}, {{multi-listen_start}},
{{audio}}, {{video}}, {{multi-video_start}, etc.

  • External links should have the icons they currently have for mailto: news: and

the like, but http: links should only have the current external link if they go
to an html/xhtml/etc page. If they go to a PDF, DOC file, directly to an image,
sound file, or video, then the regular external link icon should be replaced
with a file type icon. Ideally, this would be done inside Mediawiki by adding a
CSS class to recognized file extensions, but adding the icon with an advanced
CSS selector and optionally with templates is almost as good.

If we want Mediawiki to support icons for both internal and external, that's
fine and all; this is just what I'm imagining for Wikipedia.

bzimport added a comment.Via ConduitNov 12 2006, 10:39 PM

ayg wrote:

Icons added via CSS in r17593 for ogg, mid, midi, mp3, wav, wma (audio); ogm,
avi, mpeg, mpg (video); pdf (document). Still not fully fixed:

  • There should be separate icons for PDFs and other documents (like DOCs, ODFs,

etc.), or else the current one should be used for both (opinions?)

  • There should be an icon for image files
  • There should maybe be a separate icon for interactive things like Flash
  • Probably more file formats should be supported
bzimport added a comment.Via ConduitNov 12 2006, 10:41 PM

ayg wrote:

(and r17594)

bzimport added a comment.Via ConduitNov 13 2006, 3:09 AM

ui2t5v002 wrote:

(In reply to comment #29)

Icons added via CSS in r17593 for ogg, mid, midi, mp3, wav, wma (audio); ogm,
avi, mpeg, mpg (video); pdf (document).

Those two lines don't cover every type of URL, though. For the PDF links, we
had all these selectors:

/* Change the external link icon to an Adobe icon for all PDF files */
/* (in browsers that support these CSS selectors, like Mozilla and Opera) */
#bodyContent a[href$=".pdf"].external,
#bodyContent a[href*=".pdf?"].external,
#bodyContent a[href*=".pdf#"].external,
#bodyContent a[href$=".PDF"].external,
#bodyContent a[href*=".PDF?"].external,
#bodyContent a[href*=".PDF#"].external {

background:

url(http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif)
center right no-repeat;

padding-right: 16px;

}

/* Change the external link icon to an Adobe icon anywhere the PDFlink class */
/* is used (notably Template:PDFlink). This works in IE, unlike the above. */
span.PDFlink a {

background:

url(http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif)
center right no-repeat !important;

padding-right: 17px !important;

}

See
http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_2#Similar_for_PDF_files.3F

  • There should be separate icons for PDFs and other documents (like DOCs, ODFs, etc.), or else the current one should be used for both (opinions?)

Each file type needs its own icon. That's the whole point.

bzimport added a comment.Via ConduitNov 13 2006, 3:18 AM

ayg wrote:

(In reply to comment #31)

Those two lines don't cover every type of URL, though. For the PDF links, we
had all these selectors:

I've implemented those for PDFs. While anchors are used for PDFs, they aren't
for any other filetype I know of besides HTML, and query strings aren't usually
used for any non-dynamic content, so their presence for even PDFs is
questionable. Yes, technically you could add meaningless anchors or query
strings to the end of these things (and MediaWiki actually does add meaningless
query strings to style/script includes for cache control), but you could also
link to a PDF file with ".pDf" if you wanted to.

Each file type needs its own icon. That's the whole point.

Well, each general category does. I largely agree that PDF and document-y files
should have distinct icons because they're noticeably different in terms of user
experience, but PNG vs. JPG is a distinction most viewers will neither know nor
care about.

bzimport added a comment.Via ConduitJun 25 2007, 5:13 PM

ayg wrote:

Unassigning from me, it's graphical work that needs to be done at this point.

bzimport added a comment.Via ConduitSep 9 2007, 11:22 PM

ayg wrote:

Removing patch keyword, no patch is available for what needs to be done now (more icons).

waldyrious added a comment.Via ConduitMay 18 2010, 4:30 PM

(In reply to comment #28)

  • External links should have the icons they currently have for mailto: news: and the like, but http: links should only have the current external link if they go to an html/xhtml/etc page. If they go to a PDF, DOC file, directly to an image, sound file, or video, then the regular external link icon should be replaced with a file type icon.

I don't know if you're aware, but this already happens for some extensions; see http://www.mediawiki.org/wiki/Help:Links#External_links

waldyrious added a comment.Via ConduitMay 18 2010, 4:37 PM

Ugh, sorry, I missed comment #29 -- disregard my remark above.
How un-wiki of Bugzilla that we can't edit or delete our own comments (at least before someone replies to them, it could be possible).

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

bzimport added a comment.Via ConduitNov 9 2011, 7:29 PM

sumanah wrote:

Removing patch keyword per comment 34. If flamurai's patch is now obsolete, flamurai, go ahead and edit its details to mark it obsolete.

Reedy added a comment.Via ConduitFeb 9 2012, 10:07 PM

Comment on attachment 311
Patch to skins/monobook/main.css

Patch is obsolete, code exists in Monobooks main.css

Reedy added a comment.Via ConduitFeb 9 2012, 10:08 PM

Comment on attachment 306
audio icon

Image is in SVN

Reedy added a comment.Via ConduitFeb 9 2012, 10:08 PM

Comment on attachment 308
video icon

Image is in SVN

Reedy added a comment.Via ConduitFeb 9 2012, 10:09 PM

What is still remaining on this?

brion added a comment.Via ConduitSep 29 2013, 4:25 PM

Going through old bugs...

I'm going to Be Bold and 'wontfix' this; the little link icons are awful and notoriously tricky to get right (case issues, parameters on URLs, URLs that look like files but are description pages, etc).

If people want pretty link formatting for specific purposes, consider using a template or explicit style marker for making links in the style you want.

waldyrious added a comment.Via ConduitSep 30 2013, 10:42 AM

(In reply to comment #43)

I'm going to Be Bold and 'wontfix' this; the little link icons are awful and
notoriously tricky to get right (case issues, parameters on URLs, URLs that
look like files but are description pages, etc).

In that case, shouldn't current extension-dependent custom icons be removed too, for the same reasons + consistency?
https://www.mediawiki.org/wiki/Help:Links#External_link_icons

epriestley added a commit: Unknown Object (Commit).Via DaemonsMar 4 2015, 8:22 AM
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).
epriestley added a commit: Unknown Object (Commit).

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.