Open silverwind opened 6 years ago
That was the initial implementation (it also allowed multiple blocks via separate CSS comments with @include
and @exclude
) and I've decided it makes much less sense than maintaining general compatibility with the existing userstyle format. I still think so. I'm against this proposal.
If we decide to deviate from the ancient Mozilla's @-moz-document
specification, which might be a good idea since that spec won't get approved anytime soon if ever, I think it might be better to introduce exclude-domain()
, exclude-url()
, exclude-url-prefix()
, exclude-regexp()
CSS functions similar to the existing ones.
xStyle also has an exclude()
function (exclude-regexp):
https://github.com/FirefoxBar/xStyle/wiki/Style-format#exclude
In the future, we may want to implement some directives to be compatible with Firemonkey. More information: https://github.com/JasonBarnabe/greasyfork/issues/656
Their directives match the userScripts API:
@match // alias of matches
@matches
@excludeMatches
@includeGlobs
@excludeGlobs
The only problem is that Firemonkey only supports single section style. I think we can wait a while and see if Firemonkey will improve their spec to support multi-sections style or just stay with the current syntax.
Multi-sections would be my preference. It would not support nesting like @-moz-document
does but I guess no one really needs that feature anyways.
/* ==UserStyle==
@name Style
@version 1.0.0
@match https://example.com
==/UserStyle== */
.div {
color: red;
}
/* ==UserStyle==
@match https://another.com
==/UserStyle== */
.div {
color: blue;
}
The first header should support all directives, subsequent ones could be limited to just the matching-related ones.
Any progess? Really want to exclude urls from code.
so do we need to make a separate extension for this single feature? or....
...or you can add it to Stylus, which is maintained by its users, i.e. there's no "author". Currently I'm essentially the only one doing maintenance, but it doesn't have to be that way.
sure. is there some document i can read to understand all the intricacies of the code base?
since we're talking about metadata, i assume i would be looking for some kind of metadata parser. ideally, i would be able to add "@exclude" to the list of syntax rules. then there must be some other place where i can take the value and hook it into whatever code handles style injection with a nice little if(url != exclude), and we should be good to go.
i looked, but didn't really find any documents outlining how the source code works.
(edit: found the metadata syntax rules list, will look for injection code next) (edit: found the injection code, looking for url matching logic) (edit: think i found the url matching logic... holy crap...)
There's no documentation for the source code. The parser is in https://github.com/openstyles/usercss-meta. The matcher is https://github.com/openstyles/stylus/blob/master/background/style-manager.js, specifically urlMatchStyle and urlMatchSection. Which one to augment depends on whether the syntax is for the entire style or per-section.
Before proceeding with implementation we should decide which syntax to use and how it would interact with @-moz-document
.
yay
Before proceeding with implementation we should decide which syntax to use and how it would interact with @-moz-document.
yeah........ so i'm thinking my original comment is much more preferable for myself (though not exactly ideal for any other users, but i also don't think there are any users who use my userstyles, so skipping all the bureaucracy and the waiting game is looking very appealing)
since i've barely looked at this code base for like an hour or so, i'm not sure i want to (or am qualified to) talk about your syntax decisions. also, considering i was able to figure out how to do this in that amount of time, i'm guessing the reason why this feature hasn't been implemented in the last 6 years has nothing to do with difficulty.
how long would it take to consider the syntax, clean up the code, and then push it out?
Initially posted at https://github.com/StylishThemes/parse-usercss/issues/7, moving it here because it's also a concern for Stylus' user interface.
I'd propose new
include
andexclude
directives in the usercss header which support glob-based and regexp-based rules, very similar to Greasemonkey's rules.The benefits of this include:
@-moz-document
blocks, which are not understood by browsers.There are a few drawbacks as well:
The transition to this format could be done smoothly by creating wrapper "documents sections" if a style is found to have these directives.