What's new in 7.0

Normalized browser styles

Each browser has default styles that it applies to various HTML elements. Not all browsers have the same default styles (called user-agent styles), which means that websites without custom CSS will look different when viewed from different browsers. Even when creating custom CSS, web developers must take those different default styles into account and make sure they are overridden appropriately. This can be tedious and error-prone, so a common practice among developers is to remove or normalize those user-agent styles with a collection of base CSS rules before applying any component CSS that controls the look-and-feel of the site.

Until this point, the design system has avoided any global, sweeping CSS rules that might interfere with application CSS. However, because CSS normalization makes it easier to write CSS, teams have often applied their own normalization, which is not consistent across teams. Over the years, this has lead the design system team to apply more and more "defensive" CSS to account for variability in normalization rules. Teams would also rather be able to import the design system styles and get started creating an app rather than having to decide what sort of normalization they need first. Therefore the design system team has decided to include our own global CSS rules for normalization as part of the design system. For more information, see our original RFC and the new documentation page on CSS normalization.

Standardized component spacing

Before v7, some components had both top and bottom margins. This made the default spacing between them hard to predict, because those margins would either stack or collapse depending on the combination of components and how the HTML around them was structured. Now our components only have top margin, so there is no fighting between one component’s bottom margin and another component’s top margin. For more details about what components changed and how to address these changes in your application, please refer to our migration guide on spacing changes in v7.

Standardized colors

With the expansion of the design system themes to include a fourth theme (CMS.gov), we noticed theme variables were inconsistent. In some cases colors and whole color palettes weren't being used and needed to be removed. We've cleaned up and reorganized these colors using design tokens and theming to provide a more intentional approach to color. For more details, please see our full migration guide for color standardization in v7.

New dropdown component

Several major versions ago we started abstracting the idea of a dropdown menu behind the Dropdown component, which has always been implemented with a native HTML select element. This has been the U.S. Web Design System’s strategy as well. While the HTML select element tends to perform better with assistive tech than custom drop-down-menu solutions, it actually provides a poor user experience when applied to some of our applications’ use cases. Most notably, options with long text cause trouble in some browser and operating-system combinations where they are either truncated or clipped at the edge of screens.

In this update, we’ve resolved this issue by implementing the component as an ARIA combobox. A side benefit is the menu is now styled to match CMS brands. The component has been redesigned from the ground up, and our Autocomplete component has also been updated to match the new designs. Check out the Dropdown page to see it in action.

New JavaScript libraries

Up until this point, the only dynamic JavaScript components we have offered have used the React library, which makes them harder to use outside of React contexts, like Drupal websites and Angular applications. Those product teams resorted to a build-your-own approach using our CSS and their HTML. While this works, it isn’t ideal for many reasons. In this release, we’ve worked towards making our components more framework-agnostic by providing two more JavaScript libraries under the same NPM and CDN package:

• Full set of Preact components, a lighter-weight alternative to React that can improve bundle sizes in some projects
• Experimental subset of web components, which are framework-agnostic components that use standard web APIs built into modern browsers

Please check out our new example projects on GitHub and read our updated developer documentation for more details.

New version switcher for our docs

We’ve added a version switcher to our doc site so you can browse old documentation as far back as version 3.4.0 of our design-system core npm package. Version numbers listed in the dropdown will always correspond to the theme that is selected, since each theme corresponds to a child design system with its own versioning. We have plans to improve this version switcher in the next version to make the experience better and more accessible.

What's on deck

Improving the doc site's theme/version switcher

We have plans to improve the accessibility and overall user experience of switching versions and themes on our doc site, and it will involve alpha-testing a new design-system component. This component has existed in various forms in a handful of applications across medicare.gov and healthcare.gov, and testing it on our doc site will give us a way of informally trying out ideas before it goes through a more rigorous process of adoption.

Adding the USA banner to HealthCare.gov

We'll be adding the USA Banner to HealthCare.gov's header in the next version. Adding the banner helps users identify our domains as official government websites, and that's important in building confidence in the experience.

Pondering icons

We're doing a deep dive into icons used across CMS, and we want to hear from you. If you're part of a product team at CMS and would like to share about how you use icons, please click that link to go to our CMS Slack channel. You can also visit our contact page for more ways to get in touch with us. Thank you!