Scripts w/ // @match *://*/* don't show on greasyfork.org/en/scripts/by-site/*

[adamlui]

I just enhanced BraveGPT/DuckDuckGPT/GoogleGPT to match all sites and add highlight-to-ask GPT functionality, but counter-intuitively I am penalized by no longer showing for scripts/by-site/brave.com, scripts/by-site/duckduckgo.com and scripts/by-site/google.com. This is bad UX because users browsing by those search domains are exactly interested in scripts like this. Just because they happen to match all is not a good reason to exclude

[JasonBarnabe]

This is intentional behaviour.

If scripts that affected all sites appeared on every per-site listing, then you'd get the same scripts on every listing, making it less useful.

This also serves as an incentive for script authors to specify what sites their scripts affect (if they can), which is better for user experience and security.

[adamlui]

It is more not less useful to know exactly what every script on GF applies to a domain. Why would it be more useful for user to know a partial list only?

Re: incentive, you are suggesting I make my script less powerful by disabling my highlight-to-ask from working on every page + using a gazillion matches for bigger filesize as somehow "better" for UX, when I cannot see in what way this is not worse

[adamlui]

I'm going to do it though, just saying it's a worse not better UX to have scripts take longer to load and not work on every page as intended out-the-box just to accomodate the site it's listed on

[adamlui]

I must say it is quite therapeutic testing my simple highlight phrases pops up my Ask GPT menu (as it should on any webpage that uses HTML) one-by-one per domain, but I do not look forward to adding thousands of lines of matches due to this bizarre policy that is very counter a positive UX