Timvde / UserChrome-Tweaks

A community maintained repository of userChrome.css tweaks for Firefox
GNU General Public License v3.0
1.26k stars 120 forks source link

Stylish compatibility #58

Open Madis0 opened 7 years ago

Madis0 commented 7 years ago

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?
Timvde commented 7 years ago

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.

Madis0 commented 7 years ago

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.

Timvde commented 7 years ago

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 commented 7 years ago

@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 https://github.com/FirefoxBar/xStyle/issues/38 to have xStyle to support managing and editing of userChrome.css and userContent.css .

Regards :octocat:

NiklasGollenstede commented 7 years ago

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.