Add emotion to UI

[sndrs]

What does this change?

• adds emotion to UI
• removes all the SVG data-block stuff

any CSS which cannot be handled by styletron can now be managed like this:

<Logo
    css={`
        width: 250px;
        & .guardian {
            @supports (fill: hotpink) {
                fill: ${colour.brandBlue};
            }
        }
    `}
/>

in a subsequent PR, i'll update linting of *.js.scss files to disallow css that styletron won't be able to handle, and update the wiki.

What is the value of this and can you measure success?

styletron does not handle more complex CSS, for example combinator selectors. this adds emotion, along the lines of #17761, which does, but at the cost of heavier CSS.

it's much smaller than styled-jsx (2kb gzipped), and writing the code feels more natural. it's the result of unsuccessful but extensive effort to create an api more aligned with current way, but stops short of it to see how this is used.

[PRBuilds]

PRbuilds results:

Screenshots
desktop.png • tablet.png • mobile.png • wide.png

Exceptions (0)
thrown-exceptions.js

A11y validation (3)
a11y-report.txt

Apache Benchmark Load Testing
loadtesting.txt

--automated message

[gtrufitt]

What's the general feeling of the team with styetron syntax vs something like this? I'd prefer writing like this tbh, but only because it still feels more familiar

[SiAdcock]

@gtrufitt

I like this syntax as, again, it feels familiar and it keeps your styles close to your component markup.

There's a couple of possible downsides that I can think of:

1. Too much visual clutter (imagine a component comprised of four or five elements, each with their own styles defined inline)
2. No syntax highlighting or autocompletion (There's a styled-components plugin for IntelliJ, but I haven't found a plugin for emotion yet)

But as with any developer experience discussion, opinions are rife and the only way to "prove" whether hypothetical problems are actual problems is to test it out on developers.

[GHaberis]

I'd be happy to use this emotion syntax and agree that the syntax looks familiar enough to a JS developer.

I wonder how intuitive it'd be for someone whose used to writing SCSS/CSS but doesn't have a JS background? Like @SiAdcock said it's a hypothetical problem we're anticipating. Perhaps clear documentation/examples as guidance could get people up to speed with this approach quick enough? It's not a radical departure.

I do like the Styletron approach of importing named style rules from a scss file, primarily because of neatness and lack of visual clutter within the JSX.

Having named style rules also means reusing rules across elements is straight forward enough. Yes you could get around the reuse of rules in emotion by assigning the template-string to a named variable and assigning that to the css attribute, but a potential downside here is you'll end up with some rules defined inline and others not.

[sndrs]

yeah i like the look of this. be v interesting to see what people go for. if we dropped styletron for just this (to settle on one api), even though we'd lose the tiny css, we'd still be at around 10% of current state, which is pretty good.

[sndrs]

@SiAdcock one big thing in styled-components favour is the ecosystem, for sure

[SiAdcock]

We could shorten this to :

use: ['styletron-loader', sassLoader],

[SiAdcock]

What is the expensive-css attribute for? Is it simply flagging up this style element for developers / archaeologists?

[sndrs]

yeah exactly that

[SiAdcock]

👍

[NataliaLKB]

lgtm 💯

[prout-bot]

Seen on PROD (merged by @sndrs 16 minutes and 25 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉