Wikimedia Bugzilla is closed!

Added in r20065, removed in r20340.

The mentioned thread is http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/30603 dealing with users (which don't need a checker background) vs editors (for which it's useful).

Unless you want re-discuss this on WikiTech-l, I think it is clearly WONTFIX for now.

I started a discussion here: http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/051447.html

As I said in the e-mail, there's definitely a missing functionality here: being able to figure out if an image background is white or transparent. Having this functionality in MediaWiki may already be filed in Bugzilla, but I don't know of any dupes off-hand.

This doesn't necessarily need to be implemented in site-wide CSS, but the functionality should exist in some sane format. Re-opening this for now.

Based on comments on the mailing list, a toggle on the file description page (with a sensible global default that can be customized per-project) seems like the best solution to this problem. It balances the needs of editors with the needs of readers.

I've updated this bug's summary accordingly from "Add checkered background to transparent image backgrounds" to "Add toggle for checkered or transparent image background on file description pages". I've also added the "easy" keyword, as I don't think implementing this would be very difficult.

Probably wouldn't be that hard with some jquery magic to add some css (background image) onto the div...

I like the toggle idea on the image description page, provided the history images remain transparent. Users should also be able to set a default in their preferences (under Appearence).

Instead of JavaScript, how about a pure css solution, changing the background to checkered on hover? That'd be cleaner, simpler and make the verification of background transparency even faster than clicking a toggle link/button.

(In reply to comment #7)
> Instead of JavaScript, how about a pure css solution, changing the background
> to checkered on hover? That'd be cleaner, simpler and make the verification of
> background transparency even faster than clicking a toggle link/button.

Not bad at all, but when manually scanning a category or gallery page, having to hover each to see if and how an image is transparent would not be very user friendly.

I'd suggest making a preference dropdown:
* Apply checkered background on hover [CSS :hover { background } ]
* Don't apply checkered backgrounds []
* Apply checkered backgrounds by default [CSS { background} ]

Still no javascript required. and a small bit of css is added/removed (the same way the css for stub articles is dynamically loaded in a special way).

Alternatively, if this would fragment cache (not sure if it does, I don't expect it will) - we could opt for a pseudo-javascript implementation, in which the preference is set and can be retrieved via javascript ( mw.user.options.get('checkedbackground') ), and then css can be added on-load by a core module (ie. mediawiki.js or mediwiki.util.js)

Are galleries and categories subject of this discussion? I was under the impression that only the main image on an image description page should be toggled.

(In reply to comment #8)
> Alternatively, if this would fragment cache (not sure if it does, I don't
> expect it will)

It wouldn't.

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

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

On second thought, I'm not so sure if adding yet more preferences is good thing.

It seems the hover toggle is the way to go. (Not on galleries though, just the main image; enwiki uses transparency only on non-article galleries.) A hover toggle is as simple as adding ":hover" to common.css, and maybe moving the CSS to core all together.

I'll take this one.

(In reply to comment #13)
> On second thought, I'm not so sure if adding yet more preferences is good
> thing.
Totally agreed.

> It seems the hover toggle is the way to go. (Not on galleries though, just the
> main image; enwiki uses transparency only on non-article galleries.) A hover
> toggle is as simple as adding ":hover" to common.css, and maybe moving the CSS
> to core all together.
Done in r91756

Reverted in r91761, therefor reopened.

As Krinkle commented, we need to flesh out how this should be done. Since many sites already have transparency set in their CSS, this patch would not have worked reliably anyway. I think we should leave the choice the the respective sites on what they want to do with their CSS.

I tried the hover CSS for some weeks, but that isn't quit it either. A more elegant solution would be to have some image toolbar/applet above the image, styled after the edit toolbar, that can toggle tranparency combined with toggling the checkered background and even choose background color, and store it's settings as a cookie. That should be easy to achieve.

(In reply to comment #16)
> Reverted in r91761, therefor reopened.
> 
> As Krinkle commented, we need to flesh out how this should be done. Since many
> sites already have transparency set in their CSS, this patch would not have
> worked reliably anyway. I think we should leave the choice the the respective
> sites on what they want to do with their CSS.
> 
> I tried the hover CSS for some weeks, but that isn't quit it either. A more
> elegant solution would be to have some image toolbar/applet above the image,
> styled after the edit toolbar, that can toggle tranparency combined with
> toggling the checkered background and even choose background color, and store
> it's settings as a cookie. That should be easy to achieve.

AFAIK it's hard to impossible (maybe using canvas?) to detect whether an image has an alpha channel via JS.
And showing the toolbar on every non-transparent image is rather irritating (because it won't do anything)

I had not considered that.

>AFAIK it's hard to impossible (maybe using canvas?) to detect whether an image
>has an alpha channel via JS.
>And showing the toolbar on every non-transparent image is rather irritating
>(because it won't do anything)

I really do not like that idea. Remember how annoying the IE image toolbar was (maybe thats just me). I do not think that would be good usability, even if used only on transparent images. (Also, things that only appear on some images without being appearent why, especially tooltip things, are annoying too. See the title on links bug and the controversy that caused)

>Since many
>sites already have transparency set in their CSS, this patch would not have
>worked reliably anyway. I think we should leave the choice the the respective
>sites on what they want to do with their CSS.

Why not. The C in CSS stands for cascading. I do not think we should care about weird hacks wikis do unless they cause severe incompatibility (which this doesn't. At worse on hover the background would change to a different transparent image). Most mediawiki users (outside of Wikimedia) will not know enough to do custom css stuff.


(for reference, I think the hover on file pages only solution is a good idea)

I wa thinking more about a static bar above the image, not the kind that pops up like in IE.

I know what the C stands for. The reason why it may not work is because local CSS overrides the CSS in core. Enwiki now has a static bg-image; placing a hover in the core CSS will be overridden by that static bg-image. But that is indeed not a big issue.

I am asuming that the scope of this bug is the image description page only, so transparency outside of the image description page (such as galleries in non-article space) are not considered.

On the image description page, there are two elements: the main image, and the thumbnails in the history table. I propose we make main image transparent on hover, and the history thumbs permanently transparent. That would done as follows:

/*
 * Add a checkered background image on hover for file description pages.
 */
.filehistory a img,
#file img:hover {
    /* @embed */
    background: white url(images/Checker-16x16.png) repeat;
}

This basically means the previous patch had one 'hover' too many.

(In reply to comment #20)
> /*
>  * Add a checkered background image on hover for file description pages.
>  */
> .filehistory a img,
> #file img:hover {
>     /* @embed */
>     background: white url(images/Checker-16x16.png) repeat;
> }
> 
> This basically means the previous patch had one 'hover' too many.

Fine with me. Anyone against it? Otherwise I'll commit that in a few days.

Looks good to me.

People who only need to know "if" an image is transparent can either scroll down or hover the image, and for more precision the hover on the main image on the description page can be used.

It will not show transparency on articles, which I think is a good thing.

(In reply to comment #21)
> (In reply to comment #20)
>> /*
>>  * Add a checkered background image on hover for file description pages.
>>  */
>> .filehistory a img,
>> #file img:hover {
>>     /* @embed */
>>     background: white url(images/Checker-16x16.png) repeat;
>> }
>> 
>> This basically means the previous patch had one 'hover' too many.
> 
> Fine with me. Anyone against it? Otherwise I'll commit that in a few days.

Bump.

Patch resend with r96270.
Since it is kind of a new feature, it will be in 1.19.

Project or user css:
How can we get it like it was before (checkered background on the file page permanently)?  Would it also be possible to invert the hover action?  Ie: white/page background on hover?

Permanent checkered background:

#file img {
    /* @embed */
    background: white url(//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png) repeat;
}

Reverse hover:

#file img {
    /* @embed */
    background: white url(//upload.wikimedia.org/wikipedia/commons/5/5d/Checker-16x16.png) repeat;
}
#file img:hover {
    background: white;
}