-
-
Save erikvold/1033799 to your computer and use it in GitHub Desktop.
| var self = require("self"); | |
| var us = require("userstyles"); | |
| exports.main = function() { | |
| var url = self.data.url("black-google.css"); | |
| us.load(url); | |
| }; |
The userstyles module I created is at erikvold/userstyles-jplib the load function is using nsIStyleSheetService which loads the css once before the content within userContent.css and userChrome.css load.
This means that the css needs to use @-moz-document to defined which content/chrome pages the css they write should be applied to. This is how userstyles work.
(I don't know enough of about where this fits in the greater scheme of things). What does this do when?
This is a example jetpack, which uses the userstyles module to simply load a userstyle. So with this module one can make a firefox addon out of a userstyle, or package userstyles together in a addon; but there actually isn't a simple way to simply include css into xul pages for jetpacks like there is for old school xul extensions, so this module also provides a simple means for styling xul windows which was not present in jetpack before afaict.
If you include this snippet in a Firefox 4+ extension built with the jetpack SDK.
I've got a example add-on on the add-on builder here. There is a download button, it is a little slow though.
the css in that addon kind've sucks though, I'll try to fix it up so that it actually turns github black. it works now.
Thanks! I think the answer to the thing that eluded me the most is the design of nsIStyleSheetService (and do correct me if I'm wrong):
There is no reference to any specific event being listened to or timing of when the call is made (main.js is just executed, once only, some time during browser startup, or just after the add-on is first installed, depending on what the first-start context is), because all the css you add will be taken care of by that service in the css cascade performed on every web (and xul) page ever after until the browser shuts down again, as soon as they load.
So you need all your css to spell out all its contextual dependencies (such as @-moz-document url(http://www.w3.org/), url-prefix(http://www.w3.org/Style/), domain(mozilla.org), regexp("https:.") { / css for those urls here */ }), which means that if you want to do anything wonky like css that is different in different phases of the moon you can't just pick a different css file / string at different times, but have use tricks like adding all css styles you want for everything, and making some of them depend on page mods you do on document structure (like, say, adding a data-moon-phase="waxing gibbous" attribute to the <html> element, a k a document.documentElement) and reference it in your css in rules like html[data-moon-phase="waxing gibbous"] body { background: url("http://example.com/howling-donkey.png"); }.
(And pardon IANA for serving a 404 instead of that chilling image, by the way; I'm sure they withhold it from us for the very best of reasons.)
I believe you have a genuine sell of something great, but it's unclear what that great is (I don't know enough of about where this fits in the greater scheme of things). What does this do when? My educated guess, if it helps pinpoint the parts People don't immediately grok:
"us.load(url)" creates a <style> tag in the current content document and sets its css context to the contents of a file black-google.css fetched from somewhere, and does this at (before?) DOMContentLoad time. If you include this snippet in a Firefox 4+ extension built with the jetpack SDK.