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.
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.
Not a fan? No problem. You can still opt out of this change and continue using Overpass instead.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Originally, PatternFly’s empty states often had a container with full width and some sort of layout to center the contents like so:
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).
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 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.
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).
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.