Feature Request: want to NOT apply whole domain, maybe support specify url pattern in comments as meta data like Greasemonkey script does

[snowman]

like

• example.com/profile
• example.com/post
• example.com/article

[webextensions]

@snowman

Thank you for the feature request.

While we haven't thought through the design for it, we do intend to support such a feature.

On a slightly related note, we also intend to support use-cases like the ones described at https://github.com/webextensions/live-css-editor/issues/43#issuecomment-607462660 which may be implemented in a different UI form.

Some changes are being prepared for the "Options" page where the users would have more control options. Eventually, that would provide UI options to view/control the origins (sites) and pages where the styles get applied.

It is expected to still take some time to implement this feature. We intend to increase our speed though in the near future.

[Droyk]

@webextensions Will you please be able to tell me how much time would it possibly take? approx would be helpful. are you completely remaking your extension from the ground up for the V3 if so how much time is it going to consume? how much time has it already taken? I'm asking coz I'ma new dev & want to do the same thing knowing a real-life timeline would definitely help me to see things from a d/f perspective.

[webextensions]

@Droyk While the ad-hoc implementation of such a feature alone may not take much time (1 to 3 days), the real challenge is to identify good UX and ensuring that the data structure fits well for future as well.

General topics and challenges related to WebExtensions which need to be considered for devicing a proper solution:

• MV3 based API
• Many of those APIs are "async" (for good reasons)
• Cross-browser compatibility (particularly with Firefox)
• Limited UI space/size available (eg: for floating editor)
• Storing data offline (wherever possible)
• Communication with external sites
• Use optional permissions for security concerns of the user
• Slow updates in Extension store
• Review process in Extension store
• Ensure that library code is reviewable by Extension store
• CSS / JS of the site affecting in-page Extension UI
• A bit tricky setup related to sourcemaps
• Automated tests are tricky to setup (and depending on use-case, they may be slow to run)
• ... there may be more

While this list seems big, but these points are not applicable for all WebExtension. Also, some of them would go away once resolved (with custom implementation or some appropriate library).

But, there are big advantages also (compared to web apps), like, we don't need to worry about script load performance and we get access to more powerful APIs.

Regarding slow updates for this extension:

• Since this extension was created around 10 years ago, a good chunk of its code is based on plain JS (with jQuery) which is relatively slow to develop. For most of the new parts of development, we are using React.
• Apart from that since we are not working on it full-time as of now, it takes good amount of time before the feature requests are implemented.

If you have some good suggestions from UI/UX perspective regarding this or any other issues, feel free to add them here on GitHub. Since you are a JS developer as well, PRs are also welcome. If you are willing to contribute and looking for documentation about any piece of code, kindly create an issue.

Some additional references:

• https://github.com/webextensions/live-css-editor/blob/main/notes-for-developers.md
• https://github.com/webextensions/live-css-editor/blob/main/extension/README-FOR-EXTENSION-REVIEWERS.md