Stylish compatibility

[Madis Otenurm]

Despite Firefox 57 nearing and Stylish won't be able to modify UI CSS directly, there is an extension called reStyle that works with Stylish UI styles and therefore could also install the styles from this repository.

These styles should work when installed, but inefficiently - quoting the developer:

[...] reStyle is meant as a replacement for Stylish and requires @document sections to know where to put the different kinds of styles. Without them, the only thing reStyle could do would be to apply the style to the UI, about:-pages and every web page. [...]
Most of the styles in the linked repo should actually be surrounded with this (even when directly pasted to the userChrome.css file):

@-moz-document
    url(chrome://browser/content/browser.xul)
{
    /* css from file here */
}

Without a surrounding @document rule (or a @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");), reStyle will not recognize a style as a UI style.

---

What do you think? Would you be willing to add these lines to all scripts posted here?

[Tim Van den Eynde]

I have been planning to write a tool for managing styles. It handles adding the right namespace by itself. I haven't worked on it recently, though, and if reStyle is an already working extension, I am happy to work with the developer to make my repository work.

The reason why I didn't include an @-moz-document or @namespace in the styles, is because I find it redundant and easy to automate. As far as I know, for userChrome.css, you don't ever need anything other than the given namespace. If this assumption is wrong, I can see the advantage of adding an @-moz-document in every file and I am definitely willing to include it. If the assumption is right, I'm actually more inclined to ask him to just support CSS files without any @-moz-document or @namespace in userChrome.css.

For what it's worth: there is one userContent.css file in this repository, and it actually has the correct @-moz-document tags.

That's just my current point of view, I'm definitely open for discussion.

[Madis Otenurm]

I think one good reason to include the namespace would be an import-based management, like "the new CTR" does.
That way all styles can affect what they need to and at the same time userChrome.css looks clean.

[Tim Van den Eynde]

That is definitely what I also had in mind (as demonstrated by this parse regex). But as you can see, for userChrome.css tweaks (not userContent.css), Aris also does not include the namespace in the css files. Example.

He also doesn't seem to be using it in his top-level userChrome.css though, so I'm not sure how that works. Is it maybe not necessary at all?

[mikhoul]

@Timvde Maybe you could try to coordinate also with @FirefoxBar to have a more standard format for the CSS files with this xStyle addon too.

I've opened an issue here FirefoxBar/xStyle#38 to have xStyle to support managing and editing of userChrome.css and userContent.css .

Regards

[Niklas Gollenstede]

I recommend the use of @-moz-document rules for styles in the userChrome.css especially in the userContent.css file in almost any case. As far as I was able to find out, the userChrome.css is applied to ~url-prefix(chrome://) by default. There are quite a lot of documents with that prefix (see this style for some examples. Most/many of the styles in this repository actually only need to be applied to the main Firefox window UI, whose URl is chrome://browser/content/browser.xul. applying them to the entire url-prefix(chrome://) is at best a performance burdon, at worst you end up styling elements you didn't intend to. Stuff like that can be hard to track down.

As for namespaces, I still don't know how they behave. reStyle currently just concats styles with different namespace declarations, which should be invalid (I think), but everything still works. reStyle simply takes the XUL namespace as an indicator that the style is not meant for webpages.