GNOME Bugzilla – Bug 126553
Some GTK2 themes mess up rendering.
Last modified: 2011-12-10 17:53:20 UTC
Epiphany seems to use the default font and background colours of the currently used GTK2 theme when rendering webpages which do not specify these colours. In most cases, pages will end up looking awful and unreadable. http://hot.ee/kernelpenguin/epibug.png Now this one just looks damn awful. And it's the Epiphany webpage as well. The background colour is specified and is white while the font colour is not and thus Epiphany uses the colour from the current GTK2 theme. And the page ends up unreadable. http://hot.ee/kernelpenguin/epibug2.png This is where it actually looks good because of this bug/feature. Here, the background colour is not specified. In case you are wondering, I'm using a dark theme because my eyes tend to get sore after a while when using bright themes. Possible fix/workaround: Just use black for text and white for background if these colours are not specified.
Uhm isnt that a bug in the page ? If you specify a background you want to specify also a foreground color IHMO. All browser offer colors costumization, so I think web designer should take that in account.
We have no control over page authors who for some reason think that web text will always be black. The problem is that these web authors are not making their pages accessible. (file bugs with them not us, although in the above example we do have control and we should fix it). Note there is a preference available that will always overide pages colors with your theme colors, presumably making all web pages easier on your eyes. Leaving open for the time being cuz we should fix the epiphany web page.
Since this is a common practice on the web and I can name dozens of sites which will "break" when the default text colour is used, then expecting people to "fix" their pages is like waiting for world peace -- it will never happen. The way I see it, since you are refusing to either "fix" it or offer a setting which overrides the theme colours with neutral black-on-white, then I can either: 1. Use another theme. I wouldn't want to. OR 2. Switch back to Firebird. Which is a shame really since Epiphany does look pretty good. Or actually there's a better way. Use black-on-white as the default colours. When the setting to grab colours from the theme is enabled, then do just so. Technically, this is not a bug, but it is certainly a misfeature.
No i'm offering you another option as well Edit->Preferences->Fonts and Colors->always use the desktop theme colors. This will overide page colors with your chosen colors 100% of the time. Which will be low contrast and easy on your eyes. There could be a legitimate argument that this preference should also be available from the view menu as well to make it more easily accessibile (we can discuss that) on a page by page basis. Defaulting to black and white is not an option. You chose a theme every app should honor your theme. Epiphany shouldn't just get up and say i'm ignoring it. The w3c itself recommends that page authors specify all or none of the page colors. The bugs you are seeing are bugs in those web pages, we offer a workaround already for them.
I'm not completely convinced we can ignore the fact that our behavior breaks a lot of web pages (how many would be interesting to know). I know it's the right thing to do, but: - Does our user gain more than lose in real situations ? - Is there a chance the behavior will get fixed in the future ?
I'm not saying to ignore it. I'm saying we already have a solution, with a potential caveat. Number of user who use themes that have text entries that are not white and text that is not black is very small. (this is how we choose our color schemes and is what most web pages assume). So basically the number of people adversly affected by this is small. The default themes that do have this issue in gnome are accessibility oriented. For these users most of them are going to want to use their themes colors (due to color blindness, low light sensitivity etc.). For pages that overide the users colors they have two choices use the colors the page provides or overide them. By default we use the colors the page provides, but if a page doesn't provide a color the best we can do is guess. The sane way to guess is to pick a color from the users theme, afterall this is the color scheme they have specified. Now if a page specifies some but not all colors we have a problem, essentially what we need is an "unbreak this page" button. But what does unbreak really mean. Unbreak doesn't mean hardcode white and black bg and fg respectively. This is broken for the users who are most likely to see this problem (high contrast, low contrast, inversed colors etc.) granted i'd expect these users to set the always use desktop theme colors preference but for the sake of argument lets assume they aren't for whatever reason. What I'm proposing is that if we really think this is an issue than we should make overiding page colors with the theme colors easier. Its saner and for the people most affected will yield better results. This prevents the problem of hardcoding colors and not following themes (an a11y blocker according to billh) while at the same time provides sane "unbreak this page" functionality. A simple way to do this would be to have a simple switch in the view menu near the encoding menu. Another option is a view menu "style" selector". The choices would be Page Colors, Desktop Colors or others if we move to supporting selection of actual style sheets.
>But what does unbreak really mean. Unbreak doesn't mean hardcode white >and black bg and fg respectively. This is broken for the users who are >most likely to see this problem (high contrast, low contrast, inversed >colors etc.) granted i'd expect these users to set the always use >desktop theme colors preference but for the sake of argument lets >assume they aren't for whatever reason. I dont think we can assume for the sake of the argument here. The risk is that you make an user group unhappy for another that doesnt exist :) >A simple way to do this would be to have a simple switch in the view >menu near the encoding menu. As someone proposed on the list maybe we could integrate it with alternate style sheet selector. View->Style-> Desktop Theme (Maybe insert other possible user styles here) ------------- Alternate site style 1 Alternate site style 2
Which reminds me that View menu has already so many items ... :/
Target: 1.2 -> 1.4
Target: 1.4 -> 1.6
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
*** Bug 154723 has been marked as a duplicate of this bug. ***
Hello, what's the scoop on this bug? It's biting me hard.
What exactly is this bug about? The screenshots in comment 0 time out, and there is no testcase either.
Target Milestone: 1.6 -> 1.8
What sites are affected? Have you tried contacting the web master for those sites to advise of the problem?
*** Bug 475979 has been marked as a duplicate of this bug. ***
This bug is still valid, I have reported it in: http://bugzilla.gnome.org/show_bug.cgi?id=516968 It can be easily reproduced with Darklooks theme and going to: http://www.elpais.com/ http://www.lne.es/ I know that it is a web problem, but it is hard mail to all webmasters, I have tried to contact lne and elpais but I am still waiting :-( I think that would be great being able to use white color by default when webpages doesn't specify one
More affected sites: http://vivalinux.com.ar/ http://www.wine-doors.org/wordpress/ http://packagekit.org/ http://blog.cafarelli.fr/post/2007/11/01/Tips-and-tricks%3A-Gentoo-Linux-on-a-Samsung-Q45-laptop
An easy workaround is set gecko to not use system colors. In firefox is very easy change it, simply in "Contents" -> "Colors", but I can't find a similar option in epiphany, then, I have had to use about:config for setting "browser.display.use_system_colors" to "false", and now works as expected :-D Is there any more accesible way of configure colors handling in epiphany?
We don't do this in WebKit, so this should not be an issue anymore.