Last modified: 2014-11-18 18:07:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3578, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1578 - External links to .doc/.odf/.swf/image files should have their own custom icons
External links to .doc/.odf/.swf/image files should have their own custom icons
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: design
: 1311 3726 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-24 01:17 UTC by flamurai
Modified: 2014-11-18 18:07 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot of proposed media links with icons (3.25 KB, image/png)
2005-02-24 05:48 UTC, flamurai
Details
audio icon (312 bytes, image/png)
2005-02-24 05:48 UTC, flamurai
Details
document icon (265 bytes, image/png)
2005-02-24 05:48 UTC, flamurai
Details
video icon (215 bytes, image/png)
2005-02-24 05:48 UTC, flamurai
Details
Patch to /skins/monobook/main.css (877 bytes, patch)
2005-02-24 05:54 UTC, flamurai
Details
improved document icon (not in screenshot) (270 bytes, image/png)
2005-02-24 05:58 UTC, flamurai
Details
Patch to skins/monobook/main.css (877 bytes, patch)
2005-02-24 22:46 UTC, flamurai
Details

Description flamurai 2005-02-24 01:17:40 UTC
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.
Comment 1 T. Gries 2005-02-24 01:32:06 UTC
(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
Comment 2 flamurai 2005-02-24 03:05:32 UTC
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.
Comment 3 flamurai 2005-02-24 03:06:10 UTC
I meant bug 1254... sorry about that.
Comment 4 flamurai 2005-02-24 05:44:58 UTC
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.
Comment 5 flamurai 2005-02-24 05:48:01 UTC
Created attachment 305 [details]
Screenshot of proposed media links with icons
Comment 6 flamurai 2005-02-24 05:48:24 UTC
Created attachment 306 [details]
audio icon
Comment 7 flamurai 2005-02-24 05:48:39 UTC
Created attachment 307 [details]
document icon
Comment 8 flamurai 2005-02-24 05:48:55 UTC
Created attachment 308 [details]
video icon
Comment 9 flamurai 2005-02-24 05:54:42 UTC
Created attachment 309 [details]
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.
Comment 10 flamurai 2005-02-24 05:58:04 UTC
Created attachment 310 [details]
improved document icon (not in screenshot)
Comment 11 flamurai 2005-02-24 22:46:06 UTC
Created attachment 311 [details]
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.)
Comment 12 Ævar Arnfjörð Bjarmason 2005-02-26 03:12:05 UTC
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.
Comment 13 Zigger 2005-11-04 12:46:29 UTC
*** Bug 3726 has been marked as a duplicate of this bug. ***
Comment 14 Zigger 2005-11-04 12:50:07 UTC
*** Bug 1311 has been marked as a duplicate of this bug. ***
Comment 15 Omegatron 2005-11-04 14:56:15 UTC
I made a similar proposal here:

http://en.wikipedia.org/wiki/Template_talk:Audio#Feature_request

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

This would be really helpful.
Comment 16 Omegatron 2006-01-24 03:42:34 UTC
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/  
Comment 17 Omegatron 2006-11-10 14:58:20 UTC
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
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-10 15:01:49 UTC
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.
Comment 19 Omegatron 2006-11-10 16:03:18 UTC
(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.
Comment 20 Omegatron 2006-11-10 16:06:36 UTC
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.
Comment 21 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-10 21:06:36 UTC
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.
Comment 22 Omegatron 2006-11-10 21:20:49 UTC
(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?
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-12 03:27:35 UTC
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.
Comment 24 Omegatron 2006-11-12 05:13:38 UTC
(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.
Comment 25 Rob Church 2006-11-12 08:36:40 UTC
> There's no way to link to PDFs or DOC files internally.

[[Media:Wiki this, wiki that.pdf]]
Comment 26 Omegatron 2006-11-12 15:57:48 UTC
(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".
Comment 27 Rob Church 2006-11-12 19:00:28 UTC
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.
Comment 28 Omegatron 2006-11-12 19:18:29 UTC
(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.
Comment 29 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-12 22:39:36 UTC
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
Comment 30 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-12 22:41:33 UTC
(and r17594)
Comment 31 Omegatron 2006-11-13 03:09:25 UTC
(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.
Comment 32 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-13 03:18:27 UTC
(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.
Comment 33 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-25 17:13:05 UTC
Unassigning from me, it's graphical work that needs to be done at this point.
Comment 34 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-09 23:22:06 UTC
Removing patch keyword, no patch is available for what needs to be done now (more icons).
Comment 35 Waldir 2010-05-18 16:30:23 UTC
(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
Comment 36 Waldir 2010-05-18 16:37:22 UTC
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).
Comment 37 p858snake 2011-04-30 00:09:39 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 38 Sumana Harihareswara 2011-11-09 19:29:20 UTC
Removing patch keyword per comment 34.  If flamurai's patch is now obsolete, flamurai, go ahead and edit its details to mark it obsolete.
Comment 39 Sam Reed (reedy) 2012-02-09 22:07:45 UTC
Comment on attachment 311 [details]
Patch to skins/monobook/main.css

Patch is obsolete, code exists in Monobooks main.css
Comment 40 Sam Reed (reedy) 2012-02-09 22:08:13 UTC
Comment on attachment 306 [details]
audio icon

Image is in SVN
Comment 41 Sam Reed (reedy) 2012-02-09 22:08:27 UTC
Comment on attachment 308 [details]
video icon

Image is in SVN
Comment 42 Sam Reed (reedy) 2012-02-09 22:09:16 UTC
What is still remaining on this?
Comment 43 Brion Vibber 2013-09-29 16:25:24 UTC
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.
Comment 44 Waldir 2013-09-30 10:42:41 UTC
(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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links