Remove the editor (and the linter)

[silverwind]

Greasemonkey does fine without an built-in editor to and personally, I greatly prefer to use my own editor for editing plain .css files in the extension's directory.

Benefits would include:

• Much reduced package size, removing the CodeMirror and CSSLint and SQLite dependencies and a lot of wrapper code around those.
• No more headaches with the linter trying to create a one-fits-all configuration.
• Allows users to symlink .css files, so they can work off the same source as what's in a git repostiory.
• Removes the need to copy-paste for users who already use external editors.

[tophf]

Greasemonkey uses the Firefox's built-in Scratchpad. Stylus for FF will be able to do it too, arguably, thus removing the need for the built-in editor, but not Stylus for Chrome.

Also, Chrome extensions don't have direct access to the real file system but I guess this idea can be implemented by storing css files in a designated subfolder with a predefined name like userstyles inside the extension directory (initially empty with a readme text file inside) which we can enumerate periodically using chrome.runtime.getPackageDirectoryEntry (it's not implemented in FF/Edge). Since there is no way to subscribe to file system modifications, setInterval-based approach is required. One second interval seems too big a delay when you frequently save to see the changes. 100ms interval or less seems an overkill. A hybrid approach might be used: when a change is detected during the 1-second check, a new frequent timer is scheduled. However it still seems pretty dumb.

Anyway, the built-in editor should obviously stay in the Chrome extension, the extra 1MB of js stuff doesn't hurt performance as it's loaded only when you use it.

Actually, I have an idea for the built-in editor that would make it much more convenient than an external tool in most common use cases: 1. show it in a dockable sidebar similar to the devtools inspector in the page itself (implementation-wise it could be an iframe to a web_accessible_resource page of the extension or Shadow DOM), 2. implement element-picker (uBlock Origin has a nice one) that can navigate to the matching rule in the style you edit, or add a new rule based on your choice of selector path (like in uBlock), 3. use a single editor code box, of course, 4. add a hotkey/button/toggle to highlight the matching elements in the web page for the rule the text cursor is in, just like devtools does on hover in the Elements inspector.

P.S. There's no SQLite dependency and never was. The old Stylish used Chrome's built-in WebSQL, then switched to IndexedDB (which only recently became just as fast, arguably). Currently there's only a WebSQL migration microstub, it was necessary in the original Stylish when users upgrade from an earlier version. It's not really needed in Stylus as it's a new extension so there'll be no need to migrate a WebSQL database.

[narcolepticinsomniac]

Adding extra options in terms of editing styles would be great. Removing the built-in editor would be a drastic and unnecessary move though. As a matter of fact, that would be the type of unilateral decision-making I'd expect to see from the new Stylish devs. Exactly the type of thing we'd be looking to undo.

As for integrating an element picker, or an option to access the editor as an iframe/web_accessible_resource page of the extension or Shadow DOM, Freestyler has implemented similar features pretty decently. They were shortsighted in removing a classic manage/edit page instead of leaving it as an option though. For the element picker, they have incorporated Stylebot's UI. It's not bad, but they neglected to remove the automatic !important; insertions, which is a problematic "feature". The Stylebot editor they've integrated has the option to switch to a classic "code editor", which is injected as an iframe. The Stylebot picker/editor is part of the Shadow DOM. If it was improved, I see no reason you'd need both. The Stylebot editor could be made to have all the same functionality.

All in all, Freestyler's popup and the new Stylish popup are eerily similar. Maybe there's something to that, but that's beside the point. Neither team is trustworthy. Freestyler has added some cool features for editing styles. Stylus could add similar options without gutting the classic manage/edit functionality.

Stylebot is open source, and with some fine-tuning, it'd be a good starting point for these features. No need to completely reinvent the wheel.

[silverwind]

@tophf Ah, I've been using Greasemonkey with the external editor option for so long, I didn't even notice the Scratchpad option. The idea with polling chrome.runtime.getPackageDirectoryEntry sounds workable, but we'd also need a way to write the files when auto-updating for example. Are you aware of a way to write to the package directory? If that's possible, we could drop IndexedDB/WebSQL and pave the way for a external editor option.

Overall, I agree that some of my ideas are probably too radical for this extension 😉.

Element picker sounds like it's be hard to get right. It works for uBlock because the resulting selector is inserted in a flat list of selectors. Userstyles can include multiple nested @document sections. I imagine it'd be hard to find the right place to insert a specific rule. My usual workflow of adding new rules in a userstyle is to use the DevTools element picker, copy the styles that affect the element to my userstyle and modify them there with a !important appended.

[tophf]

we'd also need a way to write the files when auto-updating for example

Eek, extensions don't have such an API.

Userstyles can include multiple nested @document sections

Chrome doesn't support @document in CSS at all (Stylish-chrome feeds it separate <style> element per style section), let alone nested, and Stylish-chrome never implemented any workarounds for nested sections, primarily because it's quite complicated and resource-consuming in some/many cases of nesting.

[tophf]

Welp, with Chrome/WebExtensions API this is impossible to implement, and since that's unlikely to change in the foreseeable future I'm closing this.

[ErraticFox]

Don't mean to reopen, but I just want to confirm: As of now, there will be no way to edit a style with your own editor/ide?

[tophf]

Nothing changed since my last message. The only way is to use Mozilla import and export buttons manually.

[silverwind]

Maybe there is a way. See my idea at greasemonkey/greasemonkey#2513.

[tophf]

No, there's none. Your idea doesn't work.

[silverwind]

I had to try it anyways, and yeah, fileSystem is not available to extensions, only to apps. What could work is that the user inputs a file name in the extension directory and you fetch and save the file with ajax:

fetch(chrome.runtime.getURL("file.css")).then(function(res) {
  res.text().then(function(css) {
    // import css
  });
})

Still probably not that great of a UX.

[tophf]

We can't make the external editor aware of the user pressing the edit button and we can't pass the style text to external editor so there's no sane and usable solution worth trying to implement.

[tophf]

Well, strictly speaking, there is a workable solution: write a native OS application, which is installed separately and communicates with our extension via chrome.nativeMessaging API to pass the style text to a file and read it back on change, so if anyone is willing to write such an app (at least for Windows OS) we'll add the necessary support code in Stylus.

[ErraticFox]

I wasn't thinking of making Stylus pass it towards a editor, but more or less, saving the styles individually as a regular css file. We could then open up where ever they're saved such as the extensions directory.

[tophf]

@ErraticFox, that was also discussed and I don't see how that could be of any use.

• WebExtension can't write files to arbitrary folders. It can only write to the browser download folder or use FileSystem API that reads/writes any files in the depths of the browser user profile folder with obfuscated file names.
• The styles must reside inside the internal IndexedDB to be instantly loaded, not as external files.
• Keeping files in the extension folder is not feasible because those will be deleted on extension update.
• To read files from an arbitrary folder the extension would need an explicit "file://" permission set by a user. And the user would have to manually specify the full file:// URL.
• To detect whether the file was modified the user would have to press some button inside the extension. Or the extension would need to re-read the file every 1 sec or at best use xhr/fetch HEAD method to check its modification date (not reliable). Obviously, this would have to be limited to currently opened style in the Stylus editor otherwise just imagine we would have to check 100 styles every second.

Without a native OS connector app it's a dead end.

[silverwind]

To read files from an arbitrary folder the extension would need an explicit "file://" permission set by a user. And the user would have to manually specify the full file:// URL.

Maybe it's possible to intercept the opening of a file:// URL, similar to how Greasemonkey detects .user.js files when opened in Firefox? So a user could just drag a style into the browser for installation (and the extension could then poll the file as mentioned, if a developer mode switch is enabled).

[tophf]

Intercepting won't help because to read the actual contents an extension would still need the permission. Drag'n'dropping is a different case: the file contents may be read from the drop target object but that's just a one-time thing. Anyway, setting the URL is not the problem here, it's just a minor thing. There's no sensible method to use an external editor without writing the native app as I explained above.

[tophf]

Just to clarify, it's certainly possible to make an imitation of external editor support using file:// URL which is checked for update/changes, but personally I think such UX is embarrassingly lame so I can't get myself motivated to implement it.

[tophf]

Also, some day Stylus will be able to auto-update styles from arbitrary URLs, including file://, which would provide a solution for the external editor problem without explicit weird hacks. The only remaining problem will be the need to press the update button after each file save.

[ErraticFox]

To be honest, I really wouldn't mind that. I just simply prefer to be able to use my own editor, even if it's at the cost of pressing another button.

[schomery]

External editor integration can be followed here; #91