You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see no way to constrain global/overgreedy user styles to specific sites.
The "Custom included sites" option seems to disable the author's matches completely and put all sections on the matched sites. There's no constraining "whitelist" option.
The "Custom excluded sites" option allows disabling a style for specific sites, but the syntax seems to be limited to globs (iiuc), so I can't use this option to blacklist everything except the sites I need (I'd need negative lookaheads for that).
Real example
Case in point: Dark-Greasyfork. It has two @document sections: one useful, one global. Naturally, I don't want the global section to be used anywhere, especially considering it contains a :has() selector. However, I can't find a way to achieve that, like I'd do for, say, user scripts in Tampermonkey.
Possible solutions
If there's currently no way to constrain a global style, I can suggest adding these features:
An "Enable author's matches" checkbox next to the "Custom included sites" list (checked by default). This way, it could be used as an actual whitelist.
This is similar to Tampermonkey's "Original includes/excludes" checkboxes in a script's settings.
Support for the full @document syntax in the "Custom included/excluded sites" lists, in addition to globs. This way, it would be possible to add something like regexp(...) for full control.
This is similar to Tampermonkey's "User includes/excludes" lists in a script's settings, which use the same syntax as author's includes and excludes.
Both features seem straightforward to implement and will substantially improve the functionality of include and exclude lists, I think (considering this design is well tested in Tampermonkey and Violentmonkey.)
The text was updated successfully, but these errors were encountered:
It's not really straightforward because the author of the styles can change the number of sections or their order, but indeed this would be more useful than wholesale inclusion. Initially I envisioned the same approach you described, IIRC, but since I'm lazy I never got to implementing it properly and others implemented it in a simplified form that only suits one-section styles.
@tophf
I do understand that dealing with adjusting the matching rules of every section individually would be a pain in the ass, and I'm not even sure it can be done in a satisfactory way for more complex styles.
What I'm suggesting is still treating the style as a single section but adding more flexibility to it. And if somebody ever decides to take up the challenge of dealing with individual sections, this improvement would still be a step in the right direction.
Problem
I see no way to constrain global/overgreedy user styles to specific sites.
Real example
Case in point: Dark-Greasyfork. It has two
@document
sections: one useful, one global. Naturally, I don't want the global section to be used anywhere, especially considering it contains a:has()
selector. However, I can't find a way to achieve that, like I'd do for, say, user scripts in Tampermonkey.Possible solutions
If there's currently no way to constrain a global style, I can suggest adding these features:
An "Enable author's matches" checkbox next to the "Custom included sites" list (checked by default). This way, it could be used as an actual whitelist.
This is similar to Tampermonkey's "Original includes/excludes" checkboxes in a script's settings.
Support for the full
@document
syntax in the "Custom included/excluded sites" lists, in addition to globs. This way, it would be possible to add something likeregexp(...)
for full control.This is similar to Tampermonkey's "User includes/excludes" lists in a script's settings, which use the same syntax as author's includes and excludes.
Both features seem straightforward to implement and will substantially improve the functionality of include and exclude lists, I think (considering this design is well tested in Tampermonkey and Violentmonkey.)
The text was updated successfully, but these errors were encountered: