Closed jgkamat closed 6 years ago
Hi Jay,
IIUC this is essentially what #15 is about. It would require some modifications to the build system. You could say that it's on the to-do list, but it's not a very high priority for me, as it seems like a lot of work to workaround a problem that isn't exactly a problem to begin with, because the all-sites file is kind of like a shot in the dark, an "if it works, cool, but it probably won't most of the time" thing.
I think the easiest solution in your case would be to delete the bigblow.styl file and rebuild the CSS, then it will be excluded. :)
I saw in some of your other comments that you were having trouble with the build system, so let me know if I can try to help you with that. I'm not a Node guy really, I just installed what I needed from the Ubuntu repos as much as possible (I don't recall how much, if anything, I installed directly with Node), and it works for me. I'm really not a fan of Node, even less now than when I started this project, but Styl seems to be the most concise and powerful CSS framework, so I decided to use it.
IUC this is essentially what #15 is about.
Ah, I should have search a bit before opening this, this is basically a dupe of that.
I think the easiest solution in your case would be to delete the bigblow.styl file and rebuild the CSS, then it will be excluded.
I'll do that for now (and hopefully per-domain settings will come soon!)
I saw in some of your other comments that you were having trouble with the build system, so let me know if I can try to help you with that.
I eventually worked it out, it was a combination of getting node correctly installed (the package manager version was too old) and me being confused about the bigblow stylesheet breaking the all-sites css. I do like styl a lot, and it's a lot better than writing raw css, so I think it's fine! It dosen't matter for most users since the files don't need to be generated by most people. I'm 100% up to speed on the build system now, but thanks for asking! :smile:
Ah, I should have search a bit before opening this, this is basically a dupe of that.
No prob.
I'll do that for now (and hopefully per-domain settings will come soon!)
Well, not to be rude, but don't count on it. haha ;) I don't know if I'll ever do it, to be honest. I'm just not sure it would be worth the trouble. Theoretically we could figure out a combination of site sheets that don't conflict, and only use those in the all-sites file, but that seems like a fragile system to me.
I think the issue the all-sites file tries to solve is the tedium of installing site-specific sheets in the browser. If that were easier, then the all-sites file wouldn't serve much of a purpose in the first place.
Do you have any ideas for how we might make the site-specific files easier to install in browsers? That might be more of an issue for the browser extensions, but I wonder if there's anything we could do to help on this end.
Well, not to be rude, but don't count on it. haha ;) I don't know if I'll ever do it, to be honest.
Er, I was referring to qutebrowser per-domain settings (so I can use the site-specific files), not necessarily a solution to #15 :)
I agree that having a white/blacklist for the all-sites file seems very hacky, although it's very convenient to have!
Do you have any ideas for how we might make the site-specific files easier to install in browsers? That might be more of an issue for the browser extensions, but I wonder if there's anything we could do to help on this end.
I'm not sure, I'm not too familiar with how 'traditional' styling plugins work. For qutebrowser, I think it would be nice to provide the domain that corresponds to each stylesheet in a way it can be programatically parsed (I guess we could get it from the filename, but that seems brittle).
From a quick look at some userscripts on userstyles.org, I'm seeing things like this at the top of each one:
@-moz-document regexp("^https?://((gist|guides|help|raw|status|developer)\\.)?github\\.com((?!generated_pages/preview).)*$"), domain("githubusercontent.com")
maybe these headers could be 'tweaked' in a way to generate one file for all sites (so site specific quirks could be placed in their own blocks, but things would be in their own files). I don't know anything about that header though, so that's probably not possible :)
Er, I was referring to qutebrowser per-domain settings (so I can use the site-specific files), not necessarily a solution to #15 :)
LOL, my bad. :)
I'm not sure, I'm not too familiar with how 'traditional' styling plugins work. For qutebrowser, I think it would be nice to provide the domain that corresponds to each stylesheet in a way it can be programatically parsed (I guess we could get it from the filename, but that seems brittle).
Yeah, that's a good idea...
maybe these headers could be 'tweaked' in a way to generate one file for all sites (so site specific quirks could be placed in their own blocks, but things would be in their own files). I don't know anything about that header though, so that's probably not possible :)
Well, you know, that might actually work. I feel like there's some reason I rejected that idea in the past, but I'm not sure what it was.
I'm guessing my thinking was that the Stylish Firefox extension only allowed one site per stylesheet, despite the @-moz
line. But I don't know if I ever verified that that's actually the case. I wonder what would happen if we took two site-specific stylesheets, put them in a single file with the appropriate @-moz
selectors around each set of lines, and then applied it as a single sheet in the browser.
Would you be interested in testing that idea? One of the reasons I haven't done much with this project lately is that I haven't been using Firefox as my main browser for a while, so I haven't been able to use the Stylish extension. Since Mozilla is killing off XUL (and many of my favorite addons, like Pentadactyl), I have been losing enthusiasm for Firefox, but I haven't bothered to set up user styles in another browser yet.
If you're not, that's fine, we can just put it on the to-do list as an idea. :)
Thanks.
Would you be interested in testing that idea? One of the reasons I haven't done much with this project lately is that I haven't been using Firefox as my main browser for a while, so I haven't been able to use the Stylish extension. Since Mozilla is killing off XUL (and many of my favorite addons, like Pentadactyl), I have been losing enthusiasm for Firefox, but I haven't bothered to set up user styles in another browser yet.
I took a look, and the userstyle program I'm using (stylus) sems to be stripping the directive and properly using it to supply multiple sites! For example:
@-moz-document domain("githubusercontent.com"), regexp("^https?://((gist|guides|help|raw|status|developer)\\.)?github\\.com((?!generated_pages/preview).)*$") {
a {
color: red !important;
}
}
@-moz-document regexp("^https?://((www)\\.)?reddit\\.com((?!generated_pages/preview).)*$") {
a {
color: green !important;
}
}
seems to be properly applying to reddit and github respectively.
However, these directives dont work in qutebrowser (since it's not mozilla based). qutebrowser could strip these like stylus does, but that might be annoying. In any case, it would be nice to provide a plain css alternative if we do actually end up doing split css in this way.
I'm also not sure if stylish (the more popular plugin) supports this or not. Stylus is more powerful, so it might break the stylesheet for many users...
This definitely needs more research if it was to be implemented though...
Thanks for looking into that! I wonder if @The-Compiler would consider supporting the @-moz-document
selectors (if it's even possible to do that using WebKit).
I don't expect to work on this soon, but I'll add this to the tracker so maybe we can do it someday. Thanks.
The only way I could support @-moz-document
is by parsing and (and possibly splitting) the CSS myself, which I'd rather not do (at least for now - I won't say no to it completely yet, as cssutils might help with that and already is an optional dependency). :wink:
However, like mentioned by someone already, you'll soon be able to do per-domain settings (like a stylesheet) by hand. I think that's "good enough" for only a handful of stylesheets for now.
How do Stylish and others do this? Do they use @-moz-document
even on e.g. Chromium, or do they something like @match
and @include
comments like Greasemonkey does?
The only way I could support @-moz-document is by parsing and (and possibly splitting) the CSS myself, which I'd rather not do
I surely don't blame you there. :)
However, like mentioned by someone already, you'll soon be able to do per-domain settings (like a stylesheet) by hand. I think that's "good enough" for only a handful of stylesheets for now.
Will there be any kind of programmable or scriptable way to import stylesheets for specific sites? It would be cool if we could run a script like qutebrowser --import-css-for-site example.com example.css
The problem is that the copying/pasting/file-saving/button-clicking routine becomes quite tedious when you want to customize for several sites.
How do Stylish and others do this? Do they use @-moz-document even on e.g. Chromium, or do they something like @match and @include comments like Greasemonkey does?
I don't know, but I sure wish we/they could standardize on one way! :)
The new BigBlow css file seems to be conflicting with many of my sites in the all-sites css file.
For example Before:![2017-10-08-163430_1029x621_scrot](https://user-images.githubusercontent.com/4349709/31320678-9a575fa0-ac46-11e7-8f74-85ef1f5d21c7.png)
After:![2017-10-08-163445_1059x788_scrot](https://user-images.githubusercontent.com/4349709/31320680-9d41ba12-ac46-11e7-98e8-efc6ba3a449d.png)
Could the bigblow target please be excluded from the all-sites css file somehow?
(this is what caused the problems for me in the PR's I made).