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

More & better titling #627

Merged
merged 19 commits into from
Apr 5, 2018
Merged

More & better titling #627

merged 19 commits into from
Apr 5, 2018

Conversation

cchaos
Copy link
Contributor

@cchaos cchaos commented Apr 3, 2018

Main takeaway

The euiTitle mixin now allows a font-size parameter to be passed which will also set the correct line-height and font-weight for that title level. This means that all titles at that particular font-size will look the same no matter the component. (Consistency)

Big differences

Only the top 2 levels of titling are in the light font weight. The titles get bolder as you decrease font size. This helps to separate heading from content especially when they are similar sizes – increases scan-ability.

More title levels

Since the page title should always be the largest, and highest level, title and we are currently using <EuiTitle size="l" /> for page titles, this needs to remain the top most level. Therefore, I could only add more titling levels on the small size, hence the new xs, xxs, and xxxs values allowed for the size prop.

This also meant that the large size should utilize the $euiFontSizeXXL (largest font size) variable since no other font size should be larger than it. So I manipulated our font size scale a bit

from:

$euiFontSizeXS:     $euiFontSize * .75 !default;
$euiFontSizeS:      $euiFontSize * .875 !default;
$euiFontSizeM:      $euiFontSize * 1.125 !default;
$euiFontSizeL:      $euiFontSize * 1.5 !default;
$euiFontSizeXL:     $euiFontSize * 2 !default;
$euiFontSizeXXL:    $euiFontSize * 3 !default;

to

$euiFontSizeXS:     $euiFontSize * .75 !default;
$euiFontSizeS:      $euiFontSize * .875 !default;
$euiFontSizeM:      $euiFontSize * 1.125 !default;
$euiFontSizeL:      $euiFontSize * 1.25 !default;
$euiFontSizeXL:     $euiFontSize * 1.75 !default;
$euiFontSizeXXL:    $euiFontSize * 2.25 !default;

screen shot 2018-04-03 at 13 37 20 pm

I'm also allowing a uppercase prop to be passed to convert it to all caps

EuiText

The EuiText component also utilizes the same euiTitle mixin though it then converts the font-size to a percentage to be sure it changes with the text's base font size. I also tried to utilize em units wherever possible (some margins needed to remain in px). I also added max-width: 36rem.

The only difference between our default titling and the ones in EuiText is that the 3rd level is bolder. I found that in the case of large text areas, the bold helped to separate the content visually and offer better scan-ability. However, it seemed way too bold if it stood on it's own as is the case with EuiTitle.

screen shot 2018-04-03 at 13 40 12 pm

Other changes

  • Removed the doc specific text styling
  • Increased font-size of fig captions in docs
  • Decreased title font color slightly
  • Modified most components who have some sort of title in them to utilize the new mixin - this means that in some cases, the component's title weight has changed ex: EuiSidebar. This is an intentional change.

@cchaos cchaos requested a review from snide April 3, 2018 17:50
Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works great. They pop now.

Looks like the props tab on EuiTitle doesn't work. Was broken on master, but you may as well fix it while you're in there. Likely just not being passed correctly in the example docs. Sometimes I've seen issues with it around null returns #384

image

Think you'll want to add the new titles to the actual EuiText docs rather than just to the text scaling stuff.

Once my eyes got used to it, the bolding looks good. Only place that it bugs me is when we use underlines. You might want to adjust the EuiCard hover states to use color, rather than an underline now. It can look at a little weird with the thick underlines. Pretty minor.

image


const classes = classNames(
'euiTitle',
titleSizeToClassNameMap[size],
{
'euiTitle--uppercase': uppercase,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd make this a map rather than a boolean. Maybe textTransform="uppercase"

@@ -21,25 +22,25 @@
ol,
blockquote,
img {
margin-bottom: $euiSizeL;
margin-bottom: 1.5em;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is the same thing, but we're getting a little loose with when we use em, rem and pixels. Not saying pixels are the way (they definitely are not), but we should probably do something more wholesale against our files at some point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Youp, I totally get that, however I they're not necessarily replacements for each other and there is value is using them in certain ways. I'm using em's inside of the .EuiText component because we want the font-sizing, margins, line-height, etc to scale with the base font size we set for the whole of the component. We can't use 'rem' here because 'rem' is only based off the the font size set on (the whole document), so this doesn't change when changing the base font size of .EuiText. Therefore, if we use em's, thought it's based on the current element's font size and not it's parent's base font size, it will scale appropriately. Otherwise, if we use px or rem units, the spacing will be much more dramatic at the smaller scale text sizes.

After I had written all that out, I realized that since the base font size of .EuiText is known to use we can actually just do calculations on that to set margins in rem values. Though this does mean that we will have to set each margin individually at every size. But we could probably make a mixin for that.

I have thought about wrapping our px values attached to the sizing variables in the convertToRem() function so we are always using rem values. But that's for another day.

}

blockquote {
position: relative;
text-align: center;
margin-left: auto;
margin-right: auto;
padding: $euiSizeL;
padding: 1.5em;
max-width: 36rem;
font-family: Georgia,Times,Times New Roman,serif;
font-size: 112.5%;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might wanna change this calc to match your others.

line-height: $euiSizeXL;
@include euiTitle($euiFontSizeXL);
font-size: ($euiFontSizeXL/$euiFontSize)*100%; /* 1 */
margin-bottom: .6em;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do these margin values come from? Each title is a little different and they end up computing a little loose. Ends up kind of weird when they all have a pixel value for the margin-top.

Again, not too worried about ems themselves perse, but this ends up a little more distanced from the global variables that the previous settings. Be nice to see some sort of calculation for this stuff so that we know it scales.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was basing the bottom margin's off of the base 8/7px scale so that when the line-height of a header doesn't allow the following item to start on the grid, I used bottom margin to push it on. Basically making up for remainder.

But let me work on the maths and see if I can come up with something that uses rem instead.

@cchaos
Copy link
Contributor Author

cchaos commented Apr 4, 2018

As for the title underline on the Card, it bugged me too. But I just changed the font-weight to 200 and I'm still having the same issue...

screen shot 2018-04-04 at 11 06 25 am

@cchaos
Copy link
Contributor Author

cchaos commented Apr 4, 2018

Ahhh it was a font-size thing. Apparently at 20px+ the underline thickens.

@cchaos
Copy link
Contributor Author

cchaos commented Apr 4, 2018

@snide I think the documentation issue with the props table not showing up has to do with the fact that the component returns a cloned element. The ScreenReaderOnly comp does the same thing. I'm not sure I know how to fix that.

Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Minor comments to help readability. Oh. And watch out for the 500.

@@ -41,5 +49,6 @@ $euiLineHeight: 1.5;

$euiFontWeightLight: 300 !default;
$euiFontWeightRegular: 400 !default;
$euiFontWeightMid: 500 !default;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't available in open sans, and currently that's what is used in Kibana.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know what it would fall back to?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It ends up not bold, which was the problem we were having with the form labels.


$euiFontSize: 14px; // 5th position in scale

$euiFontSizeXS: $euiFontSize * nth($euiTextScale, 7); // 12px
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think it matters what you use, but this could probably be done a little cleaner with a map.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're probably right but for the sake of overrides, I'm not too worried...

@@ -16,21 +16,29 @@
font-size: convertToRem($size);
}

// Our base gridline is at 1/2 the font-size, ensure line-heights stay on that gridline.

@mixin lineHeight($multiplier: 3) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a cool way to do it.

Might wanna name this mixin a little more specific though. When I see lineHeight(3) in the other parts of the doc, first thought was wait, why is this setting the line-height to 3!

Maybe, caclulateLighHeightFromBaseline or something? Could probably use an example... if the baseline is set to 8px, the base font size is 16, and you pass a multiplier of 3, then this set the line-height to roughly 24px (converted to rems).

cchaos added 16 commits April 4, 2018 22:35
- Updated the font scale
- Decreased line-height of large font sizes and added padding to make up the difference
- Added class for medium title size and making it the default
- Takes a font-size and determines the correct line-height and font-weight
- Used in all places that are titles (warning but on purpose: some components now have different weights for their titles)
- This now means that we have a set hierarchy for titling and, in most cases, all titles at the same font size should look the same
- All values are in rem
- All margin/line-height values are a multiple of the baseLineHeightMultiplier
- Updated K6 font sizing to use the scale as well
- The mixin also recommends using the same prop names as EuiTitle as arguments (ie “xs”, “m”, “l”)
- Added another mid-way font weight
- Updated docs
@cchaos
Copy link
Contributor Author

cchaos commented Apr 5, 2018

jenkins test this

@cchaos cchaos merged commit dbb717b into elastic:master Apr 5, 2018
@cchaos cchaos deleted the more-titles branch April 5, 2018 03:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants