Global changes [2020 major release update]

Photo by Frank Vessia on Unsplash

For over a year now, we’ve just been itching to make global changes to PatternFly. What would a breaking change release be without major upgrades to fonts, colors, and viewports?

We’re stoked to elect Red Hat Text as our default font of choice everywhere. We also changed some of our colors to provide better contrast and made smaller viewports first-class citizens in the traditionally desktop-driven PatternFly world.

Let’s take a closer look at these changes.

Font

Make redhat font default, add opt-in for overpass by @mcoker

PatternFly faced long-lasting browser compatibility issues with Overpass, so we made the decision to switch to the official Red Hat font family once it was completed. Red Hat’s brand team and type designer helped ensure this new font met all product and digital marketing needs. Not to mention, we think it looks nice.

Overpass is our old font. We think Red Hat Text looks much better.

Not a fan? No problem. You can still opt out of this change and continue using Overpass instead.

Colors

With PatternFly’s sharp new font, we had to spruce up our color palettes as well. Not only do the new colors look better, but they also provide better contrast for accessibility. Who said functional design can’t look good too?

You can check out the new palettes on PatternFly’s revamped Colors page (thanks to @gdoyle1 for the design!).

Add new cyan, gold, green, and red colors, updated blue by @mcoker

Alerts have a fresh look with PatternFly’s new colors. Now you can create alert messages that are easier to read and a bit nicer to look at.

The previous alert colors were a bit dull. Thanks to @mceledon, PatternFly’s alerts are now modern and vibrant.

Update blue and cyan 600/700 color variables by @christiemolloy

Some of PatternFly’s unused blue and cyan colors didn’t get updated in March 2019 for brand purposes. In August 2019 we missed updating them again when adding a default alert variant. Rather than retire these colors, we decided to update them to align nicely with the rest of the color palette.

The 6th and 7th columns are the updated blue and cyan colors. They’re rather dark, but potentially usable!

Update success-100, success-200, and green-500 by @mcoker

To improve accessibility and consistency across PatternFly’s portfolio, we updated some of the green colors. Now you can build more unified interfaces that everyone — regardless of visual ability — can enjoy.

But that’s not all! This update beautifies things quite a bit. In the words of our designer @mceledonia, “It just changes greens to better greens.”

Some of the components that use the new #3E8635 value are alert, form, form control, label, notification drawer, and progress.

The old success color didn’t provide sufficient contrast compared to the new lighter green.

Update black global and background global/component vars by @mcoker

Accessibility didn’t end with the green color updates. PatternFly’s primary and secondary text colors have been widely used to display text on white (` — pf-global — BackgroundColor — 100`) and light gray (` — pf-global — BackgroundColor — 200`) backgrounds, but the contrast ratios were not quite reaching the required W3C 4.5:1 contrast ratio in some components, such as forms and empty states.

To achieve the ratio, we updated our secondary text color ` — pf-global — Color — 200` and replaced ` — pf-global — BackgroundColor — 150` and ` — pf-global — BackgroundColor — 300` with ` — pf-global — BackgroundColor — 200`. This way, you can build forms and empty states that more of your users can easily interact with.

The new empty state now meets color contrast standards.

Mobile first

Speaking of accessibility, PatternFly needed some work in the mobile-first design area. More and more enterprise applications are using smaller viewports, so it’s important that our patterns can easily support design for mobile screens.

We changed PatternFly’s CSS across the board and addressed a few components specifically to make sure they support the mobile experience. This way, mobile users can enjoy the same PatternFly-quality consistency and accessibility across viewports.

Hide vertical navigation at 1200px and update spacing by @mcoker

Perhaps the most impactful mobile-first change is that we now hide the vertical navigation at 1200px instead of 768px. At 768px the page’s main content area was very narrow and difficult to work with, causing tables, data lists, card layouts, and more to be cramped at that viewport.

The old sidenav breakpoint left data lists rather cramped.

Now that the vertical navigation is hidden at 1200px, page content layouts should flow smoothly above and below the navigation breakpoint at 1200px. Additionally, the chrome spacing is now more compact at 1200px, resulting in additional space for an application’s content at a greater viewport width.

The new breakpoint gives data lists plenty of space.

Change components to be mobile first by @christiemolloy

We updated all components (except table grid modifiers) to have a mobile-first approach to the CSS. `min-width` is now used in all media queries, and we updated CSS variables so that a base variable always refers to the mobile-first design.

This change provides greater consistency in the way CSS is authored and makes the CSS easier to customize. It also creates a common approach for structuring component CSS and writing media queries.

Remove `pf-m-mobile/icon/user` and add `pf-m-hidden/visible` in PageHeaderTools by @mcoker

We removed a limited subset of CSS classes used to hide and show elements in the masthead and enabled a full suite of `.pf-m-hidden` and `.pf-m-visible` variables that can be used at specific breakpoints.

These tools give you full control over what elements are hidden or visible in the masthead at various device widths. They also align better with the tools that the React masthead previously offered to hide and show elements.

Allow wizard to be used in modal by @mcoker

You’ll now have an easier time using the wizard in the modal component, especially when designing for the mobile experience. We removed the “wizard modal” styling that existed previously and made the “in page” variation the default behavior. This changes the wizard into a normal block element that takes up the height and width of the element it’s placed in. Now there’s only a single variation instead of two, and you can simply place the wizard in the modal component.

Make wizard inPage by @nicoletheon

Since our HTML/CSS supported placing the wizard in the modal component, we removed the `inPage` prop in React. But don’t worry — we have you covered if you would still like to use the modal variation of the component without writing additional code. You can just specify the `isOpen` prop, and the wizard will be placed in a modal for you.

Empty state: Center content and adjust secondary margin by @mcoker

Originally, PatternFly’s empty states often had a container with full width and some sort of layout to center the contents like so:

Who wants a small off-center empty state?

But did you really want your empty state off to the left side like that? We didn’t think so.

Now you don’t have to put in the work to widen and center your empty states — the component does it for you. You can even make it fill the height of its container by adding the class `.pf-m-full-height` or passing the `isFullHeight` prop in React (thanks to #4031 by @seanforyou23).

Update bottom pagination design by @mcoker

The bottom pagination is now specifically designed for mobile by sticking to the bottom of the viewport. To align with the React component naming, we renamed the bottom pagination from “footer” to “bottom.”

Breadcrumb: Add word-break, display link, and inline icon by @mcoker

Breadcrumb trails are also a bit more mobile-friendly. We changed the structure and white space behavior in the breadcrumb component so that the items adapt better with different types of content. This is particularly useful in more narrow viewports where space is limited and breadcrumb items begin to stack.

I think we have a text wrapping problem…

Problem solved!

React

Use tsc instead of babel for build by @redallen

Since PatternFly 4 started as a JavaScript library, we have been using Babel’s preset-react along with a few other presets to build components. However, now that the patternfly-react repo is 96.8% Typescript (and we already run the Typescript compiler to Typecheck code!) we replaced Babel’s output with the Typescript compiler’s output.

This speeds up builds and improves the quality of our transpiled code. Another added advantage is that the Typescript compiler supports incremental builds out of the box and does a much better job than our custom incremental build script, which had issues in the past.

Babel also injected helpers at the top of each file to do things like implement the spread operator. The Typescript compiler can take care of these by importing a common tslib package, which helps bundle sizes.

But it didn’t come for free. We lost support for UMD builds (consider using the react-core.umd.js bundle) and for propTypes (consider using an editor with Typescript support).

Upgrade React peer dependency to ^16.8.0 by @redallen

We upgraded our peer dependency from react@¹⁶.4.0 (2 years old) to react@¹⁶.8.0 (1 year old). This change allows our library code to use React hooks moving forward. Contributions can now use hooks, and some of our developers are already excitedly adding code with hooks. In the future, we may expose state management to you through hooks.

Check back soon

That’s all for global changes. Check back for more articles on the update post.

Have a story of your own? Write with us! Our community thrives on diverse voices — let’s hear yours.