Install styles from *.user.css file #134
Conversation
|
@schomery, we need to test if adding a content script declaration in manifest.json disables the extension on update: please make a private copy of current Stylus with a dummy name in your google account, install it, update to this PR, and wait for an update (might be useful to click the "Update extensions now" button on chrome://extensions page). In case it gets disabled, apply.js would have to check location.href and load the corresponding scripts by sending a message to the background page that will do chrome.tabs.executeScript. Or webNavigationListener could do that, which is even simpler. |
|
@eight04, I haven't reviewed the code yet. Some behavioral observations first:
|
Currently it is just a placeholder. Where can I find a proper icon?
I just changed the Edit:
I haven't figured out how to do this. |
Unfortunately, I cannot publish any more extensions (even private ones). Mine is full! Anybody else has a dev account? |
|
Let's implement executeScript scenario I suggested then. We'll use it for freestyler.ws site later as well. @eight04, can you do it in this PR? |
|
I don't understand. Did you mean the new content script ( |
|
Use stylus preprocessor: /* ==UserStyle==
@name Test
@namespace test.com
@version 0.1.0
@preprocessor stylus
@include http://www.example.com/
@var theme-color 'Pick a color' #000
==/UserStyle== */
body {
color: theme-color;
background-color: lighten(theme-color, 80%);
} |
It will be programmatically injected instead of manifest.json. if (location.href.endsWith('.user.css') && window === top) {
document.addEventListener('DOMContentLoaded', function _() {
document.removeEventListener('DOMContentLoaded', _);
if (document.body.textContent.startsWith('/* ==UserStyle==')) {
chrome.runtime.sendMessage({
method: 'injectContentScript',
js: 'install-user-css.js',
});
}
});
}And in background.js::onRuntimeMessage: case 'injectContentScript':
chrome.tabs.executeScript(sender.tab.id, {
file: request.js,
allFrames: false,
frameId: sender.frameId,
});Other observations:
|
|
Correction: any preprocessors should only load when they're actually used because the majority of our users don't use any of them. |
|
We need to refactor edit.js. It is 2.2k lines now. |
|
Yes we do need to rewrite it, but that's a separate issue. |
|
Currently it opens the editor on first installation.
I was thinking to let users to create user-css when writing a new style (right now it is broken). By checking the checkbox, it switches the editor mode.
It can contain multiple sections, which are separated with metadata block: /* ==UserStyle==
@name Test
@namespace test.com
@version 0.1.0
@preprocessor stylus
@include http://www.example.com/*
@var theme-color 'Pick a color' #000
==/UserStyle== */
body {
color: theme-color;
background-color: lighten(theme-color, 80%);
}
/* ==UserStyle==
@include http://www.example.com/
==/UserStyle== */
body {
color: theme-color;
background-color: darken(theme-color, 80%);
}
This is borrowed from userscript. It would be easier to implement other rules like
I didn't think about that. Maybe splitting different sections into different editors makes more sense? To generate a .user.css file, the style author can simply concatenate them. The advantage of using single editor is just to have a consistent experience compared with normal text editors. |
I've used your sample code and although it's installed but nothing is displayed. I see an error in the background page though:
Well, I don't know your vision of the final UI but I don't like current implementation. Is this usercss so important that it should always be there? Personally, I don't need this feature so I'm more worried about reducing the influence on the standard workflow and UI.
Well, you basically ditch the goodness of the existing multi-section editor and the existing standard multi-section userstyle CSS format. I don't see it as a good idea.
I suggest using magic comments at the start of each section, which will do the same along with reusing current structure and format.
Which normal text editors? Our editor is very far from being even compared to normal CSS editors. |
Installation error is properly handled in 685f360.
If you were talking about the 'Userstyle mode' checkbox, how about to hide it when editing regular styles? We can even hide the checkbox when creating styles, which simply remove the ability to create usercss from the editor, then users won't notice any difference if they don't try to install/edit an usercss file.
I don't understand. This PR is based on the current format. It converts usercss to
If we use multi-section editor to edit usercss, we would still ditch the applies-to toolbar since usercss uses
I meant text editors like notepad, sublime, etc. They usually work with a single file. If the editor does matter, we can simply drop the changes to |
|
I'm all for being able to install from different formats. I also appreciate the effort going on here. That said, there's some choices that seem odd to me. Like tophf said, this isn't functionality I ever see myself using, so I've just skimmed the comments here. In that respect, I can review from the viewpoint of a typical clueless end-user. The easy stuff is the UI choices. I agree with tophf that the disabled checkbox is weird and unnecessary. The option for "Userstyle Mode" should be with all the other options below. Not sure "Userstyle mode" is a great name for it. Looks more like "Userscript format" to me, but maybe that's not accurate either. The "external" icon is being used incorrectly in the manager:
Any text in the editor before toggling modes back and forth results in a CodeMirror error shown. The biggest thing I don't get is why this is not a simple import function like "Moz format", which converts to our standard implementation? I'm not a fan of the disjointed formatting. |
|
By the standard userstyle CSS format I mean the one used in the classic Stylish-Fx, USO, and freestyler: @-moz-document domain("stackoverflow.com"), url-prefix("https://stackoverflow.com/documentation/") {
body {
background-color: #D9DEE0;
}
}
@-moz-document domain("gaming.stackexchange.com") {
body {
background-color: hsl(221, 47%, 33.7%);
}
}
@-moz-document domain("english.stackexchange.com") {
#footer {
background-image: none;
}
}My idea was to augment it with magic comments: /* ==UserStyle==
@name foo
@namespace bar
@var video-width 'The width of videos' 854px
==/UserStyle== */
@-moz-document domain("stackoverflow.com"), url-prefix("https://stackoverflow.com/documentation/") {
/* @exclude regexp("foo") */
body {
background-color: #D9DEE0;
}
}
@-moz-document domain("gaming.stackexchange.com") {
/* @exclude url-prefix("https://gaming.stackexchange.com/bar") */
body {
background-color: hsl(221, 47%, 33.7%);
}
}
@-moz-document domain("english.stackexchange.com") {
#footer {
background-image: none;
}
}As you can see, there's no Such file can be imported using the existing import button, which will additionally process the magic comments and set I don't know how to organize the editor UI though. |
|
Well, I can offer my opinions on the UI, but tbh, I don't really get the objective here. I understand why a legacy style Stylish editor option would be useful. Nostalgia, familiarity, organization, and plenty of available styles in Moz format. Are there styles available in these formats, or are we just implementing compatibility for the sake of being able to write styles in a different format? I don't get it. Admittedly, I'm not trying all that hard to understand, but this seems like a lot of effort for a feature I don't see being utilized. |
I think the "external" icon shouldn't be shown because clicking it will take the user back to the source page and cause the editor to open because it's in a userstyle format. I haven't had a chance to test this code, but how does it get updated? I don't see a
There aren't any styles in this format, but I think there is a lot of potential having a userstyle that can be installed from a source outside of USO; but I do agree with @tophf about keeping the same CSS format.
I think the |
|
I thought it might be useful to mention my idea about making a single code box that handles multiple sections while preserving the ease of visual manipulation. Turns out CodeMirror provides line widgets which we can show for
The big advantage is that with just one editor all multi-section styles will be handled internally a lot faster for everything related to DOM (displaying, scrolling, initial loading). To facilitate navigating between sections we could display a persistent shelf on the bottom with numbers 1 2 3 4 5 ... to scroll to that section. A hover tooltip may display a few lines of that section's code. We can even recognize magic comments /* @section-name foo */ and display them after (instead of) the number. |
It is not just the format. Moz-format userstyle is just a static CSS file but usercss needs to build the code dynamically according to its configuration. @tophf's solution looks good. I think the syntax is more CSS-ish. I'll take a look at moz-format parser.
Usercss has Currently usercss has its own update process without checking MD5. When updating:
There is a potential issue: usercss might be installed from file:// protocol. I'm quite sure auto-update would not work with it. I have no experience working with CodeMirror. I'll revert the changes to |
Alright. I just wanted to make sure I wasn't missing something. As long as we're all on the same page that this is mostly about "future potential", as opposed to being immediately useful, I think it's great. Usually when people show up and randomly start putting in this much effort, it's to fix or improve something that's bugging them personally, not to implement what is currently a fairly abstract concept.
Still don't understand why it wouldn't be "dynamically" converted upon install. All the "userscript-ish" format is either directly applied, or interpreted as, standard naming, applies to rules, update URLs, and stylesheets. The ability to install a different format is great, but why would that format need to be shown in the editor? I think of this as an installable/importable/exportable format, not a "mode" which should be shown in the editor.
Best of a bunch of worlds, huh? Performance improvements of single editor, and the convenience of sections with magic comments, seems like a no-brainer. Would we be losing any functionality for individual sections?
No doubt this'd be "non-trivial", as you like to say, but it does seem pretty awesome conceptually. It might be pretty sweet if magic comments could serve a dual purpose of naming and re-ordering sections. |
|
It seems that we can't reuse the moz-parser from edit.js. It can only handle regular CSS format and failed with nested rules which commonly used by LESS/SCSS. Maybe I can write a parser based on brace matching, but I doubt it would be compatible with all preprocessors we'd like to support. |
|
Yeah, I suppose you'll have to include less.min.js in the extension and use it to process the code. |
|
Alternatively, it's possible to tweak csslint to recognize nested rules. We already patched it locally several times because this library is effectively dead. |
|
I've finished the moz-format usercss: /* ==UserStyle==
@name foo
@namespace bar
@version 0.1.0
@var my-color 'Choose a color' #D9DEE0
@preprocessor stylus
==/UserStyle== */
@-moz-document domain("stackoverflow.com"), url-prefix("https://stackoverflow.com/documentation/") {
body {
background-color: my-color;
a {
color: lighten(my-color, 50%);
}
}
}
@-moz-document domain("gaming.stackexchange.com") {
body {
background-color: darken(my-color, 50%);
}
}
@-moz-document domain("english.stackexchange.com") {
#footer {
background-image: none;
}
}Any advice about the configure icon? Should I draw it myself? |
|
I think the editor should contain the unaltered style... the processed and raw css should be saved separately and the processing should only occur when the changes are saved. All the benefits of using stylus are lost if we present the user with processed css. Additionally, we should be able to "import" (under Mozilla format) the |
|
I agree. There was a single editor to edit usercss source before the revert (b4b2f61). Currently IMHO, we need a PR to refactor Also moz-format parser is already decoupled from |
|
Why not split out the code you are using now, like you did with |
|
Done. |
|
I think it's okay to merge. |
|
FWIW, zip of locally merged branches: stylus-master&usercss.zip |
|
I'm out of town right now with only my phone until next week |
|
I haven't been following all that closely, so with me testing, you're basically getting feedback from a typical clueless end-user. I really expected configuration options to popup automatically on the installation page. When that didn't happen, I expected them to pop up in the editor page that's opened upon installation. When that didn't happen, I looked around for an option to open the config settings manually and saw none. Did I miss something? If I wasn't aware that they were there somewhere, looking for them in the manager wouldn't be all that obvious. It's fine for them to be there as well, but that shouldn't be the only way to access them. They should open automatically, either before or directly after installation IMO. When I finally got to it, the config UI is really nice, and everything seems to work well. The message box closing upon save is kinda annoying, since I'm tweaking multiple settings and checking how they look, I have to reopen after every tweak. The example script should be altered to demonstrate font color correctly because changing it for 'body' does nothing. A few little UI quirks: Install page header should be on top, and I'd also suggest that the update option could be a simple "Check install URL for updates" or even just "Check for updates" without displaying the whole URL in the UI, which is a little messy looking. Also, blue links don't follow the monochrome protocol.
Install message box header/logo is out of whack.
Config message select should resize dynamically:
Should numerical inputs use
Another thought I had that I figured I'd throw out there, is that it'd be nice to be able to view the computed code. Not sure how important that is, but I wanted to see it. |
I had planned to add "configure" action in the popup panel: I think we can do this in another PR, also to keep the dialog after saving.
I guess it should be fine. Userstyles.org doesn't provide numeric field either.
Since the style is injected inline, you can find it from the inspector: Changes:
|
I'm aware. I meant a convenient way to view it in the editor. It kinda bugs me that I can't easily view the interpreted code, but maybe that's just me. Not terrible... just feels strange. If nobody agrees, NBD.
Difference is, the color input is a known entity. AFAICT, select text can be unpredictable, so if we do set a max-width, it should be at the aesthetically ridiculous point, and even then we might as well throw an ellipsis on it. Even your last photo was still cutting off text:
NBD either, if no one else feels like it's warranted.
That's cool too. The more ways to access it, the better, but the biggest point I was trying to emphasize is that the config needs to be integrated into the install process. It should pop up automatically, either before or directly after installation. Burying all your hard work elsewhere, where it might go overlooked, makes zero sense. If a style has config options, users should be aware right off the bat, and not have to go looking to click an icon in a completely separate area of the UI. Other than that, this format is really interesting. If options were more prominent during installation, it'd be a big improvement for users installing, compared to US.o, where advanced settings are buried and surely go overlooked fairly often. Also easier to host pretty much anywhere. The only variable is whether authors will get on board, since they'll have learn the basics. I hope it does catch on, because you've done a nice job with it here. |
|
@eight04, are you interested in speeding up |
|
I'm back! Glad to see this one merged! @narcolepticinsomniac Did you create a GitHub Dark usercss? I have that on my to-do list, but it'd be great if you already have it done 😜 |
|
Nah man, wasn't me. My pic is just a screenshot of an @eight04 screenshot with an arrow added to point out an overflow issue. Apparently he has converted it, at least to some degree, to use for testing though. |
|
@Mottie That usercss is generated by xStyle, by installing userstyle from USO and exporting it. |
|
@eight04 Is there any way I could get you to email me (gmail: wowmotty) the usercss? It'll save me some work since I can't seem to get the GitHub-Dark page on freestyler.ws to even load - look at the author page at the first entry. It doesn't even show the style name, and clicking on the link returns a server error. I reported the problem but haven't gotten a response. |
|
It was installed from here: Anyway, here is the gist: |
|
Hey @eight04! We need to provide AMO with a source for the semver bundle. Would you please add a tag to your build? It might be easier to slap a |
|
Would it be better if we don't fork the entire |
|
Whichever is easier... I created a |
|
I made a new repo with latest rollup and semver. The bundle size dramatically decreased ( I'll archive |
Partially implements #101.
With this PR we can install an
*.user.cssfile like:Main objectives:
@namespaceand@name, then replace the old one.@varand merge intosection.code.@varthrough a config dialog.Others:
Edit:
Edit 9/1:
An example of usercss host on gist
https://gist.githubusercontent.com/eight04/1b9edeb170d9f8bbabfb06dc6627f8f7/raw/foo.user.css
Edit 10/4:
=andvin@version.@var select.