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

Heading component and fluid size improvements #679

Merged
merged 12 commits into from
May 5, 2020

Conversation

tylersticka
Copy link
Member

Overview

This PR started as a resolution to #548 but I immediately noticed some heading issues. Solving those sparked some ideas on how to effectively port our Hash Heading pattern, and before I knew it I had a whole new component.

  • Fixes an issue in the headings.level mixin where em units were used instead of rem, causing fluid sizes to become out of step when font-size differed from 1em.
  • Simplifies headings.level based on actual heading usage.
  • Adds support for non-standard levels (beyond 1–6) in headings.level mixin.
  • Adds c-heading component.
  • Adds c-heading--level-* modifiers for changing the visual level.
  • Adds permalink variation of c-heading and necessary Twig logic for that. Permalink supports dark theme and has unique focus styles.
  • Adds ms.step-class-segment mixin for keeping translation of negative steps to n* steps DRY.
  • Adds unit.swap function and normalizes a few other functions in that file.
  • Adds fluid.fluid-calc function to separate property-specific responsive logic from the nuts and bolts math.

Screenshots

Screenshot_2020-05-01 Storybook

Screen Shot 2020-05-01 at 2 58 48 PM

@tylersticka tylersticka requested review from a team May 1, 2020 22:00
@tylersticka tylersticka added ✨ enhancement New feature or request 🎨 design Requires visual, UX or UI design decisions 🦮 a11y Accessibility improvements labels May 1, 2020
Copy link
Contributor

@Paul-Hebert Paul-Hebert left a comment

Choose a reason for hiding this comment

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

This is looking great @tylersticka !

I left some nits and questions inline. Once you've had a chance to review those and address any requiring feedback I'd be happy to approve. Thanks!

$permalink-radius: sizes.$radius-full;
$permalink-size: sizes.$control-height;

$min-width-permalink-shift: layout.$max-width-prose + $permalink-size * 4;
Copy link
Contributor

Choose a reason for hiding this comment

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

These var names don't quite explain to me what they are and how they're used. An additional comment might be nice.

Copy link
Contributor

Choose a reason for hiding this comment

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

(After reading through the rest of the code, or viewing a demo it's clear, but up top where these are placed it's not)

Copy link
Member Author

Choose a reason for hiding this comment

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

  • Added more context to this

* to the inner heading to avoid unintended font sizes.
*/

.c-heading__element {
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if there's something more specific than __element we could use here? __text? __content?

Copy link
Member Author

Choose a reason for hiding this comment

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

I started with __text but changed it because, to me anyway, text suggests that HTML is not allowed. I changed it to __element because this is meant to be specifically the heading element, and c-heading__heading-element felt silly.

I'm open to __content, though. I also toyed with __inner.

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 be fine with content or inner. I think those communicate more intent than element

Copy link
Member Author

Choose a reason for hiding this comment

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

  • Renamed to c-heading__content

@@ -1,29 +1,47 @@
@use "unit";

/**
* Dynamically adjust font size between a minimum and maximum, starting at a
* minimum breakpoint width and capping at a maximum.
* Mixins and functions that allow for dynamically adjust a CSS property from a
Copy link
Contributor

Choose a reason for hiding this comment

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

I think there's a typo in this sentence. for doesn't seem like it fits

Copy link
Member Author

Choose a reason for hiding this comment

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

  • Rewrote sentence

$delta-width: unit.strip($max-width - $min-width);
// We use `rem` so the fluidity won't be influenced by parent elements
Copy link
Contributor

Choose a reason for hiding this comment

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

Just wanted to clarify: The min and max breakpoints should always use rems but the fluid value being calculated could use other units. Is that correct?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not exactly.

Media queries will always calculate em based on the root element's font-size, which sounds a lot like the behavior of rem. But Safari has issues with rem media queries, which is why it's better to prefer em.

But if we use that same value in the font-size calculation, the em will calculate based on the current (not root) font-size. So we have to convert values applied to the element itself to rem, which will more closely match the behavior of the media query.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, gotcha thanks. It might be helpful to add more of that context in a comment as that wasn't all clear to me.

Copy link
Member Author

Choose a reason for hiding this comment

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

  • Removed terse comment
  • Added more detail to main comment

@mixin font-size($min-width, $max-width, $min-font-size, $max-font-size) {
$delta-font-size: unit.strip($max-font-size - $min-font-size);
/**
* Although the the `calc` statement is only part of the equation, breaking it
Copy link
Contributor

Choose a reason for hiding this comment

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

You have two thes in this sentence.

Copy link
Member Author

Choose a reason for hiding this comment

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

What, you don't like The The?

Copy link
Member Author

Choose a reason for hiding this comment

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

  • Removed the extra "the"

<a class="c-heading__permalink" href="#{{permalink_id}}">
{% include '../../assets/icons/link.svg.twig' with {
class: 'c-icon',
role: 'presentation'
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we should use aria-hidden over role="presentation"?

https://timwright.org/blog/2016/11/19/difference-rolepresentation-aria-hiddentrue/

Copy link
Member Author

Choose a reason for hiding this comment

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

  • Replaced role="presentation" with aria-hidden="true"

@derekshirk
Copy link
Contributor

I'm not sure how I feel about the focus style of the permalink overlapping a (small portion) of the heading text. 🤔

Screen Shot 2020-05-04 at 10 00 24 AM

Is this common?

Did you consider animating the heading text with transform: translateX() a little bit to the right when the permalink is focused, eliminating the overlap?

Screen Shot 2020-05-04 at 10 02 06 AM

@tylersticka
Copy link
Member Author

I'm not sure how I feel about the focus style of the permalink overlapping a (small portion) of the heading text. 🤔

I thought it was kind of cute, but maybe that's just me?

@derekshirk derekshirk self-requested a review May 4, 2020 17:59
derekshirk
derekshirk previously approved these changes May 4, 2020
Copy link
Contributor

@derekshirk derekshirk left a comment

Choose a reason for hiding this comment

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

I'm not sure how I feel about the focus style of the permalink overlapping a (small portion) of the heading text. 🤔

I thought it was kind of cute, but maybe that's just me?

I'm not opposed to it and would be happy to approve it as-is from a design perspective. I'm excited to use this new heading component.

@tylersticka
Copy link
Member Author

@Paul-Hebert @derekshirk Ready for re-review!

Copy link
Contributor

@Paul-Hebert Paul-Hebert left a comment

Choose a reason for hiding this comment

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

Thanks for making those changes. Looks good @tylersticka ! 🚢

@tylersticka tylersticka merged commit db2cfd2 into v-next May 5, 2020
@tylersticka tylersticka deleted the feature/heading-improvements branch May 5, 2020 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🦮 a11y Accessibility improvements 🎨 design Requires visual, UX or UI design decisions ✨ enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants