Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6.2.x styling changes make Kibana hard to read. #16662

Closed
robcowart opened this issue Feb 12, 2018 · 9 comments
Closed

6.2.x styling changes make Kibana hard to read. #16662

robcowart opened this issue Feb 12, 2018 · 9 comments
Labels
Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.

Comments

@robcowart
Copy link

Kibana version:
6.2.0 and 6.2.1

Elasticsearch version:
6.2.0 and 6.2.1

Server OS version:
Centos 7 and MacOS

Browser version:
Chrome - 64.0.3282.140 (Official Build) (64-bit)
Safari - 11.0.2 (13604.4.7.1.3)

Browser OS version: MacOS

Original install method (e.g. download page, yum, from source, etc.): yum repo (CentOS) mac download (MacOS)

Description of the problem including expected versus actual behavior:
Changes in 6.2.x are making Kibana harder to read (examples are nav bar, but it shows up other places too). This is negatively impacting users.

6.1.3 in Chrome... easy to read.
k613_chrome

6.2.1 in Chrome... hard to read.
k621_chrome

6.21 in Safari... also hard to read.
k621_safari

However 6.2.1 in Firefox (58.0.1 64-bit) looks fine.
k621_firefox

Steps to reproduce:

  1. Open 6.2 and 6.1 versions of Kibana in Chrome and Safari and compare.
@timroes timroes added Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. triage_needed labels Feb 12, 2018
@deanpeters
Copy link

deanpeters commented Feb 14, 2018

Was there a change in font-weight attributes here? Yeah, I know, I should be lighting up installs of each and checking, but if someone can hit each the inspector on each of the samples above?

Here's why I ask, we've got an issue of luminosity that appears to be font-weight related, possibly color related. I suspect the former as I think what's happening is that the aliasing that occurs in the course of rendering a font whose color is #FF mean there are other parts of the character that aren't quite #FF so the character is nice, smooth, readable, and not something out of the green screens from the 1970's.

Rather than blather on here are 3 screenshots of the samples against a Colour Analyser.

6.1.3 in Chrome comparing the font color #FF with a strong font-weight against the background #15571:

image

6.1.3 in Chrome comparing an aliased portion of the same character with a stronger font-weight w/a color #E8F1E8 against the background #15571:

image

6.2.1 in Chrome comparing an aliased portion a not so stong font-weight rendering at a color (possibly aliased) with #D8E6EA against a background of #15571

image

When I get a chance, I'll see if I can't get the inspector stood-up on the option with builds on each to see the actual font-weight and color attributes of the above samples ... but that won't be for a few days ... possibly a week ... faster if anyone has any URLs to share :)

@robcowart
Copy link
Author

robcowart commented Feb 14, 2018

I had @svencowart (best UI developer that I know) take a look and he quickly narrowed in on the issue. The problem is related to -webkit-font-smoothing. While this is still set in Kibana 6.2 to antialiasing, it appears that the changes related to react-ifying Kibana (or some other changes) have altered the rendering order, which is causing this issue to occur.

If you search for issues with Webkit and font-smoothing, you will find plenty of complaints and not a lot of solutions. This is why I see the issue on Chrome and Safari... they are the Webkit browsers.

Apparently if font-smoothing is applied at the end, after the page is rendered, it works. Try this in developer tools and you will see that setting it to something like initial or subpixel-antialiasing will make everything look right. That is not because those values are the fix, rather that developer tools is altering the page after it has been rendered. In order to fix the issue it will necessary to somehow apply -webkit-font-smoothing: antialiasing at the end of page rendering, or return the render order to the way it was in 6.1 and earlier. (@svencowart also mentioned how sometimes transforms are used to affect a change after rendering to cause things to be applied after the fact to work around such issues, but also mentioned it was hack - I might be saying this wrong, as I am close to over my head here)

@timroes I notice you set the triage_needed tag. I think the above troubleshooting may point in the right direction.

@deanpeters
Copy link

@robcowart , yeah, sounds like your UI guy is on target with their assessment.

@robcowart
Copy link
Author

Here is how to fix this...

In the directory KIBANA_HOME/node_modules/@elastic/eui/dist there are four CSS files:

  • eui_theme_dark.css
  • eui_theme_k6_dark.css
  • eui_theme_k6_light.css
  • eui_theme_light.css

In each of these files find the style attributes for the html tag. They will look something like this:

html {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
  font-weight: 400;
  font-size: 16px;
  color: #DDD;
  height: 100%;
  background-color: #272727;
  -webkit-font-smoothing: antialiased; }

Delete -webkit-font-smoothing: antialiased;

Finally delete the directory KIBANA_HOME/optimize/bundles and restart Kibana. After the optimization process has run, you will be able to launch Kibana, and fonts should look good again!

@snide
Copy link
Contributor

snide commented Feb 20, 2018

Just some comments.

The background color for that nav area changed in 6.0 alpha and hasn't changed since then. The screenshots for contrast you're linking to are using imperfect eye pickers and not the actual hex codes used, so your screenshots as pasted above are not correct. As mentioned, the colors in use there haven't changed since we upped contrast for accessibility and still continue to pass. Inspect the document and look for the hex codes themselves when doing these kinds of checks. The eyedroppers will always lie.

https://github.com/elastic/kibana/pull/12085/files

On to the real culprit. Font-smoothing was turned on when we removed the bootstrap reset (as we started to transition towards EUI usage across Kibana). FWIW it's usually preferred for the use case you list (light text on dark backgrounds). It tends to be a fairly subjective design decision. More often than not it is preferred by people who are used to more OSXey style text rendering.

In the end there's no setting that everyone will prefer so I'm inclined to remove it for the simple reason that it has no plans to be included in the standard CSS spec.

@kihlstrom
Copy link

As a design decision it may be subjective, but from an accessibility or readability perspective it would appear wise to remove -webkit-font-smoothing: antialiased; as soon as possible.

Any way I can help getting this fixed? Should I create a pull request?
(I'm new here and don't know the rules...)

@snide
Copy link
Contributor

snide commented Mar 19, 2018

Font smoothing will be removed with elastic/eui#539

Further, we now provide full color combo legibility tests for Kibana's new UI framework at https://elastic.github.io/eui/#/guidelines/colors if you're curious about how we test for this.

The Elastic UI Framework is not in full usage across Kibana, so expect these formulas and standards to gradually move into Kibana as we move towards 7.0. Till then pieces of Kibana might reflect legacy color combinations.

@robcowart
Copy link
Author

Thanks for the update @snide. Regarding testing, I noticed your comment, in the issue which you linked to, that you prefer the font-smoothing being enabled. I can guess from that that you have a retina display, maybe even the LG 5K monitor (as many at Elastic do). I will admit that font-smoothing looks OK on those screens. However, the vast majority of users don't have that luxury. Ideally testing would include inspection of things on more common monitors.

@snide
Copy link
Contributor

snide commented Mar 19, 2018

@robcowart Yep. And that's ultimately why I think it's better to remove it. No worries, I agree it makes sense. I also just wanted to put together some resources to give the community a place to see what Kibana design has brewing so you aren't necessarily reacting to things as we release them. As you can peep from that repo we're taking accessibility and inclusive design pretty seriously around here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.
Projects
None yet
Development

No branches or pull requests

6 participants