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
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.
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.
contentStyleFile rules should [overrides by default][bug 773602]
the rules for the same element contained in the document stylesheets and the
The relative paths in
contentStyleFile should works as expected, so if the
css is contained in the
data/ add-on folder, that should be the base URL for
The page shouldn't be able to detect neither modifying the CSS rules added by
contentStyle should 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
We should continue to use the Stylesheet service, in order to cover the point 3. If AUTHOR_SHEET type will be supported by Stylesheet service we could have the exact behavior of the Style Editor without the problem of introspection.
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