'Using the 'revert' CSS keyword in user scripts
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?
Solution 1:[1]
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:
- 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
- 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 likefont-family: "Comic Sans MS" !important;
. - 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:
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 willinherit
values, and some not. Depends on the attribute.font-family
in our example obviously inherits frombody
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 likeinherit
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
- If the attribute by its nature inherits, the
I will try to address some other questions that I can foresee before they arise:
- You do not have to put
!important
on everything to account for someone that did* { all: revert }
. - 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
- For public facing websites, it's unlikely someone will need to use this.
- 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.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Zach Jensz |