sizzle Root

Re: @Marti:

these opinions are treading seriously on the TOS I'm refraining from just removing users at this time. Other Admin+ aren't usually this lenient.

I just want to reaffirm this statement. @Marti is more patient than me, and if he chooses to interact with users, then I will let him handle the situation as he sees fit. But if I see a user making statements that seem to violate the TOS, I will not give them the benefit of the doubt. I will remove them without warning.


You're right Marti that OUJS probably isn't the best home for UserCSS. But I really feel for that community since they got shafted even worse the UserJS community. We dealt with the loss of a long time home that was neglected and slowly collapsed. Their home got sold right out from underneath to some company just looking to make a buck from the traffic.

At the very least the creators of this OpenUserCSS could fork our code base and make the desired modifications for hosting UserCSS and run their own instance.

As long as they were truly free and open source, I would be happy to collaborate with them to link our register user bases and have prominent links between sites.

Essentially both sites would have to handle new registrations on their own, but we could set up a mechanism to authenticate registered users on one site to be registered on the other.

Basically, if I went to OUCSS and typed in my username (usernames from both sites should be reserved on the other but nothing should be created automatically) to login, I should be created as a user there, and hopefully on my profile it would show I have no UserCSS but list my UserJS (or at least a link to my scripts on OUJS). The actual links to the listed scripts should point to the pages on OUJS. Samething goes for a user registered on OUCSS logging into OUJS for the first time.

This does require mirroring moderation removal of users on the site the user originally registered on. Of course you can always ban users that registered on the other site, and whether this removes the user from the origin site is up to them. We'd probably mark the user for moderation review.


As far as I'm concerned, a user style is just another asset/resource. We already host javascript libraries on this site that are meant to be @require'd by the user scripts installed from the site. I once considered whether we should host css and html templates as well. The only thing I was really opposed to hosting was media (graphics, audio, videos, etc.). User scripts could use these css files via @resource and those with some type of Stylish extension could just install the styles directly. I would probably replace the "Libraries" link in the toolbar with "Resources" and that would take to a page where could filter be the type, i.e. Libraries, Styles, and Templates. If we started getting a lot of user styles uploaded here we could add a direct link to that filter in the toolbar.

Just to be clear: we really do mean Open. Anything uploaded here would have to be released under a share-alike license permitting derivative works. This would have to be a content license since code licenses used for scripts and libraries only apply to code not content like CSS (@Marti can let know if I'm wrong about this).

Re: @r-a-y:

Not sure what the brass at OpenUserJS thinks though.

Well I'll have to find out what @Marti and others think about the idea, but this site is an open source project so if somebody submitted a PR with necessary changes and the idea had support, I wouldn't stand in the way. The "brass" in this case are just the people who pay to host the site and those who want to make sure it is stable, secure, and maintainable.

Basically the Stylus users talking about starting their own site (which is exactly how this site came about with the collapse of userscripts.org) could submit a PR to OUJS with the changes to incorporate a UserCSS hosting service into this site. They could even user a different url and forward it the the relevant UserCSS homepage on this site. They could even use a slightly different template and style on the pages relevant to UserCSS. The point is: this site is similar, open source, and already built.

I find it disappointing that the creator of Stylish and userstyles.org (who is also the creator and owner of greasyfork.org) decided to sell off userstyles.org and abandon the community.


Re: @mihaimorcov:
Just to clear, according to our TOS, all scripts must be licensed under an Open Source Initiative approved licensed. All of these allow derivatives. Unless someone violates the terms of a license (like not giving proper attribution if required), we can't remove a script. Yes we would really prefer people to use the forking feature since it preserves forking history, but we can't remove a script just because they don't use it.

From day one we were and still are a host for FOSS user scripts. It was something I thought key to the user script community. But if you want to use copyright to "protect" your precious user scripts, then this really isn't the place for you.


Re: @ts:

I did not focused on minify them because I do not want keep my source code secretly.

That is exactly the reason OUJS is providing this option. In the past authors have posted minified versions of their scripts on the site, but we decided that minification != obfuscation so we wouldn't remove these scripts. However, if we provide automatic minification then they have no excuse to post an already minified script and we can remove it. Therefore source code isn't secret. The full unminified source will be posted on the site for everyone to see.

The method you're using to have multiline strings is an unstable hack. Have you considered using @resource and GM_getResourceText. You could put them in a public gist and use the Raw url for the @resource key. ES6 will provide template strings.

Otherwise just let your users know on the script description page not to install the minified version.


This might help (you might have to use @run-at document-start):

var pushState = window.history.pushState;
window.history.pushState = window.history.replaceState = function (stateObj, title, url) {
    console.log('changed to: ' + url);
    pushState(stateObj, title, url);
};

Re: @sizzle:
My bad. I didn't read your entire post. You already used popstate. I've had this problem on a similar page. The onpopstate doesn't help. The page doesn't reload, but the url changes.



Re: @Marti:

I figure if you're going to post the source of a library from somewhere else, you should post the full source (especially since it usually has the copyright notice in it).




This is not the place for this discussion. This has already been proposed and shot down on GitHub. I have strong arguments against it and the other project owner mostly agreed with me. The only way I'd change my mind is if I got strong feedback from users.

In the future, request site features on GitHub. You can request feedback for the GitHub issue in the general discussion category, but keep your arguments on GitHub where the other developers can see.



Both Greasemonkey and TamperMonkey handle script updates automatically. All the script author needs to do is increment the @version metadata value when uploading a new version.


There you go. The reminder will only show up if you aren't logged in or you use Google for authentication. We don't have any way of telling who's done migrating so those who use Google will just have to put up with it until April 20th.



assume each site takes a different approach to how it discounts duplicate installs

OUJS counts every request for the .user.js file as an install. No attempt is made to prevent "duplicate" installs.



I think it might be time to increase the flag threshold on scripts.




OUJS has been the shorthand for OpenUserJS.org for awhile so I decided to purchase the domain and set up redirection: oujs.org

So now you can link to your script homepages (or any page) with a shorter url:

http://oujs.org/scripts/sizzle/Hello_World -> https://openuserjs.org/scripts/sizzle/Hello_World

Notice that the redirect url is http not https (but it does get redirected to the secure site).

I have no idea if you install a script using the short url if updating will work properly (since updating must be done over SSL).


The number I enter into the script settings dialog isn't being used for the ?limit= in the query string. Instead it is being set to undefined, which makes me think it is a mistake. Setting limit to a non-numeric value is a hack to return all results. Please fix your script or I will be forced to close this loophole for good. Thanks.


Re: @Marti:
There should probably be a message explaining the one new group per script restriction on that page.


Re: @trespassersW:
The basic idea behind the current system is that anything besides a positive or negative vote is pretty pointless. Other systems use stars but that scale can mean many things to different people. Allowing comments to be attached to a review is also counter productive for everyone involved. You either get the love ("This is such a great script. I couldn't live without it.") / hate ("This script is completely useless. Not worth installing."), both of which can be captured by a simple positive/negative vote, or worse you end up with misplaced bug reports or feature requests. Just go to AMO or Google Play and it'll be clear that the vast majority of reviews are bug reports and feature requests, with the remaining being love/hate messages. Could someone write a very useful constructive review? Sure. But the reality is that it almost never happens. Even if it did, that user would have by definition some criticism so they could open an issue. If you want to be showered with praise, I'm sorry but numbers and the occasional complement in an issue will have to do.