Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Metadata block items #197

Closed
jerone opened this issue Jun 23, 2014 · 2 comments
Closed

Metadata block items #197

jerone opened this issue Jun 23, 2014 · 2 comments
Labels
enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. team biz This is similar to a meta discussion.

Comments

@jerone
Copy link
Contributor

jerone commented Jun 23, 2014

The following extensions have support for different metadata block items:

Right now we are supporting a few of the userscripts metadata block items:

  • @name
  • @namespace
  • @description
  • @version
  • @icon and @icon64
  • @author
  • @collaborator
  • @licence and @license
  • @homepage and @homepageURL

What other items should we support?

I found the following interesting:

All other metadata block items are only interesting for developers, who can also read the source if they need the info.
@jerone jerone mentioned this issue Jun 23, 2014
Merged
@Martii
Copy link
Member

Martii commented Jun 23, 2014

@developer

Similar to our legacy @author and @collaborator usage currently. Could be upmixed with @collaborator assuming our usernames are identical to every other user.js site... e.g. not recommended.

@website

Could be upmixed to @supportURL or @homepageURL easily which is much clearer on what that is.... e.g. possibly redundant but doable... more towards SEO though and @copyright is pretty specific on this... so probably not recommend. Implemented in Scriptish... currently upmixed.

@source

Could run into anyones site terms regarding hotlinking, install counters, and could be confusing with @installURL/@downloadURL and others... runs into url changes such as githubs recent changes to raw urls, etc... e.g. don't recommend Implemented in TamperMonkey and currently upmixed.

@screenshot

Why not just look at the @homepageURL instead? I'm also thinking data URIs might be a storage hog especially in the meta routine store... e.g. don't recommend unless restricted to http and https schemas, suffix with URL so it becomes @screenshotURL with an upmix, never display the image itself ever ever ever (think of a 10Megapixel bmp file or 100% quality jpeg and cache all screenshots into a thumbnail list which can violate Content copyright and put us in trouble and of course porn), and any other input from everyone... e.g. overall really don't recommend.

@contributionAmount

I don't really feel like validating extra web urls manually to see if they aren't a phishing scam (this comes along with this key and not yet mentioned)... does anyone? Known repositories I will validate manually though... e.g. don't recommend

...

@iconURL

Could be possible but not on an upmix due to GMU/AOU and will probably run into conflicts down the road... and never show because @icon was already established by GM... e.g. don't recommend because already standardized. Implemented in Scriptish and TM... currently umpixed.

@icon64

Is this useful anywhere or in some spec? 48px by 48px is the current standard right now and usually those do well with auto browser sizing to 64pixels. I am contemplating pr'ing to have that removed but not sure yet.

Scriptish has a lot of redundancy and picking and choosing which ones we display and with optional linking should be chosen carefully. The ones showing now and in #189 are important to protect OUJS as well as some basic general information due to the fragmentation from USO... and of course what "Founding Father GM" supports. I don't think anyone would want to scroll through a long list of these just to get to our real script homepage (user content). I accommodated for this partially with the set of ids in #144

Bloating up the metadata block isn't always a good thing for speed with a lot of users.

When a variant or exact copy of the README.md does get synced from #81 I think this will alleviate some of these suggestions.

See also:

@Martii Martii added team biz and removed Feature labels Jun 23, 2014
@Martii
Copy link
Member

Martii commented Jul 12, 2014

So what's currently left is:

  • @developer -1 from me and -1 from GM Port.
  • @screenshot -1 from me and -1 from GM Port.
  • @contributionAmount 0 from me... open up a separate PR for this presumably under "Allowing SEO and Marketplace" to isolate this. Again the majority of user.js engines MUST agree to this or be "undefined" minimally. -0 from GM Port btw. SM is more protective on security than most browsers.
  • @icon64 0 from me... using it where?

Closing this issue since it's become somewhat stale... reopen with comments if need be.

Refs:

@Martii Martii closed this as completed Jul 12, 2014
Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Mar 7, 2016
Post fix for @supportURL and homepageURL
93c1204 
* Trap if a Userscript doesn't encode one of these urls correctly. Fixes "Page Load Error" with "Failed to Connect"... server trip

Applies to OpenUserJS#819, OpenUserJS#239, OpenUserJS#197, and OpenUserJS#189

Ref:
* https://openuserjs.org/discuss/webhook_not_working
@Martii Martii mentioned this issue Mar 7, 2016
Merged
@OpenUserJS OpenUserJS locked as resolved and limited conversation to collaborators Apr 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. team biz This is similar to a meta discussion.
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jerone @Martii