CSS reset

[SiAdcock]

The design system team have received a couple of requests for specifying a CSS reset for Guardian projects. I've listed some of the reasons that make this a compelling idea over at guardian/source#402.

Specifying a Guardian CSS reset would provide a consistent developer experience across projects, making dipping into another project easier. Devs would come to learn which properties have been neutralised or normalised at a global level, which would help when debugging or planning features.

It would make Source leaner, as we could make assumptions about which User Agent styles have been overridden.

It would make new apps easier to kick off, as the debate about which CSS reset to use, or whether to use one at all, is happening at a higher level. Note that if after some debate there is a consensus that we should never use a CSS reset, this is still a recommendation that is worth making.

Currently, frontend uses normalize.css, and dotcom-rendering and support-frontend use Eric Meyer's reset. I'm not sure if resets are used anywhere else.

Questions

• Do we want to specify a CSS reset at the CS infra level and recommend that new projects adopt it?
• Other than those listed above, are there any other benefits of doing so?
• What are the tradeoffs?
• Other than normalize and Eric Meyer, which other resets are out there?
• Would we consider defining our own reset?

[gtrufitt]

I think I would still +1 on https://hankchizljaw.com/wrote/a-modern-css-reset/ for a modern reset.

So the plan would be:

• Client-side infra recommends a reset
• Source resets components that it cares about

and the two should work together.

It would make Source leaner, as we could make assumptions about which User Agent styles have been overridden.

I think unless source defines and specifies the reset, you can't make those assumptions? Either the reset is defined, lives and is required by source or you have a 'works best with' and you can no longer make full-blown assumptions on the overrides?

I actually disagree with your last comment on guardian/source#402 and still think it makes sense for source to define the reset css for projects that use source. Certainly in DCR, if you're going to recommend a reset, it feels ergonomic for that recommendation to live within source.

[JamieB-gu]

Historically I've not been too bothered about resets, but I think the benefits it provides to a universal design system that you've described above are a good argument for having one.

Instead of making use of a third-party one, could we start one in Source? Perhaps creating a PR for each rule we want to add, and tagging the platform stakeholders in these PRs to a) get their opinion and flag any problems it might cause for their platform, and b) make them aware of the changes so they can upgrade easily?

[SiAdcock]

Great points, thanks both. I'm coming back around to the idea of this living in Source.

The difficulty I had, as @JamieB-gu identifies, is onboarding. Source has so far been additive: it gives your codebase features that were previously missing. By introducing a reset, we're now saying that Source takes over the rendering layer of your codebase, adding globals that can affect even non-Source components. Perhaps this is desirable, even inevitable in the long run. I want to be sure that this is clear to everyone before making a decision about defining a CSS reset. It would certainly take a major version bump in Source.

There's something to be said for having a consistent environment for all components, not just Source. As @tomrf1 pointed out to me recently:

reset has caused trouble with our epic/banner in the past, where we build it in storybook then find it looks different in DCR!

It's also useful to have place where sensible defaults can be defined and debated with the most visibility and the broadest set of voices. Quoting @i-hardy:

ideally a reset is not something you really want to have to think about, and if we can bake in a lot of beneficial defaults then why not?

Assuming we go ahead with this, what could a CSS reset look like? I'm less in favour of Eric Meyer's approach than once I was. It is way aggressive, targets some ancient browsers that we no longer support and includes at least one known (maybe two) accessibility issues.

The Andy Bell reset that @gtrufitt mentions is less aggressive and includes some generally good modern ideas such as enabling smooth scroll and optimising text rendering.

As for resets that we currently use: as previously mentioned, DCR and support-frontend use Eric Meyer. DCR also supplements this with some modern ideas. support-dotcom-components also implements a minimal reset on some of its components. Taking these, and combining with the minimal proposal in guardian/source#402 gives you:

/* 
Explicitly set box-sizing on everything. 
I think border-box is the easiest to get 
your head around. Using inherit can get 
confusing.
*/
*, *:before, *:after {
	box-sizing: border-box;
}

html {
    scroll-behavior: smooth;
    -moz-osx-font-smoothing: grayscale;
    -webkit-font-smoothing: antialiased;
}

html, body {
    /* 
    optimizeLegibility has performance problems in some circumstances
    so optimizeSpeed feels like a safer default?
    https://marco.org/2012/11/15/text-rendering-optimize-legibility
    */
    text-rendering: optimizeSpeed;
    font-feature-settings: 'kern';
    font-kerning: normal; /* Safari 7+, Firefox 24+, Chrome 33(?)+, Opera 21 */
    font-variant-ligatures: common-ligatures;
}

body {
    background-color: #ffffff;
    color: #121212;
    min-height: 100vh;
/* 
    Note, I have dropped line-height: 1.5 from the
    Andy Bell reset as too opinionated
*/
}

/* Remove default margin */
body,
h1,
h2,
h3,
h4,
p,
figure,
blockquote,
dl,
dd {
  margin: 0;
}

/* remove default spacing and decoration from fieldset and legend */
fieldset, legend {
	padding: 0;
}

fieldset {
	border: 0;
}

em {
    font-style: italic;
}

strong {
    font-weight: bold;
}

/* 
Remove list styles on ul, ol elements with a list role, 
which suggests default styling will be removed 
*/
ul[role="list"],
ol[role="list"] {
  list-style: none;
}

/* A elements that don't have a class get default styles */
a:not([class]) {
  text-decoration-skip-ink: auto;
}

/* Make images easier to work with */
img,
picture {
  max-width: 100%;
  display: block;
}

/* Inherit fonts for inputs and buttons */
input,
button,
textarea,
select {
  font: inherit;
}

/* Remove all animations and transitions for people that prefer not to see them */
@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

/* remove styling of invalid input elements that gets applied in Firefox */
input:invalid {
	box-shadow: none;
}

Does this look like a sensible starting point? We can always debate the finer details in a PR against Source.

Or is doing this too much too quickly?

Also, if you have any favourite CSS rules you'd like to consider adding, please add them to this thread.

[i-hardy]

Given that the rules fall into some pretty well-defined groupings, for migration purposes would it make sense to offer both the whole reset and a way to adopt it incrementally, so it's easier to manage the impact? So you'd export a resets object with specific sets of rules that you can pull in one at a time, like:

export const resets = {
	listStyles: `
		ul[role="list"],
		ol[role="list"] {
		  list-style: none;
		}
	`,
};

[mxdvl]

Getting Source to help with consistency sure seems like a step in the right direction.

Building on @i-hardy suggestion, I think that each rule should probably live in its own file. If we're saying that each grouping is orthogonal to the others, it should be easy to discuss its merit, update it and consume independently.

For example, I have some qualms about `100vh` and `optimizeSpeed`, but I would not want this to stop the adoption of the other rules.

min-height: 100vh;

Viewport units are not perfectly supported, and are effectively broken on mobile.

text-rendering: optimizeSpeed;

Should we check wether a recommendation from 2012 is still relevant?

[SiAdcock]

Thanks for the suggestions @i-hardy and @mxdvl, it's a good point. Making the reset easy to onboard is my main concern right now. An opt-in approach like this would make it easier adopt the reset.

Let's riff on this for a bit...

It's important to note that when the reset goes live, there will be some rules that must be adopted by a project that's using Source components. Say your project is using Source checkboxes, you must adopt the styles that reset <legend> and <fieldset> elements, otherwise checkboxes will look broken.

Because this could get really messy, I propose that any project uses Source components must adopt a core set of rules that we define. These rules reset elements that are used in Source components.

Rules that are not required by Source components could be adopted on an opt-in basis. Another approach would be for us to add new rules to the reset very gradually, always as a breaking change, to help teams migrate slowly to our reset. Happy to take any feedback on this.

I think it's important to note that this approach would only be appropriate to ease onboarding. I don't want to live in a world where teams are encouraged to pick and choose which parts of the reset they want to adopt. The point of the reset is to provide consistency across environments. If every project has a different set of base styles, we're breaking that contract.

Thoughts on this welcome 🙂

[sndrs]

what would the overhead be of applying scoped, source-specific resets per source component?

something like:

// source/resets.js
export default {
	fieldset: css`
		$, $:before, $:after {
			box-sizing: border-box;
		}
		padding: 0;
		border: 0;
	`
}

// source/component.js
import { resets } from './resets'

export const fieldset = css`
	${resets.fieldset}
	display: flex;
	justify-content: flex-start;
	flex-direction: column;
	border: 0;
	padding: 0;
	margin: 0;
`

would that become really unwieldy and/or bloated?

[SiAdcock]

Thanks for this suggestion @sndrs, it's a great point. By doing this, we reduce the amount of UA-reset repetition across components. It also provides a natural starting point for a global reset in the future. Perhaps this is a good first step, with no cost to consumers and a small win for reducing repetition (and, crucially, reducing JS) in Source.

I don't think we need to worry about bloat right now. Source components themselves barely require any UA resets and I can't imagine that changing much in the near future.

[JamieB-gu]

/* Remove all animations and transitions for people that prefer not to see them */

I think this is a great benefit!

[SiAdcock]

Update on this

I have started a very simple reset in guardian/source#676. It exposes a set of very sensible defaults (in fact the exact same defaults that dotcom-rendering uses) and we can look to build on them in the future. You can use them in your projects from Source v3.0.0, although they are not yet required.

As per @sndrs suggestion I've also started consolidating some element-specific UA overrides for use within Source.

Let me know if you have any thoughts. If you would prefer we go big and bold with resets and include something more like my suggestion above, please let me know.