Using the 'revert' CSS keyword in user scripts

user_5587480 0
Viewed 141

I try to find a difference in how the revert keyword works depending on whether it is used in a user script or on a site itself.

An article on MDN describes this difference as follows:

This keyword removes from the cascade all of the styles that have been overridden until the style being rolled back to is reached.

  • If used by a site's own styles (the author origin), revert rolls back the property's cascaded value to the user's custom style, if one exists; otherwise, it rolls the style back to the user agent's default style.
  • If used in a user's custom stylesheet, or if the style was applied by the user (the user origin), revert rolls back the cascaded value to the user agent's default style.

However, I don't see any difference myself. Could someone show an example?

userscripts css
1 Answers

Prereq #1: We need to understand the 3 main cascading origins defined by the spec, then it's easy to understand what the value does:

  1. Author origin - this means websites, CDNs, external sources, even http://127.0.0.1. For all intents and purposes it's a site's CSS file pulled off the internet. The ubiquitous stylesheet of any website
  2. User origin - this means C:\Users\yourself\AppData\Local\Google\Chrome\User Data\Default\User StyleSheets\Custom.css - browsers on most desktop platforms allow you to specify a "user" stylesheet to be applied by default. Not sure how many people use this feature, but it's there, and allows you to do crazy stuff like font-family: "Comic Sans MS" !important;.
  3. User-agent origin - browsers are required to provide default styling, in order for textareas to use fixed-width font, or <u>text</u> to have an underline. Here is an example of how the default UA style has been applied to body and was overridden by an Author origin style:
    Developer tools showing UA styles applied to body being overridden by author styles

Prereq #2: We need to understand that this spec is WD status (working draft) - meaning it didn't hit the market yet for adoption by browsers, so maybe the tiny details have not yet been worked out. If something seems a little unusual, it's because it's still waiting feedback. This is how the world works over there, completely normal.

Now that we have those bits understood formally, let's see what happens when we use font-family: revert. Well, it depends where it's been set:

  • If in Author context -> will roll back to use the value from User origin
  • If in User origin -> will roll back to use the value from User-agent origin
  • If in User-agent origin -> will behave like font-family: unset. Now, some CSS attributes will inherit values, and some not. Depends on the attribute. font-family in our example obviously inherits from body and parents, padding does not. There is a full list of those in this property table
    • If the attribute by its nature inherits, the revert value will behave like inherit meaning it will go to the specified or computed value cascading in.
    • If the attribute does not inherit, it will apply the initial value (see the column in the same property table

I will try to address some other questions that I can foresee before they arise:

  1. You do not have to put !important on everything to account for someone that did * { all: revert }.
  2. Browsers have a lot of leeway on appearance, quite a lot of it, and this is why we've been doing css resets for the past decades
  3. For public facing websites, it's unlikely someone will need to use this.
  4. For something like an uncommon intranet app, let's say a company wants dropdowns and other form controls to bear the company branding, colors, fonts, etc. and those are set at an OS level in such a way that they trickle down through the browser's appearance - even here we'd be far more likely to use initial instead through the app's stylesheet because we want the control to remain in the project's repo.
user_6088860
Related