Unprefixing appearance to ship web-compatible styling of form elements

Google, Mozilla

Rationalizing the spec for the CSS appearance property to help ship an unprefixed version.

We reviewed and updated the spec for the CSS appearance property, helped browsers ship appearance unprefixed without breaking compatibility, and made it easier to style HTML widget elements across browsers.

Challenge

Form controls are a notoriously inconsistent component of the web platform, and developers have long struggled with customizing their appearance. Historically, the -webkit-appearance / -moz-appearance CSS property was used to control an element’s special styling, allowing developers to give an element the native appearance of another element, such as a button or a checkbox. By 2018, implementations of the non-standard property varied widely, with different browsers supporting different native elements and different styles for a given element. Efforts to unprefix and standardize the CSS property met further difficulty after Mozilla implemented appearance, encountered web compatibility issues, and was forced to revert the change. Developers, meanwhile, used CSS hacks and workarounds to ensure consistent customization despite a lack of interoperability and numerous cross-browser bugs.

Mozilla and Google asked us to untangle the complexity hiding behind the appearance property by proposing spec updates to ameliorate compatibility and consistency issues and writing web-platform-tests tests to ensure conformance across browsers. The ultimate goal was to reduce common pain points among developers when styling widgets and reduce the number of CSS properties which require prefixing.

Solution

To fix the developer pain points around appearance, we needed to get all browsers on board with the same specified behavior and to ship an unprefixed version of the CSS property. Achieving consensus required updating spec text to reflect the status quo of support for various native element values across browsers. This included studying the hundreds of implicit styling changes triggered by different values and identifying areas of ambiguity when element styles were combined in interesting ways.

We also surveyed developers to help us understand the use cases and pain points for the CSS property. Since our changes needed to preserve web compatibility, we researched -webkit-appearance / -moz-appearance in the wild with HTTPArchive to find websites that used values that did not match browsers’ user-agent styling.

Equipped with this research, we narrowed down the list of supported values to just those necessary for web compatibility and updated the spec accordingly. We also wrote new WPT tests to uncover and fix conformance errors related to the new spec changes. Finally, we reached out to browser vendors and asked them to unprefix the property and supported our request by citing our findings about inherent risks and the actions needed to mitigate them.

Impact

This work paved the way for the introduction of the appearance CSS property as a replacement for -webkit-appearance. Chrome and Firefox have since shipped appearance unprefixed. WebKit (the rendering engine that Safari uses) has now also included appearance unprefixed. It is available in Safari Technology Preview 134.

As part of implementing the new specification, the appearance property now also supports the auto keyword, which means you only need to remember two values: auto and none.

Now that appearance has shipped, developers have a single, consistent property to apply custom styling to all HTML elements, including those with special default styles out-of-the-box. In the process of unifying appearance, we helped improve the developer experience of customizing native element styling, fixed long-standing platform bugs, and established a playbook for future improvements in the realm of form control styling. We removed the need to prefix a significant and commonly used CSS property and provided a useful precedent for standardizing and unprefixing additional properties down the road.