Clone this wiki locally
In Add-on SDK we introduce
contentStyleFile as options
for page-mod. Those feature gives the capability to applying a stylesheet to
all documents that matches the
Protected from introspection
User Stylesheet are protected from introspection by the page. It means, a page can't detect the stylesheet, remove it, or modifying it in any way.
Using a document stylesheet a website could be easily detect which add-on the user has, reverting the changes, modifying the CSS rules on the fly.
Overriding page stylesheet
User Stylesheet can overrides page's stylesheet and inline stylesheet as well,
!important is used. So the author the Add-on can be sure that this style
is applied, no matter what.
Using a document stylesheet, an inline stylesheet or another stylesheet added later, could always override the Add-on rules for the same elements.
User Stylesheets are registered before any document is loaded. They will applied with all the rest of the stylesheets, so the users will see immediately the add-on changes as soon as the document is displayed, avoiding "flickering" effect.
Comparing to the alternative of document stylesheets, the User Stylesheet and the Stylesheet service is definitely the right direction for an Add-on.
However, even if they following the standards, the behavior of User Stylesheets seems counterintuitive for some developers, where they expect for instance, to have the same behavior of the Style Editor, that uses document stylesheet instead.
In addition, in order to applying the document filtering, we have to dynamically
add the [-moz-document] rule to any
because the Stylesheet service requires a URL, we have to convert in a
data: URL. This is not only a bit hacky, but more important it
breaks relative paths.
What the Add-on developers expects?
contentStyleFilerules should overrides by default the rules for the same element contained in the document stylesheets and the stylesheet inline.
The relative paths in
contentStyleFileshould works as expected, so if the css is contained in the
data/add-on folder, that should be the base URL for relative path.
The page shouldn't be able to detect neither modifying the CSS rules added by
contentStyleshould be applied immediately to a document when is loaded, before it was displayed the first time, to avoid the "flickering" effect. The user should see the document already modified by the Add-on.
How to achieve that?
We should continue to use the Stylesheet service, in order to cover the point
3. In that case, we probably need a new type of stylesheet ("Add-on Stylesheet" ?)
with more "weight" than author page; basically that behaves like an User
stylesheet with the "weight" of each css rule set to
To avoid to break the paths in
contentStyleFile, we should be able to pass
the original URI to the Stylesheet service instead convert it in data: URL.
For accomplish that, Stylesheet service should provides a method to register
a stylesheet passing a second parameter that is the
-moz-document filtering rule;
or provides a method to register a stylesheet to a given document.
It's a good approach if we are sure that we don't have problem with memory/performance,
and if there is no timing issue: because we need a
document instance, the idea is
registering the stylesheet at run time for every document as soon as we receive
document-element-inserted notification. However, similar operation on JS
side gives to us the "flickering" effect mentioned before.
If we can avoid any timing issue, then
offer a way to apply user agent stylesheet on a given document
it's probably the best approach, because we can offer a consistent solution for
- Allow adding CSS stylesheets to page with page-mod API
- Offer a way to apply user agent stylesheet on a given document
- css rules tested in style editor don't apply the same way via page-mod
- contentStyleFile breaks relative paths in stylesheets
- Add a new type of Stylesheet to use with nsIStyleSheetService that always overrides the Author Stylesheet by default