Last modified: 2014-11-18 18:07:18 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.
(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
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.
I meant bug 1254... sorry about that.
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.
Created attachment 305 [details] Screenshot of proposed media links with icons
Created attachment 306 [details] audio icon
Created attachment 307 [details] document icon
Created attachment 308 [details] video icon
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.
Created attachment 310 [details] improved document icon (not in screenshot)
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.)
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.
*** Bug 3726 has been marked as a duplicate of this bug. ***
*** Bug 1311 has been marked as a duplicate of this bug. ***
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.
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/
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
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.
(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.
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.
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.
(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?
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.
(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.
> There's no way to link to PDFs or DOC files internally. [[Media:Wiki this, wiki that.pdf]]
(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".
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.
(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.
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
(and r17594)
(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.
(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.
Unassigning from me, it's graphical work that needs to be done at this point.
Removing patch keyword, no patch is available for what needs to be done now (more icons).
(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
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).
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
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 on attachment 311 [details] Patch to skins/monobook/main.css Patch is obsolete, code exists in Monobooks main.css
Comment on attachment 306 [details] audio icon Image is in SVN
Comment on attachment 308 [details] video icon Image is in SVN
What is still remaining on this?
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.
(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
