@icon

[TriMoon]

First of all, GREAT work keep up the good work 👍

That said, could you add support for @icon 🤝

Maybe while you're at it also @namespace 😉

[erosman]

could you add support for @icon

@icon

Icons (@icon, @icon64, @icon64URL, @iconURL, @defaulticon) are not processed. Remote icons can be used to track users e.g. ⓘ

Maybe while you're at it also @namespace

What is the benefit?

[TriMoon]

What is the benefit?

See: https://sourceforge.net/p/greasemonkey/wiki/Metadata_Block/#namespace

This allows multiple scripts to share the same name in case of clashes.

Remote icons can be used to track users e.g.

Not if the icons are downloaded only once per install/update.
At which time, unless a local install, they can already be tracked irrelative to this...
(You could disable the icon download for local installs using a setting...)

Edit:
Oh by the way, if the icon used is the favicon of the website the script operates on, tracking in this context is completely out of meaning.

[erosman]

FM doesn’t use @namespace but userscripts can have it. The original idea of @namespace was to enable having multiple userscripts with the same name but different @namespace.
Why would having multiple userscripts with the same name be useful?
How many such instances are there?

Not if the icons are downloaded only once per install/update.

The tracking still occurs that time.
Furthermore, storing it bloats the storage area since it has to be converted to a sting in order to store.

The icon is only a display feature for when editing the script. It has no practical use.

[TriMoon]

Why would having multiple userscripts with the same name be useful?
How many such instances are there?

Imagine someone using a downloaded userscript, and then modifying it to add extra functionality for their own needs, they could keep both installed at same time.
Hence you should not consider the amount of current instances using it, but rather give people the possibility to use it when needed.
Else you will end-up in same boat as early computers were that said something similar to "64k ought to be enough" 😉

• Options are good, options are a dev's best friend.

The tracking still occurs that time.

I really don't understand this point of view.
A one time download of an icon is nowhere near any definition of "tracking" because that would imply repeat downloads AND making use of other sophisticated coding and/or cookies etc.
If the mere act of connecting to some IP is "tracking" in your view, then you are already "tracked" 24/7 while connected to the internet, because you can't use the internet without connecting to other machines.
Don't get me wrong, i personally am also against tracking, but there is a limit you should draw a line at.

Furthermore, storing it bloats the storage area since it has to be converted to a sting in order to store.

Any and all userscripts will "bloat" the storage space already, this argument is also invalid IMHO.
Because how big is an icon in general, a few kb? wow...

The icon is only a display feature for when editing the script. It has no practical use.

It is/can be used to display in the list of active userscript's for the website that is been viewed.
Yes not all visuals have functional meaning but they make a product look much better for the user...

---

Disclaimer

If i came over a bit strong i apologize, it's not my intention and i highly appreciate your efforts in this project like most do that make use or will make use of this. 👍

[erosman]

Let's see if there is a popular demand for such feature.