Feature request: Ability to install .user.css (or similar) files, as you would with userscripts

[obskyr]

The main problem I've always had with Stylish is that you need to register an account on userstyles.org and go through the upload process in order to share a user style. This prevents you from hosting your style on another site, and from easily sharing your styles with friends.

What I'd really like to be able to do is to just FTP up a CSS file to a server, send the link to a friend, and have Stylus automatically ask to install the user style when they visit the page - like GreaseMonkey would, for example. No having to copy-paste things, no having to click "Import styles", no terrible site-specific logic, just pure visiting a file and having the install process trigger. Beyond sharing with friends, this could also seriously improve the situation outlined in #65 - it'd open up an easy standard for building new user style sites.

Doing it with pure CSS files could use the @document rule to specify domain, or if you'd rather not do that, perhaps Stylus could recognize an extension like .usercss.json to install JSON files. Heck, you could even do both. My one true wish is just that there's a way to visit a single file and have Stylus automatically trigger an install.

[tophf]

Related: #39 "Install from URLs and toggle automatic updates per style"

[obskyr]

To build upon this a bit - this feature requires some decisions to be made, both for installing via CSS and via JSON.

Installing from CSS files

Regular Stylish CSS files can't be installed directly, as they don't include the style name, URL, and update URL (and the MD5 stuff, I suppose) in the actual file. One way to solve this would be to accept GreaseMonkey-style comments:

/** ==UserStyle==
  * @name        This is the style name!
  * @homepageURL https://example.com/
  * @downloadURL https://example.com/style.user.css
  * ==/UserStyle==
*/

@-moz-document regexp("https?://example.com/.*") {
    ...
}

This example takes property names straight from GreaseMonkey, but you could substitute in "updateUrl" and whatever else, of course.

You could also prompt for those details, buuuut of course that wouldn't be very automatic (and I don't want to have to fill out style names myself...). Another possibility is to prompt only if the comment is missing.

Installing from Stylus JSON files

In the case of JSON files, there's a problem with Stylus's current format: there's no separation between style attributes and user settings. Check out this JSON, grabbed from an entry from Stylus's "Export styles" feature:

{
    "enabled": true,      // User-specific
    "updateUrl": null,    // Style attribute
    "md5Url": null,       // Style attribute
    "url": null,          // Style attribute
    "originalMd5": null,  // Style attribute
    "name": "Style name", // Style attribute
    "sections": [...],    // Style attribute
    "id": 2               // User-specific
}

This means that the current Stylus JSON format - in its current iteration - can't be shared (unless you simply ignore the user-specific properties, but that'd be a bit weird, wouldn't it?), as the ID depends on how many styles you've installed until then, and enabled is entirely individual.

Hope I've provided some food for thought!

[tophf]

this feature requires some decisions to be made, both for installing via CSS and via JSON.

Obviously, yes. But personally I don't see it as a priority. Currently implemented features cover 100% of my needs. So hopefully someone else steps up and implements the thing. Also, IMO 99,999% of users install styles from USO that provides proper UI to customize style settings (we can add freestyler.ws, it's not hard, it's not yet done because I'm lazy).

JSON format - in its current iteration - can't be shared

Well, you can simply delete the user-specific id and enabled properties.

[obskyr]

Yeah. For now people install from Userstyles, since that's what exists and can be used.

Perhaps I'll implement it if I have time... it's not exactly a trivial undertaking. 🤔

[silverwind]

My vote is for Greasemonkey-style comments, they're easier to use than JSON.

A big question is how the style options (/*[[option]]*/) that us.org supports could be defined. color, text and image settings should be easy, dropdown settings will be harder. I was thinking about YAML-like syntax for them:

/* ==UserStyle==
@color-setting "color" "#16f"
@text-setting "text" "text"
@image-setting "image" "https://url/to/image.png"
@dropdown-setting "bg":
   - "Tiled Background":
    background-repeat: repeat !important;
    background-size: auto !important;
    background-position: left top !important;
   - "Fixed Background":
    background-repeat: no-repeat !important;
    background-size: cover !important;
    background-position: center top !important;
==/UserStyle== */

There are probably more elegant ways to define those. Also keep in mind that dropdown options can include nested /*[[option]]*/ in their body, so for those to work and not break the comment block, they should probably just parsed as [[option]] in these blocks.

cc: @Mottie

[Mottie]

I think this is a great idea!

It would definitively need something that would allow users to set options... If Stylus could be made to allow extensions to preprocess the css before it is applied to the DOM - it would only need to preprocess the css after any changes - an extension could easily replace any placeholders with user selected options. This would also allow developers to create userstyles using SCSS or LESS!

I agree with @silverwind that these options should be added to the metadata. For certain options that include css, it should allow both css snippets and a url that points to a sub-userstyle; a sub-userstyle would contain additional css that may be too unwieldy to add to a comment block (e.g. a user selected syntax highlighting theme). And it should also handle nested options, so that the additional css could include a @color-setting which is set in the main userstyle.

/* ==UserStyle==
@color-setting "color" "#16f"
@text-setting "text" "text"
@image-setting "image" "https://url/to/image.png"
@dropdown-setting "bg":
   - "Tiled Background": https://url/to/tiled-background.userstyle.css?version=1.0.1
   - "Fixed Background": https://url/to/fixed-background.userstyle.css?version=1.0.2
@dropdown-setting "syntax-theme":
   - "theme1": https://url/to/syntax-theme1.userstyle.css?version=2.3.0
   - "theme2": https://url/to/syntax-theme2.userstyle.css?version=1.2.4
   - ... (etc)
==/UserStyle== */

The sub-userstyle should be saved locally to storage, similar to how userscripts save all @require code locally so users don't have to deal with a FOUC.

IMO 99,999% of users install styles from USO that provides proper UI to customize style settings

I think that 99,999% of users are frustrated with the changes to USO and would be happy to use something else if there was an option.

[obskyr]

The sub-userstyle should be saved locally to storage, similar to how userscripts save all @require code locally so users don't have to deal with a FOUC.

👌👌👌👌👌 I think I'm in good company here...

I'll think a bit about this - if Stylus could achieve the level of simplicity and complete openness that userscripts enjoy today (while user styles have been missing out since the very beginning), that would be the world I want to live in.

[eight04]

+1 for less. More powerful than /*[[option]]*/. Maybe something like this:

/* ==UserStyle==
@name My Userstyle
@format less
@color-setting my-color #222
@url http://example.com
==/UserStyle== */

div {
	background: @my-color;
	border: 3px solid darken(@my-color, 30%);
}

/* another section with different match rule */
/* ==UserStyle==
@regexp www\.example\.com
==/UserStyle== */

div {
	color: @my-color;
}

Just generate the variables and send them to the compiler to get final CSS string.

[tophf]

Implemented in #134