For a few months now I’ve received sporadic reports that my website was broken. They said the layout was askew and things were sized strangely. They had screenshots to prove it. This was embarrassing for a professional website builder.
Thankfully my audience is tech-savvy and the Grammarly browser extension was identified as a prime suspect. When this extension was installed it broke my website, simple as that. My initial response was: “Sorry, their bug, not mine”. But after one report too many, I was forced to sign-up and install Grammarly myself (praise the burner email).
Discovery
After accepting the Grammarly Firefox (Mullvad browser) extension kitchen sink permissions:
- Access your data for all websites
- Display notifications to you
- Access browser tabs
I soon found the evidence. Grammarly injects a stylesheet into web pages (here’s a GitHub Gist). This stylesheet is loaded from the local extension assets. It cannot be found by the web page itself using StyleSheetList. It even bypasses Content Security Policy. It is effectively a stealth stylesheet undetectable by the website itself. In Firefox at least, I didn’t care to install Grammarly in other browsers.
The Grammarly extension also appends a custom <grammarly-desktop-integration> element to the <html> document. This is done on every website regardless of whether you interact with the extension or not (I’ve no idea what it’s used for).
Why me?
At the end of Grammarly’s stylesheet you’ll find the following CSS:
:host,
:root {
--rem:16
}Aside from the obvious crime of omitting a semicolon, this is seemingly innocuous. You probably know the magic number 16. By default 1rem = 16px in CSS units (kinda, it’s complicated). Further up Grammarly are doing a form of dynamic font sizing:
.kE2Bj {
font-size:calc(0.86px*(var(--rem) - 2));
line-height:calc(1.2868px*(var(--rem) - 2));
}This code is auto-generated so it’s not entirely clear what’s going on. I thought they might be dynamically setting the --rem value using the browser’s base font size — good for accessibility — but from testing that isn’t the case. Maybe the extension has its own setting?
As an aside note, Grammarly are also loading twenty variations of the Inter font — Four Naan, Jeremy? That’s Insane! — Inter is available as a variable font. You don’t need twenty individual @font-face rules, Jeremy Grammarly.
Anyway, as it happens I was also using the --rem custom property name. I’m doing my own experimental flavour of fluid typography:
@layer base {
:root {
--rem: 0.0625rem;
--fluid: calc((100vi - (400 * var(--rem))) / (1920 - 400));
--font-size-h1: clamp(
calc(31 * var(--rem)),
calc((31 * var(--rem)) + (80 - 31) * var(--fluid)),
calc(80 * var(--rem))
);
}
}How this works is a topic for another blog post.
What’s important is that I was using --rem and it’s defined inside a cascade layer. Styles outside of a layer take precedent over those within a layer, regardless of CSS specificity (a topic for an entire book). Source order also matters, so Grammarly’s --rem probably would have won anyway.
TL;DR: Grammarly broke my calculations and thus they broke my website.
The Fix 🤡
Initially I used a mutation observer to detect the appended web component and add extra !important styles to reclaim my territory. Once I understood the exact problem I changed my custom property to --🤡 which is perfectly valid.
Basically the name --rem is now “considered harmful” because Grammarly are bad web citizens. They are generating random class names, why specifically hijack --rem? Why apply it globally to :root? They could also, you know, not inject their code into every web page ever, unless the extension is actually used?
I’ve reached out to Grammarly support. They’ve been quick to respond, but I’ve yet to reach a technical person who understands my issue. I’m hoping we can swap names. Grammarly can have --🤡 for their sins, the rest of use can use --rem. Any of you nerds work for Grammarly? Let’s make this happen.