Closed Bug 478632 Opened 15 years ago Closed 7 years ago

Awesome bar link color on linux

Categories

(Firefox :: Theme, defect)

Product:
Firefox
Component:
Theme
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: micmon, Unassigned)

Details

Attachments

(4 files, 2 obsolete files)

Screenshot of the awesomebar in Firefox 3.1b3
60.77 KB, image/png
Details
Screenshot of the awesomebar in Firefox 3.0.x
87.66 KB, image/png
Details
Patch 3
923 bytes, patch
faaborg
: ui-review-
Details | Diff | Splinter Review
Screenshot of patch 3
55.14 KB, image/png
Details 
The blue color of links in the awesomebar window really hurts my eyes. What about using a slightly less aggressive blue?

Tango blue would be nice... try:

.ac-url-text { color: #204a87 !important; }
.ac-url-text[selected] { color: inherit !important; }
Nice idea! #204A87 looks really better!
Hardcoding blue is a bad idea. The current blue comes from the colour of text links in your GTK theme, if you change it to something like Dark Room it should end up being a grey colour.
Michael, how is this color supposed to be called in GTKRC? I don't find a matching color definition which I could change in my theme :/
While Tango's blue is an awesome shade of blue (I'm a bit biased, naturally), hardcoding the link color is not the right solution.

The awesomebar's display completely breaks with themes that use a dark menu, like Shiki-Colors or Ubuntu's new Dust theme.

Jakub Steiner (jimmac) and I have run into this very same problem when designing a new theme. 

It only seems to affect Firefox 3.1+.. 3.0.x works fine.

Will attach screenshots of 3.1b3 and 3.0.x
>Hardcoding blue is a bad idea. The current blue comes from the colour of text
>links in your GTK theme, if you change it to something like Dark Room it should
>end up being a grey colour.

Anyone know what bug changed the behavior?  It is entirely possible that it is my fault for giving it a ui-r+ without thinking, but as several people have mentioned this does create a problem for different themes, especially accessibility high contrast themes.
Should we make the URL colour the same colour as the title text, but with slightly less opacity (say, 70%)? This would probably fix things for dark themes.
Do we use the right background? If so, it's a GTK theme bug.
We use the same background as menu popups, but those typically don't have links in them. What we could use is the GtkEntryCompletion popups, but that really isn't feasible for 3.5 (I got contact from OpenSUSE guys saying they want to switch to a dark theme by default Real Soon Now, and this bug is stopping them).
Attached patch Patch (obsolete) — — Splinter Review 
This looks really good.
Attachment #377663 - Flags: review?(dao)
Comment on attachment 377663 [details] [diff] [review]
Patch

Actually, there's one part of this code I shouldn't remove.
Attachment #377663 - Attachment is obsolete: true
Attachment #377663 - Flags: review?(dao)
Attached patch Patch 2 (obsolete) — — Splinter Review 
Better patch.
Attachment #377665 - Flags: review?(dao)
(In reply to comment #10)
> (I got contact from OpenSUSE guys saying they want to
> switch to a dark theme by default Real Soon Now, and this bug is stopping
> them).

Is it (1) a dark theme or (2) a mixed dark/light theme? For 1), why don't they specify an appropriate link color? For 2), I think it should still be possible for them to find a blue shade that's readable on dark and light backgrounds (e.g. #67f), or they could patch browser.css themselves, assuming they distribute Firefox.
Attachment #377665 - Flags: review?(dao) → review-
Comment on attachment 377665 [details] [diff] [review]
Patch 2

r-, pending response to comment 14. Reducing the opacity of text also raises accessibility concerns.
So far options have included:

1) keep the color the same (con: doesn't look great)

2) hard code a new color (con: accessibility concerns)

Would either of these two options potentially work?:

3) work with the gnome community to update OS themes (con: possibly hard)

4) special case the color change so that it looks better in certain situations, and doesn't introduce accessibility concerns (con: greater code complexity)
(In reply to comment #14)
> (In reply to comment #10)
> > (I got contact from OpenSUSE guys saying they want to
> > switch to a dark theme by default Real Soon Now, and this bug is stopping
> > them).
> 
> Is it (1) a dark theme or (2) a mixed dark/light theme? For 1), why don't they
> specify an appropriate link color? For 2), I think it should still be possible
> for them to find a blue shade that's readable on dark and light backgrounds
> (e.g. #67f), or they could patch browser.css themselves, assuming they
> distribute Firefox.

Could you please document how to define such a link color in a gtk themerc?
Has a decision been taken regarding this bug for Firefox 3.6/7? The current way it works really doesn't look great with Xubuntu's default theme..
(In reply to comment #15)
> (From update of attachment 377665 [details] [diff] [review])
> r-, pending response to comment 14. Reducing the opacity of text also raises
> accessibility concerns.

what are those accessibility concerns? at least from "screen-reader" POV the color shouldn't make a difference, right?

(In reply to comment #14)
> specify an appropriate link color? For 2), I think it should still be possible
> for them to find a blue shade that's readable on dark and light backgrounds
> (e.g. #67f), or they could patch browser.css themselves, assuming they
> distribute Firefox.

Why should we patch this ourselves rather than fixing upstream? If this does not work with all decent themes, then we definitely don't want it in ubuntu. At best we would be able to tweak these colors in gtk+ theme. If thats not easy to do atm, the current patch looks like a reasoanble approach to me.
here a screen with using 0.65 opacity (0.75 as suggested in the patch should be better though): http://imagebin.ca/img/LKSlnTlN.jpg
(In reply to comment #19)
> here a screen with using 0.65 opacity (0.75 as suggested in the patch should be
> better though): http://imagebin.ca/img/LKSlnTlN.jpg

the left side is _with_ the change ... the right side is the current situation.
(In reply to comment #17)
> Could you please document how to define such a link color in a gtk themerc?
> Has a decision been taken regarding this bug for Firefox 3.6/7? The current way
> it works really doesn't look great with Xubuntu's default theme..

I don't know anything about themerc's, but GTK's source code has this:

      gtk_widget_style_get (GTK_WIDGET (link_button), 
			    "link-color", &link_color, NULL);
      if (!link_color)
	link_color = &default_link_color;

I don't know if you can set style properties directly from a theme file. If not, then that would answer comment #14 (and I also think accessibility concerns are moot, since it is still text).
Reducing a native color's opacity is almost as bad as hardcoding a color. We don't want to do that because it breaks high-contrast themes (those chosen by visually impaired users) and low-contrast themes (where further reducing the contrast could affect legibility even for unimpaired users). Accessibility isn't limited to screen reader access.
(In reply to comment #22)
> Reducing a native color's opacity is almost as bad as hardcoding a color.

Absolutely not. You still take the text colour which was designed to look good and readable on the background, you just make it a bit softer. The opacity level is still so high that if doing this makes the text unreadable then the text in the original colour wouldn't be readable either.

I have tried this with high and low contrast themes and the results are actually quite good, much better than what we have now.
(In reply to comment #23)
> (In reply to comment #22)
> > Reducing a native color's opacity is almost as bad as hardcoding a color.
> 
> Absolutely not. You still take the text colour which was designed to look good

That's why I wrote "almost": beyond accessibility, hardcoded colors are bad because they break themes' color palettes. That's not a concern here.

> and readable on the background, you just make it a bit softer. The opacity
> level is still so high that if doing this makes the text unreadable then the
> text in the original colour wouldn't be readable either.

Readability isn't just there or not there. If reducing the opacity by a third didn't make the text less readable (and I don't necessarily mean completely unreadable), I would expect the theme author to reduce the contrast in the first place as a means to making the theme less jarring. So I think we can assume that it actually reduces readability for any carefully designed theme. Now, trying a few themes and judging whether the result still seems good enough for you isn't sufficient, since everybody has different eyes.
(In reply to comment #24)
> Readability isn't just there or not there. If reducing the opacity by a third
> didn't make the text less readable (and I don't necessarily mean completely
> unreadable), I would expect the theme author to reduce the contrast in the
> first place as a means to making the theme less jarring. So I think we can
> assume that it actually reduces readability for any carefully designed theme.
> Now, trying a few themes and judging whether the result still seems good enough
> for you isn't sufficient, since everybody has different eyes.

A carefully designed theme that caters for all eyes is one that ensures the maximum possible readability, so much so that even slight variations in the chosen colours won't make a difference. This opacity change allows the eye to distinguish between the colours of two lines of text, but you won't be able to distinguish the difference from the background.

I think you're worrying about this way too much. Most themes are suffering from our use of the link colour, whereas no theme I've tried, even less popular ones, have shown any kind of readability issues with this patch. If they are, that person is likely using assistive tech anyway.
I don't think a carefully designed theme needs to cater for all eyes. It could be optimized for people with perfect vision, using rather low contrast (which we don't want to lower further), or for people with rather poor vision, using a high contrast (which we don't want to lower either). If there's an issue with the link color that themes can't fix, we should go back to GrayText.
I would like to comment that the screenshot is with 75% opacity, while the one in the comment above was 65%, which I found to be a little bit low, personally. As far as I'm concerned, 95 or even 100% opacity would be perfectly valid. I don't think having two different colours for those links being so critical.

The most important to me is to fix that broken colour in Firefox that is still here at the moment. I'll try to look into how to get links coloured in the theme but I still think it would be wizer not to expect that from all theme developers.

I wish we can find an agreement on a decent way to improve this within the next 10 days... Firefox's awesome bar is currently broken in Xubuntu and we will soon reach our final freeze.

Thanks in advance.
>Firefox's awesome bar is currently broken in Xubuntu and we will
>soon reach our final freeze.

Using the native's themes link color gives the OS theme the most control, and helps to make sure that Firefox is fully visually integrated.  If we start changing the colors to work well with a particular OS theme, then we will subsequently break on a bunch of other OS themes.  So while I agree that the appearance on Xubuntu is broken (ugly, bad accessibility, etc.), I think this is ultimately a problem with Xubuntu's choice of link color/background color, and the best approach is for them to update their OS theme.
(In reply to comment #26)
> I don't think a carefully designed theme needs to cater for all eyes. It could
> be optimized for people with perfect vision, using rather low contrast (which
> we don't want to lower further), or for people with rather poor vision, using a
> high contrast (which we don't want to lower either). If there's an issue with
> the link color that themes can't fix, we should go back to GrayText.

We moved away from GrayText because of exactly this kind of issue. Why aren't we doing so now? I'd be happy to increase opacity or even remove opacity.

How about we give the URL the same colour as the title text but we indent it a little bit?
(In reply to comment #29)
> We moved away from GrayText because of exactly this kind of issue.

Can you elaborate? I don't remember if there was a Linux-specific issue with GrayText.

If the issue was that GrayText is often too faint but under the control of the OS themes, then it's the OS themes that need fixing.
(In reply to comment #30)
> (In reply to comment #29)
> > We moved away from GrayText because of exactly this kind of issue.
> 
> Can you elaborate? I don't remember if there was a Linux-specific issue with
> GrayText.
> 
> If the issue was that GrayText is often too faint but under the control of the
> OS themes, then it's the OS themes that need fixing.

No, we were using it where we weren't meant to. To get GrayText I believe we were getting the disabled text colour for buttons. Since buttons have darker colours than menupopups, it was fine where it was meant to be used.

It's arrogant to suggest that every theme accommodates our misuse of colours.
I'm not too sure if a separate colour for disabled menu items is available, but if we can get it we might be able to introduce a new CSS colour to use it.
I've put a GtkWidget::link-color value in Xubuntu's themerc and it indeed works well. But I had to use a "greyish" color to make sure it would also hypotetically look ok on a white background since other apps are likely to use link-color, and I didn't find out how to explicitely target the awesome bar entries.

Another solution for this problem that I can see now is having the awesome bar having its own gtk class (GtkAwesomeBar, GtkAwesomeBarEntry), which would of course only inheritate from the classes it belongs to now. The interest of it would be that people who write gtk themes could then target these very widgets to change the link-color here.

There wouldn't be the contrast problem that is posed when changing the link-color for every app. And the tip to theme Firefox's awesome bar could then be spread quite easily among themers.

I don't know how complex that solution would be to setup, though.
We don't use Gtk widgets, so we can't give the panel its own Gtk class.

I could still try my previous suggestion of giving the URL a little bit of extra padding.
Attached patch Patch 3 — — Splinter Review 
Actually, this looks surprisingly good.
Attachment #377665 - Attachment is obsolete: true
Attached image Screenshot of patch 3 — 
I've tested URL overflow as well and it works. If readability is such an issue then this should have no problems fitting in with every theme out there.
Attachment #404787 - Flags: review?(dao)
(In reply to comment #31)
> (In reply to comment #30)
> > Can you elaborate? I don't remember if there was a Linux-specific issue with
> > GrayText.
> > 
> > If the issue was that GrayText is often too faint but under the control of the
> > OS themes, then it's the OS themes that need fixing.
> 
> No, we were using it where we weren't meant to. To get GrayText I believe we
> were getting the disabled text colour for buttons. Since buttons have darker
> colours than menupopups, it was fine where it was meant to be used.

GrayText is not meant to be used in buttons only. If the widget code translates it to such a color, that's a bug.
Attachment #404787 - Flags: review?(dao) → ui-review?(faaborg)
Ah, my mistake, GrayText is indeed gotten from disabled menuitems, but on the most common themes it was still pretty unreadable, having all that light grey text in one popup, which was why we switched away from it.
Comment on attachment 404787 [details] [diff] [review]
Patch 3

We want to differentiate titles and URLs with color (really any color) so that the user can visually select on them.  It's kind of hard to explain in text, here is an example put together when we were discussing the design in Firefox 3.

Time how long it takes you to find all of the M's and then time how long it takes you to find all of the green letters, notice how you can focus on a color and they all visually pop out at you.  Just a quirk with how we process the input, works for color but not shape.

http://people.mozilla.com/~faaborg/files/daf/cogSciColorSelect.png

Anyway, if the user knows that they are trying to match some of the text in the URL (and not the title), they can select their visual processing on the color and do a quick scan avoiding the title lines.
Attachment #404787 - Flags: ui-review?(faaborg) → ui-review-
What is the status on that?
Firefox 4.0b12 still has the same issue.
In openSUSE we are still carrying a patch to make the stuff readable at all.
No longer relevant with Photon theme.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: