-
Notifications
You must be signed in to change notification settings - Fork 263
contentStyle issues
In Add-on SDK we introduce contentStyle and contentStyleFile as options
for page-mod. Those feature gives the capability to applying a stylesheet to
all documents that matches the include pattern.
As described in the original bug, contentStyle and contentStyleFile
are implemented as User Stylesheet using the Stylesheet service rather than
document stylesheets for several reasons.
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,
when !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 contentStyle and contentStyleFile, and
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.
-
The
contentStyleandcontentStyleFilerules should [overrides by default][bug 773602] 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 thedata/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
contentStyleandcontentStyleFile -
The
contentStyleFileandcontentStyleshould 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.
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
the 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
both contentStyle* and contentScript*.
- 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
- Provide AUTHOR_SHEET type for registering with nsIStyleSheetService