Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Background for standalone images, redux

553 views
Skip to first unread message

Boris Zbarsky

unread,
May 10, 2012, 5:15:30 PM5/10/12
to
I know this has been discussed to death in Bugzilla, but...

Today I happened to click a link to
http://www.cdc.gov/nchs/data/databriefs/db88_fig1.png

Go ahead. Load that in a recent Firefox. Take a look.

The complaints about this in Bugzilla have basically been responded to
with "this is the UI design decision we made". I'd really like to
understand _why_ we made the design decision this way. I understand the
whole "put a dark matte around the image" bit. What I don't understand
is why we're not giving the image itself a white background.

To recap, the effects of that compared to what we have now would be:

JPEG: no effect; JPEGs are opaque so the background would be invisible.
Opaque PNG: no effect.
Transparent PNG: painted on top of white, like in other browsers, so
more likely to be visible if people actually want it to be visible.

In particular, any transparent PNG expected to actually print well on
paper would look better on a white background, obviously. Any PNG
designed to be viewable well in current browsers would look better on white.

There are some cases which would be worse off in the new setup: white or
near-white PNGs. An example is at
<http://www.mozilla.org/media/img/sandstone/buttons/arrow-small.png>.
Do we think that these cases are more prevalent than the cases that
would be improved?

Again, if there are solid reasons for not doing this, I'd just like to
know what they are. The responses to my questions in Bugzilla were ...
uninformative at best.

Thanks for reading this far,
Boris

Jared Wein

unread,
May 10, 2012, 5:23:53 PM5/10/12
to Boris Zbarsky, dev-apps...@lists.mozilla.org
I think it comes down to the intention of the person who created the image. If somebody chose to make a transparent PNG, shouldn't we respect that decision and render it the way it was designed?

- Jared

Dao

unread,
May 10, 2012, 5:29:08 PM5/10/12
to
On 10.05.2012 23:23, Jared Wein wrote:
> I think it comes down to the intention of the person who created the image. If somebody chose to make a transparent PNG, shouldn't we respect that decision and render it the way it was designed?

If the result is illegible, that somebody isn't going to applaud you.
It's not like that person asked for a dark background.

Mart Rootamm

unread,
May 10, 2012, 5:31:22 PM5/10/12
to dev-apps-firefox
If someone made a transparent PNG, they'd typically expect to place it in a
white or white-like (light gray, à la #C0C0C0) background, and not black.
The surrounding background colour should be kept as is.

-Mart.

2012/5/11 Jared Wein <jw...@mozilla.com>

> I think it comes down to the intention of the person who created the
> image. If somebody chose to make a transparent PNG, shouldn't we respect
> that decision and render it the way it was designed?
>
> - Jared
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

Martijn

unread,
May 10, 2012, 5:36:54 PM5/10/12
to Boris Zbarsky, dev-apps...@lists.mozilla.org
Yeah, I agree.
I don't like the dark background on images, either.
I can't think of a good reason why this behavior has changed.

Regards,
Martijn

> Thanks for reading this far,
> Boris
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox



--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22

Stephen Horlander

unread,
May 10, 2012, 5:44:49 PM5/10/12
to
> If someone made a transparent PNG, they'd typically expect to place it in a
> white or white-like (light gray, à la #C0C0C0) background

We can't know what color someone expects their transparent image to be
displayed on.

If I am designing something that is transparent I design knowing the
context it will be displayed in. If I am unsure of the conditions I
don't make it transparent.

- Stephen

Dao

unread,
May 10, 2012, 5:49:43 PM5/10/12
to
On 10.05.2012 23:44, Stephen Horlander wrote:
> If I am designing something that is transparent I design knowing the
> context it will be displayed in. If I am unsure of the conditions I
> don't make it transparent.

Then again, not every person putting images on the web is you...

Mart Rootamm

unread,
May 10, 2012, 5:50:36 PM5/10/12
to Martijn, dev-apps...@lists.mozilla.org
>
> Yeah, I agree.
> I don't like the dark background on images, either.
>

I actually like it, because it makes it easier to look at images,
especially photos and dark images, because it's difficult to discern detail
with a large white background.

(I remember old Netscape up until 4.x used a simple gray background for
stand-alone photos and then at some point in Firefox it was changed to
white for some reason. I know IE still usesthe white colour as background
for stand-alone photos.)

YouTube recently changed its background colour from white to light-gray
(probably #aaaaaa).


> I can't think of a good reason why this behavior has changed.
>

To save on battery life :-)

-Mart.

2012/5/11 Martijn <martijn...@gmail.com>

> On Thu, May 10, 2012 at 11:15 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Yeah, I agree.
> I don't like the dark background on images, either.
> I can't think of a good reason why this behavior has changed.
>
> Regards,
> Martijn
>
> > Thanks for reading this far,
> > Boris

Stephen Horlander

unread,
May 10, 2012, 6:00:38 PM5/10/12
to
I wasn't trying to imply that they were.

Justin Dolske

unread,
May 10, 2012, 6:02:52 PM5/10/12
to
On 5/10/12 2:15 PM, Boris Zbarsky wrote:

> The complaints about this in Bugzilla have basically been responded to
> with "this is the UI design decision we made". I'd really like to
> understand _why_ we made the design decision this way. I understand the
> whole "put a dark matte around the image" bit. What I don't understand
> is why we're not giving the image itself a white background.

The basic objection has been that for every transparent image that needs
a white background to be legible, it's trivial to find other images that
look bad on a white background.

For example; http://www.mozilla.org/images/template/screen/logo_footer.png

Go ahead. Load that in an old Firefox. Take a look. ;-)

Here's a screenshot for the lazy: http://cl.ly/2h2i0X452U0D3b3j0Y0i

Putting a bright white rectangle behind every transparent image isn't
very visually elegant.

> Again, if there are solid reasons for not doing this, I'd just like to
> know what they are. The responses to my questions in Bugzilla were ...
> uninformative at best.

The above has been the primary reasoning for this. I'm pretty sure it's
been noted in the various bugs, but it's easy to get lost amid all the
flaming back and forth.

Anyway, gavin and jared and I sat down and talked things through, and
we're agreed to try the |img { background-color: white }| approach.
There's no perfect solution here, and it feels like the right tradeoff
between retaining the new visual design and unbreaking the images that
have been expecting a white background.

Justin

Dao

unread,
May 10, 2012, 6:09:39 PM5/10/12
to
Then I'm not sure what your point is. Clearly there are people who don't
follow the rule you pose. Blaming them for carelessly making images
transparent doesn't work. They as well as their users will blame Firefox
for breaking this since it used to work in Firefox and keeps working in
every other browser.

Martijn

unread,
May 10, 2012, 6:12:35 PM5/10/12
to Justin Dolske, dev-apps...@lists.mozilla.org
On Fri, May 11, 2012 at 12:02 AM, Justin Dolske <dol...@mozilla.com> wrote:
> On 5/10/12 2:15 PM, Boris Zbarsky wrote:
>
>> The complaints about this in Bugzilla have basically been responded to
>> with "this is the UI design decision we made".  I'd really like to
>> understand _why_ we made the design decision this way.  I understand the
>> whole "put a dark matte around the image" bit.  What I don't understand
>> is why we're not giving the image itself a white background.
>
>
> The basic objection has been that for every transparent image that needs a
> white background to be legible, it's trivial to find other images that look
> bad on a white background.
>
> For example; http://www.mozilla.org/images/template/screen/logo_footer.png
>
> Go ahead. Load that in an old Firefox. Take a look. ;-)
>
> Here's a screenshot for the lazy: http://cl.ly/2h2i0X452U0D3b3j0Y0i
>
> Putting a bright white rectangle behind every transparent image isn't very
> visually elegant.

I don't think it looks that bad with a white background, the image is
still perfectly viewable.

Regards,
Martijn

>
>> Again, if there are solid reasons for not doing this, I'd just like to
>> know what they are.  The responses to my questions in Bugzilla were ...
>> uninformative at best.
>
>
> The above has been the primary reasoning for this. I'm pretty sure it's been
> noted in the various bugs, but it's easy to get lost amid all the flaming
> back and forth.
>
> Anyway, gavin and jared and I sat down and talked things through, and we're
> agreed to try the |img { background-color: white }| approach. There's no
> perfect solution here, and it feels like the right tradeoff between
> retaining the new visual design and unbreaking the images that have been
> expecting a white background.
>
> Justin
>

Boris Zbarsky

unread,
May 10, 2012, 6:40:02 PM5/10/12
to
On 5/10/12 5:44 PM, Stephen Horlander wrote:
> If I am designing something that is transparent I design knowing the
> context it will be displayed in.

Right, and for the web that context was "white background" across all
browsers until recently... That's the point.

-Boris

Boris Zbarsky

unread,
May 10, 2012, 6:43:26 PM5/10/12
to
On 5/10/12 6:02 PM, Justin Dolske wrote:
> Anyway, gavin and jared and I sat down and talked things through, and
> we're agreed to try the |img { background-color: white }| approach.

Sounds good! Should I do white, or user's default background from
prefs? They're both pretty easy; the latter just needs a bit more C++ code.

> There's no perfect solution here, and it feels like the right tradeoff
> between retaining the new visual design and unbreaking the images that
> have been expecting a white background.

That sentence right there pretty much exactly matches how I feel about
this and is the reason I brought this up.... in particular, I agree that
its not perfect. We really need to work on that strong AI that will be
able to make decisions like this in sub-millisecond times. ;)

-Boris

Daniel Cater

unread,
May 10, 2012, 6:41:47 PM5/10/12
to
For the curious, image comes from here: http://www.cdc.gov/nchs/data/databriefs/db88.htm

Are there any common programs that output images like this by default? It seems like someone would have to actively choose a transparent background. This is the first time I've noticed this issue, and even then the text is not invisible (and it's not excessively small in-page with the white background).

Dao

unread,
May 10, 2012, 6:51:31 PM5/10/12
to
On 11.05.2012 00:43, Boris Zbarsky wrote:
> On 5/10/12 6:02 PM, Justin Dolske wrote:
>> Anyway, gavin and jared and I sat down and talked things through, and
>> we're agreed to try the |img { background-color: white }| approach.
>
> Sounds good! Should I do white, or user's default background from prefs?
> They're both pretty easy; the latter just needs a bit more C++ code.

background-color: -moz-default-background-color; should work if we
wanted this, but I'm not sure why we would want this.

Mart Rootamm

unread,
May 10, 2012, 6:58:15 PM5/10/12
to dev-apps...@lists.mozilla.org
I was thinking of a background color slider:
<---------------------->
white black

^ All this overlayed above a stand-alone image and visible when a user
hovers either over the image or past the background. Something like this.

-Mart.

2012/5/11 Boris Zbarsky <bzba...@mit.edu>
> ______________________________**_________________
> dev-apps-firefox mailing list
> dev-apps-firefox@lists.**mozilla.org <dev-apps...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-apps-firefox<https://lists.mozilla.org/listinfo/dev-apps-firefox>
>

Jared Wein

unread,
May 10, 2012, 8:11:31 PM5/10/12
to Boris Zbarsky, dev-apps...@lists.mozilla.org
Was there a bug filed for this change? I can make the change if nobody else has started on it yet.

- Jared

Boris Zbarsky

unread,
May 10, 2012, 8:35:40 PM5/10/12
to
On 5/10/12 8:11 PM, Jared Wein wrote:
> Was there a bug filed for this change? I can make the change if nobody else has started on it yet.

I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=754133

If you patch, I'll review. ;)

-Boris

Stephen Horlander

unread,
May 10, 2012, 9:09:01 PM5/10/12
to
Right, until recently, which was my point :)

The only way to know for sure what the context will be is if you
control it, which is not the case if you hand the image off to the
browser. There is no guarantee that the default background will always
white, as is the case here.

Even without this change the previous behvaior was variable as well. If
the background color was changed or if they happened to be running a
high-contrast system theme. Of course these are not common cases and
they were opt-in not forced. However in my experience websites direct
linking to translucent/transparent images isn't all that common either.

- Stephen

Asa Dotzler

unread,
May 11, 2012, 12:37:31 AM5/11/12
to
Few people will "carelessly make images transparent." It's work. You
don't do that work unless you want the image transparent. If you want
the image transparent, you very likely have a context in mind. We cannot
know that context.

- A

Asa Dotzler

unread,
May 11, 2012, 12:38:11 AM5/11/12
to
Not at all. There are lots of web pages that have a non-white background.

- A

Asa Dotzler

unread,
May 11, 2012, 12:42:14 AM5/11/12
to
Unless they designed the image to be displayed on a dark background.
Maybe we should get some data about the most common background colors
used on the web and work from there.

- A

Boris Zbarsky

unread,
May 11, 2012, 12:59:01 AM5/11/12
to
Yes, but we're talking about cases when an image is loaded standalone.

I guess there are two ways that can happen:

1) "View image" selected by user from an image context menu.
2) Actual link to a standalone image on a web page.

I ran into this largely in the context if (2). The fact that web pages
can have various colored backgrounds largely affects (1)....

-Boris

Geoff Lankow

unread,
May 11, 2012, 1:26:26 AM5/11/12
to
Why don't we just have a small button in the corner to switch the
background colour, when we're showing a standalone image? (Like the
on/off switch in about:newtab, for example.)

Gian-Carlo Pascutto

unread,
May 11, 2012, 1:40:05 AM5/11/12
to
On 11/05/2012 6:42, Asa Dotzler wrote:
> On 5/10/2012 2:29 PM, Dao wrote:
>> On 10.05.2012 23:23, Jared Wein wrote:
>>> I think it comes down to the intention of the person who created the
>>> image. If somebody chose to make a transparent PNG, shouldn't we
>>> respect that decision and render it the way it was designed?
>>
>> If the result is illegible, that somebody isn't going to applaud you.
>> It's not like that person asked for a dark background.
>
> Unless they designed the image to be displayed on a dark background.

If there's a reasonable use case for viewing the image standalone, the
best bet is that they designed it for a white background: that's what
you get in every browser besides Firefox 11+.

Put differently, until a few months ago images designed for a black
background wouldn't have worked anywhere, and images designed for a
light background worked everywhere.

I think there's a good argument to assume designers designed for
something that was known to work rather than something that was known
never to work.

--
GCP

Asa Dotzler

unread,
May 11, 2012, 2:56:45 AM5/11/12
to
I can't think of a time in recent memory when a site linked me to a
standalone image. I do, on the other hand, open images standalone all
the time via the context menu. When the new image background doesn't
work for me I just do a view image info and look at it there.

- A

Asa Dotzler

unread,
May 11, 2012, 3:01:01 AM5/11/12
to
Designers design for how the image will look in their web page. They are
not designing alpha png images to be viewed stand-alone. Alpha pngs are
basically useless stand-alone. The likely reason that an alpha png image
ends up being viewed stand-alone is a user like you or me opening the
image ourselves via a context menu.

- A

AlfredKayser

unread,
May 11, 2012, 4:18:43 AM5/11/12
to

Indeed, so when viewing an PNG or GIF standalone, you want to see the
alpha part as well, just like in an image editor (such as Paint.net).
So, an option would be use a patterned background like so:
background:-moz-Dialog url(data:image/
png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEWgoKClpaUrSK7yAAAAAnRSTlNkFG3Yt
+YAAAAPSURBVHheY2D4jxXhEgYAfr8P8SM7T18AAAAASUVORK5CYII=);

This is implemented in my themes: LittleFox, Nautipolis, Walnut,
Walnut2 and Microfox, so install one of these to test this.
(Note, the data url is needed to prevent an image load during the
image load/display...)

Dao

unread,
May 11, 2012, 5:01:03 AM5/11/12
to
On 11.05.2012 09:01, Asa Dotzler wrote:
> On 5/10/2012 10:40 PM, Gian-Carlo Pascutto wrote:
>> If there's a reasonable use case for viewing the image standalone, the
>> best bet is that they designed it for a white background: that's what
>> you get in every browser besides Firefox 11+.
>>
>> Put differently, until a few months ago images designed for a black
>> background wouldn't have worked anywhere, and images designed for a
>> light background worked everywhere.
>>
>> I think there's a good argument to assume designers designed for
>> something that was known to work rather than something that was known
>> never to work.
>>
>
> Designers design for how the image will look in their web page. They are
> not designing alpha png images to be viewed stand-alone.

Except when they do, as happened with
http://www.cdc.gov/nchs/data/databriefs/db88_fig1.png that bz came across.

Gervase Markham

unread,
May 11, 2012, 5:18:56 AM5/11/12
to
On 10/05/12 23:43, Boris Zbarsky wrote:
> That sentence right there pretty much exactly matches how I feel about
> this and is the reason I brought this up.... in particular, I agree that
> its not perfect. We really need to work on that strong AI that will be
> able to make decisions like this in sub-millisecond times. ;)

Here's a simple algorithm for deciding whether to use white or grey. It
would be used only in the case where > 2 corner pixels are 100%
transparent (otherwise, we'd stick with grey):

For each image corner:
Take the corner pixel
while (fully transparent)
move inwards 1px in each direction
take brightness value of pixel

Take brightness value of centre pixel
If a majority of the 5 pixels reached have > 0.5 brightness
grey background
else
white background

We should be able to make this decision quicker than a user can perceive :-)

Gerv

Asa Dotzler

unread,
May 11, 2012, 5:20:00 AM5/11/12
to
Which do you think is the more common case for a designer creating alpha
pngs, as part of pages with colored or patterned backgrounds or as
standalone images?

It's always easy to find a few exceptions but we shouldn't be designing
for the exceptional cases.

- A

Dao

unread,
May 11, 2012, 5:35:40 AM5/11/12
to
The former, but these images also seem less relevant for this discussion
-- many of them will look bad standalone no matter what we do.

Philip Chee

unread,
May 11, 2012, 7:32:16 AM5/11/12
to
On Thu, 10 May 2012 23:56:45 -0700, Asa Dotzler wrote:
> On 5/10/2012 9:59 PM, Boris Zbarsky wrote:
>> On 5/11/12 12:38 AM, Asa Dotzler wrote:
>>> On 5/10/2012 3:40 PM, Boris Zbarsky wrote:
>>>> On 5/10/12 5:44 PM, Stephen Horlander wrote:
>>>>> If I am designing something that is transparent I design knowing the
>>>>> context it will be displayed in.
>>>>
>>>> Right, and for the web that context was "white background" across all
>>>> browsers until recently... That's the point.
>>>>
>>>> -Boris
>>>
>>> Not at all. There are lots of web pages that have a non-white background.
>>
>> Yes, but we're talking about cases when an image is loaded standalone.
>>
>> I guess there are two ways that can happen:
>>
>> 1) "View image" selected by user from an image context menu.
>> 2) Actual link to a standalone image on a web page.
>>
>> I ran into this largely in the context if (2). The fact that web pages
>> can have various colored backgrounds largely affects (1)....
>>
>> -Boris
>
> I can't think of a time in recent memory when a site linked me to a
> standalone image. I do, on the other hand, open images standalone all

I guess you don't visit anime and image forums, or follow some people on
twitter who post raw screencaps.

> the time via the context menu. When the new image background doesn't
> work for me I just do a view image info and look at it there.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

Rob Campbell

unread,
May 11, 2012, 10:10:32 AM5/11/12
to dev-apps...@lists.mozilla.org
On 2012-05-11, at 6:35 AM, Dao wrote:

> On 11.05.2012 11:20, Asa Dotzler wrote:
>> On 5/11/2012 2:01 AM, Dao wrote:
>>> On 11.05.2012 09:01, Asa Dotzler wrote:
>>>> Designers design for how the image will look in their web page. They are
>>>> not designing alpha png images to be viewed stand-alone.
>>>
>>> Except when they do, as happened with
>>> http://www.cdc.gov/nchs/data/databriefs/db88_fig1.png that bz came
>>> across.
>>
>> Which do you think is the more common case for a designer creating alpha
>> pngs, as part of pages with colored or patterned backgrounds or as
>> standalone images?
>
> The former, but these images also seem less relevant for this discussion -- many of them will look bad standalone no matter what we do.

I think images with transparencies taken out of their original context are going to look strange no matter what we do (unless they were designed for white or black backgrounds and we happen to have the appropriate one).

For the dark background I'm going to suggest something radical: Look at what photo software does to display images. Web sites, photography software, and indeed, physical photography studios employ "light boxes" to display images. This consists of a lighted box (obviously!), with a sheet of white translucent paper over it to diffuse the underlying light and an slide or translucent image overlaid on that. The edges can be blacked out or greyed out to accentuate the image.

So for our images, we could do the same, in order from bottom to top:

1. Matte (provide options for white, grey or dark, maybe with one or two levels in between).
2. White layer (this could extend around the image to form a border)
3. Image

If we're doing this to make the images look better standalone, I think this is how we do it. Note that control of the background color is actually important here because not all images are going to work with a dark background.

Was UX ever consulted on this feature?

>> It's always easy to find a few exceptions but we shouldn't be designing
>> for the exceptional cases.

We should be designing with a goal in mind. "Make images look good in stand alone".

~ rob

Zack Weinberg

unread,
May 11, 2012, 11:04:06 AM5/11/12
to
On 2012-05-10 10:40 PM, Gian-Carlo Pascutto wrote:
>
> If there's a reasonable use case for viewing the image standalone, the
> best bet is that they designed it for a white background: that's what
> you get in every browser besides Firefox 11+.

As a data point only, just yesterday I discovered that Gmail has added a
cute feature to their mail composer on iPad (possibly other tablets as
well): you can pop up a window in which you can doodle. Whatever you
draw gets turned into a .png and attached to the email.

The doodle window shows you drawing on a light-gray background, but the
.png that's generated has a transparent background. And back on a
desktop machine in Firefox 11, Gmail's "view" link for .pngs loads the
image standalone. Result: the same effect Boris was complaining about
at the beginning of the thread.

zw

Boris Zbarsky

unread,
May 11, 2012, 11:08:05 AM5/11/12
to
On 5/11/12 2:56 AM, Asa Dotzler wrote:
> I can't think of a time in recent memory when a site linked me to a
> standalone image

Interesting. Maybe we read different blogs. ;) The ones I read have a
strong tendency to embed graphs resized down, with a link direct to the
full-size image.

> When the new image background doesn't
> work for me I just do a view image info and look at it there.

That works for me and you, but seems sucky for users in general. We
really need something that works better than that, if we can.

-Boris

Boris Zbarsky

unread,
May 11, 2012, 11:08:53 AM5/11/12
to
On 5/11/12 3:01 AM, Asa Dotzler wrote:
> Designers design for how the image will look in their web page.

And the better ones also for how it will look in print.

> The likely reason that an alpha png image
> ends up being viewed stand-alone is a user like you or me opening the
> image ourselves via a context menu.

I think it _really_ depends on your browsing patterns.

-Boris

Boris Zbarsky

unread,
May 11, 2012, 11:09:59 AM5/11/12
to
On 5/11/12 5:18 AM, Gervase Markham wrote:
> Here's a simple algorithm for deciding whether to use white or grey. It
> would be used only in the case where> 2 corner pixels are 100%
> transparent (otherwise, we'd stick with grey):
>
> For each image corner:
> Take the corner pixel
> while (fully transparent)
> move inwards 1px in each direction
> take brightness value of pixel
>
> Take brightness value of centre pixel
> If a majority of the 5 pixels reached have> 0.5 brightness
> grey background
> else
> white background
>
> We should be able to make this decision quicker than a user can perceive :-)

For a large image, that may not be the case, because just extracting the
pixel data can take a while.

-Boris

Zack Weinberg

unread,
May 11, 2012, 11:26:45 AM5/11/12
to
On 2012-05-11 8:09 AM, Boris Zbarsky wrote:
> On 5/11/12 5:18 AM, Gervase Markham wrote:
>> Here's a simple algorithm for deciding whether to use white or grey. It
>> would be used only in the case where> 2 corner pixels are 100%
>> transparent (otherwise, we'd stick with grey):
...
>> We should be able to make this decision quicker than a user can
>> perceive :-)
>
> For a large image, that may not be the case, because just extracting the
> pixel data can take a while.

Long run, I think I like best the idea of adding some controls to the
standalone image view, so the user can adjust the background color as
they see fit, or switch to Photoshop-esque checks, or whatever. There
are other common problems with looking at standalone images that could
be addressed that way, e.g. photos in the wrong orientation.

zw

EE

unread,
May 11, 2012, 1:02:18 PM5/11/12
to
Why do you consider that to be a bug? I think the dark grey background
looks nicer anyway.

papa...@gmail.com

unread,
May 12, 2012, 6:56:49 AM5/12/12
to
On Thursday, 10 May 2012 23:29:08 UTC+2, Dao wrote:
> It's not like that person asked for a dark background.

Maybe he did and he set the bKGD chunk accordingly.

L. David Baron

unread,
May 12, 2012, 6:55:42 AM5/12/12
to Boris Zbarsky, dev-apps...@lists.mozilla.org
On Thursday 2012-05-10 18:43 -0400, Boris Zbarsky wrote:
> On 5/10/12 6:02 PM, Justin Dolske wrote:
> >Anyway, gavin and jared and I sat down and talked things through, and
> >we're agreed to try the |img { background-color: white }| approach.
>
> Sounds good! Should I do white, or user's default background from
> prefs? They're both pretty easy; the latter just needs a bit more
> C++ code.

Given that the reason for doing this is that using non-white breaks
Web content, it seems like the right thing is to use white.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

EE

unread,
May 12, 2012, 2:21:34 PM5/12/12
to
On 2012-05-12 03:55, L. David Baron wrote:
> On Thursday 2012-05-10 18:43 -0400, Boris Zbarsky wrote:
>> On 5/10/12 6:02 PM, Justin Dolske wrote:
>>> Anyway, gavin and jared and I sat down and talked things through, and
>>> we're agreed to try the |img { background-color: white }| approach.
>>
>> Sounds good! Should I do white, or user's default background from
>> prefs? They're both pretty easy; the latter just needs a bit more
>> C++ code.
>
> Given that the reason for doing this is that using non-white breaks
> Web content, it seems like the right thing is to use white.
>
> -David
>

What do you mean, "using non-white breaks Web content"? If you choose
View Image, you get just that one image by itself in a tab, and it never
looks broken to me.

Matt Brubeck

unread,
May 12, 2012, 6:53:11 PM5/12/12
to EE
On 05/12/2012 11:21 AM, EE wrote:
> What do you mean, "using non-white breaks Web content"? If you choose
> View Image, you get just that one image by itself in a tab, and it never
> looks broken to me.

As mentioned elsewhere in this thread, the issue is with web content
that links directly to transparent images that do are not properly
visible against dark backgrounds, for example the link when you click
the chart on this web page:
http://www.cdc.gov/nchs/data/databriefs/db88.htm

Andrew Poth

unread,
May 12, 2012, 6:58:30 PM5/12/12
to
> > I can't think of a good reason why this behavior has changed.
>
> To save on battery life :-)
>
> -Mart.
>
> 2012/5/11 Martijn <martijn.mart...@gmail.com>

Nonsense. Battery life is only an issue with portable devices, most
of which use LCD screens, and the screen backlight is either ON or
OFF, regardless of what's being displayed on the screen. This MIGHT
be an issue for handheld devices that use OLED displays, but I can't
think of any currently on the market. I'd be very surprised if this
was even a consideration when the standalone image presentation style
was changed in Firefox/SeaMonkey.

Andrew Poth

unread,
May 12, 2012, 7:03:51 PM5/12/12
to
On May 12, 3:55 am, "L. David Baron" <dba...@dbaron.org> wrote:
> Given that the reason for doing this is that using non-white breaks
> Web content, it seems like the right thing is to use white.
>

A standalone image isn't "Web content". It's just a standalone image
and one happens to be using the Web browser to view it.

EE

unread,
May 13, 2012, 1:30:34 PM5/13/12
to
I see. So, you would be better off just downloading the image.

Gian-Carlo Pascutto

unread,
May 13, 2012, 1:38:50 PM5/13/12
to
On 13/05/2012 19:30, EE wrote:

> I see. So, you would be better off just downloading the image.

The image looks exactly as broken if you download it as compared to
viewing it online.

Or did you mean downloading and then looking at it with *other* software
that defaults to a white background? That's pretty much confirming that
Firefox's current behavior is wrong.

--
GCP

Alexander Skwar

unread,
May 13, 2012, 1:41:20 PM5/13/12
to EE, dev-apps...@lists.mozilla.org
Hi
Yep, he'd be better off, if he wouldn't be using
Firefox. Is that the message? 'coz that's how it
sounds. You're suggesting Chrome, for instance,
if that's a use case?

Honestly, I don't quite get what's that brickering
is all about. It's obvious (to me), that some pictures
look bad, if the background is dark. I haven't yet
seen a transparent stand alone pic, which looks
good on a dark background; or, at least, the vast
majority looks good on bright backgrounds.

Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯
↯ Chat (Jabber/Google Talk) ↣ a.s...@gmail.com , AIM: alexws77  ↯

Gian-Carlo Pascutto

unread,
May 13, 2012, 1:50:42 PM5/13/12
to
On 11/05/2012 19:02, EE wrote:

> Why do you consider that to be a bug? I think the dark grey background
> looks nicer anyway.

Note that "background" in this discussion isn't the page background
surrounding the image. That won't change. It's the part *directly
behind* the image that you can't normally see unless it's a
*transparent* image. And for transparent pictures dark grey tends to be
horrible as it makes (most) images almost invisible.

The original post contains pictures that pretty much explain the
problem. I hope nobody you aren't arguing that black text on a dark grey
background looks nice :)

--
GCP

Ron Hunter

unread,
May 13, 2012, 4:48:17 PM5/13/12
to
Why not check several spots under the image for color/luminosity, and
then make the background look like that in the stand-alone? Too simple?


Stéphane Roucheray

unread,
May 13, 2012, 5:24:57 PM5/13/12
to dev-apps...@lists.mozilla.org
I guess because you can't find anything 'under' the image given a direct
link to that image.

Given there is no definitive solution to this issue, I would suggest to
solve it the same way the majority of graphic softwares do, using a
checkerboard (light gray / white) as the background of the image,
keeping the dark gray surrounding it. It would look like this
http://i.imgur.com/YYb57.jpg
As an option their could be a visual switch to disable the checkerboard
and/or a visual indicator telling the user he is looking at a
semi-transparent image.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

Ron Hunter

unread,
May 13, 2012, 8:16:14 PM5/13/12
to
On 5/13/2012 4:24 PM, Stéphane Roucheray wrote:
> I guess because you can't find anything 'under' the image given a direct
> link to that image.
>

> Given there is no definitive solution to this issue, I would suggest to
> solve it the same way the majority of graphic softwares do, using a
> checkerboard (light gray / white) as the background of the image,
> keeping the dark gray surrounding it. It would look like this
> http://i.imgur.com/YYb57.jpg

That's both ugly and visually confusing.


> As an option their could be a visual switch to disable the checkerboard
> and/or a visual indicator telling the user he is looking at a
> semi-transparent image.
>

If the image is transparent, then there MUST have been some definition
of the color behind it, or it would not render well. If white works
better, then use white for the color behind the image, and grey for the
rest of the screen.

Gervase Markham

unread,
May 14, 2012, 5:31:04 AM5/14/12
to
On 11/05/12 16:09, Boris Zbarsky wrote:
> For a large image, that may not be the case, because just extracting the
> pixel data can take a while.

But surely we need such data to display the image?

Also, there's nothing wrong with starting dark, and fading to light when
we realise the problem. That would actually look pretty cool - Firefox
"learns" what's correct and does it.

Gerv

sabine.micha...@gmail.com

unread,
May 14, 2012, 7:04:25 AM5/14/12
to
If I had a transparent image containing white lines then it would be a mess on a white background and if it contained black lines it would be a mess on a dark background.

It makes sense to me that we start with a neutral color and make a background-color transition after detecting the best background color for the image.

Detecting the best color could be a challenge though.

Boris Zbarsky

unread,
May 14, 2012, 10:24:21 AM5/14/12
to
On 5/14/12 5:31 AM, Gervase Markham wrote:
> On 11/05/12 16:09, Boris Zbarsky wrote:
>> For a large image, that may not be the case, because just extracting the
>> pixel data can take a while.
>
> But surely we need such data to display the image?

No, "we" (as in, the Gecko main thread) don't. The _GPU_ needs such
data to display the image. And the GPU may well have the data; we'd
just need to ask for it and then wait until it shows up.

> Also, there's nothing wrong with starting dark, and fading to light when
> we realise the problem. That would actually look pretty cool - Firefox
> "learns" what's correct and does it.

Nothing wrong except for the fact that the only APIs that we have for
getting the image data are sync. So you'd have the UI freeze up for a
bit there while getting the data.

The numbers we have for this for large images, last I checked, are in
the 10-100ms range on desktop. Multiply by a factor of somewhere
between 10 and 100 for mobile...

-Boris

sabine.micha...@gmail.com

unread,
May 14, 2012, 10:36:41 AM5/14/12
to
> The numbers we have for this for large images, last I checked, are in
> the 10-100ms range on desktop. Multiply by a factor of somewhere
> between 10 and 100 for mobile...

Ouch, in that case I would vote for either white or light grey as those colors would be better for most images.

EE

unread,
May 14, 2012, 1:06:17 PM5/14/12
to
The software I used to view the image after downloading puts a light
diamond pattern in the background to indicate transparency.

Dao

unread,
May 14, 2012, 6:54:19 PM5/14/12
to
On 13.05.2012 00:58, Andrew Poth wrote:
>>> I can't think of a good reason why this behavior has changed.
>>
>> To save on battery life :-)
>>
>> -Mart.
>>
>> 2012/5/11 Martijn<martijn.mart...@gmail.com>
>
> Nonsense. Battery life is only an issue with portable devices, most
> of which use LCD screens, and the screen backlight is either ON or
> OFF, regardless of what's being displayed on the screen.

LED backlight can be dimmed... The ASUS Zenbook makes use of this, for
instance...

John Volikas

unread,
May 17, 2012, 3:05:07 PM5/17/12
to
This is in the latest Nightly and works well with one caveat. When switching to a tab with a standalone image, where decoded image data where discarded, the user is presented with a brief white flash while the image is decoded again.

This can be very annoying and even disorienting if you are switching from a tab with dark content while browsing with no lighting. Ideally the white background should be rendered only when there's a decoded image displayed.

On Friday, May 11, 2012 12:15:30 AM UTC+3, Boris Zbarsky wrote:
> I know this has been discussed to death in Bugzilla, but...
>
> Today I happened to click a link to
> http://www.cdc.gov/nchs/data/databriefs/db88_fig1.png
>
> Go ahead. Load that in a recent Firefox. Take a look.
>
> The complaints about this in Bugzilla have basically been responded to
> with "this is the UI design decision we made". I'd really like to
> understand _why_ we made the design decision this way. I understand the
> whole "put a dark matte around the image" bit. What I don't understand
> is why we're not giving the image itself a white background.
>
> To recap, the effects of that compared to what we have now would be:
>
> JPEG: no effect; JPEGs are opaque so the background would be invisible.
> Opaque PNG: no effect.
> Transparent PNG: painted on top of white, like in other browsers, so
> more likely to be visible if people actually want it to be visible.
>
> In particular, any transparent PNG expected to actually print well on
> paper would look better on a white background, obviously. Any PNG
> designed to be viewable well in current browsers would look better on white.
>
> There are some cases which would be worse off in the new setup: white or
> near-white PNGs. An example is at
> <http://www.mozilla.org/media/img/sandstone/buttons/arrow-small.png>.
> Do we think that these cases are more prevalent than the cases that
> would be improved?
>
> Again, if there are solid reasons for not doing this, I'd just like to
> know what they are. The responses to my questions in Bugzilla were ...
> uninformative at best.
>
> Thanks for reading this far,
> Boris

John Volikas

unread,
May 18, 2012, 11:40:28 AM5/18/12
to
Filed Bug 756419 [1] FWIW

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=756419

Heikki Jussila

unread,
May 19, 2012, 5:49:08 PM5/19/12
to

lay...@gmail.com

unread,
Dec 7, 2012, 10:18:49 AM12/7/12
to
I was sent a link to this discussion by wordpress tech support because I had filed a ticket about the new image issues. I use transparency a lot on my blog (I make collages) and my problem with the format is not that the background is white v/s grey v/s black, but that a standalone image pops up on a grey background but the image dimensions are WHITE...making it look like my image is not a png but jpeg with a white background. For example, this image http://conversewithbirds.files.wordpress.com/2012/11/thanksgiving_qtrsz1.png looks like it's on white paper...but it's not...it's a cut-out. I miss the "cut-out_ effect when a stand-alone image is shown white on a black background. I don't care what the background color is, but the transparency should be rendered in the *same color*.
0 new messages