Gather feedback from add-on authors

nt1m commented 8 years ago

@Aris-t2 @Quicksaver Hello, As you may already know, xul based add-ons and complete themes are soon going to be deprecated. This is why I have put up this proposal to figure out a WebExtensions based replacement for those. The proposal focuses on the following points:

Providing an API for theming Firefox in both interactive (tab-based, situation-based...) and static ways
Providing an API that won't break with Firefox changes (less maintenance work for add-on devs !)
Providing an API that is consistent with Chrome's API design (that doesn't necessarily mean limitations, just using similar naming/architecture)

This does not focus on hiding/moving elements around the UI, adding/showing/hiding toolbars; although I do plan on drafting that if I have some time.

Here is the state of the proposal: This draft went through a few revisions addressing feedback from Mozilla employees (I am not one to be clear). The general reception was positive, although some said it could use some tweaking to be more consistent with chrome APIs (issue #5).

Why I need your help?

Extending this API to fit your theming needs (issues #2 #3 #4)
Providing feedback about the API to improve it

Once this API gets stable enough, and once the issues are solved, I plan to implement a WebExtensions experiment that you'll be able to play around with, and once that gains enough traction, the API could be implemented.

Thanks in advance, Tim

nt1m commented 8 years ago

Please feel free to bring other add-on authors into the conversation.

nt1m commented 8 years ago

@Noitidart I think you might be interested in this proposal too

nt1m commented 8 years ago

The API proposal is at https://github.com/nt1m/WebExtensions-Theming-API/blob/master/Proposal.md

Noitidart commented 8 years ago

Hi @nt1m, excellent write up in Proposal.md. I have not created a theme myself but I have used a few and supported some (FxChrome) with additional features (via FxChromeMods). I have reviewed some themese using the Firefox theme'ing method.

The most successful themes I have seen do not use the actual Firefox theme method. Themese made with this method are seen here - https://addons.mozilla.org/en-US/firefox/themes/

The most popular themes I have seen, are made via add-ons. These addons inject style sheets that override default ones. Such as FxChrome, VivaldiFox, Firefox Dev Theme for non-dev. I checked Chrome's Theme API - https://developer.chrome.com/extensions/themes#manifest - to see if these currently popular Firefox themes would be possible, and it seems - not at all possible.

I then read your proposal - https://github.com/nt1m/WebExtensions-Theming-API/blob/master/Proposal.md - and it doesn't seem to allow inlaying/"over-laying" stylesheets to the main browser UI, is this true?

nt1m commented 8 years ago

@Noitidart Thanks for the reply! The reasons I decided not to go with a custom css support are:

CSS selectors are prone to break with Firefox changes
Permits stuff that could ruin the Firefox UX: huge font-size, elements being hidden, ... out-of-scope of theming
Sometimes you need a ridiculous amount of CSS to do simple CSS tweaking

Alternative CSS-based solutions have been considered (taking in account the problems above):

CSS variable based theme
High level CSS with high level selectors such as tab, window, toolbarbutton,... and with limitations (potentially dangerous properties removed)

My API proposal provides as much power as the solutions above, with the benefit of being consistent with chrome APIs, and supporting situation-based/tab-based theming. Plus, if you prefer CSS, there's a possibility of building a parser with this API and JS.

As the creator of VivaldiFox, I can tell you this API, in conjunction with #2 are enough for my needs. As for developer edition theme enabler, the case is a bit special since it only exposes a built-in theme (though I would see this theme being converted as well to this API).

For FxChrome, I would need help on #2 and #4.

Noitidart commented 8 years ago

Oh wow I didn't think of it but a "CSS variable based theme" would be real awesome I think.

Aris-t2 commented 8 years ago

In my opinion there should be a way to fully modify browser theme (tab shapes [old squared, modern rounded, chrome-like], colors, margins, paddings, switching images) with css the way it is done now even, if it might break the ui. It is up to the (theme/add-on) developer to make sure things don't break and to adjust css, if they break. Everything else is a non-welcome limitation and makes Firefox to lose the superior customizing state it has now.

A "CSS variable based theme" is great on the one hand, but still far too restricted on the other. Nobody wants to be restricted to a ui Mozilla devs have in mind.

Noitidart commented 8 years ago

up to the developer to make sure things don't break and to adjust css, if they break

I agree strongly with this. This is mentality when it comes to addon development.

I think one issue we need to fix though, on AMO, rather then trying to keep addon living forever by switching to a limited API, we should motivate/cultivate/make-easy-for a developer to attract/communiate-with its users who happen to be developers and would like to help maintain it.

rhelmer commented 8 years ago

Keeping extensions working across different versions of Firefox is an important consideration and a huge source of frustration for users historically - this is one of the things Chrome gets a lot of praise for, the extensions are not as powerful but they don't just stop working or exhibit bizarre behavior on upgrade.

However I think there are other reasons to tread carefully here:

WebExtensions are intended to be cross-browser and hopefully standardized - the Firefox implementation will (and already does) extend beyond what e.g. Chrome provides, but the basic design needs to be something other browsers are willing to implement (not all browsers use CSS for their UI so I think it's a non-starter).
Some extensions use CSS to spoof the UI in ways that are harmful to users. Chrome handles this by not allowing most pages to be modified by extensions at all, and themes are strictly statically defined in the manifest - I think we can do (much) better than this.

The Firefox UI using CSS/DOM makes really cool themes possible and should make it really easy for us to implement APIs to do dynamic themes, but I think it's too browser-specific and fragile to expect people to build themes on top of directly.

I totally understand the desire to expose as much functionality as possible, but doing it this way is dooming it to forever be Firefox-only and never part of any cross-browser standard.

nt1m commented 8 years ago

In addition to what @rhelmer said, some add-ons do the same thing (eg. add squared tabs), just with different CSS-based methods, and when installed together, they unfortunately conflict. This is the case with CTR and VivaldiFox squared tabs. This is one of the drawbacks of CSS based themes as well, and also where chrome wins as well. I do think both @Noitidart and @Aris-t2 have a point here though, so I see 2 potential ways to integrate CSS based theming here:

Add a WebExtensions manifest.json entry to inject a stylesheet into the main XUL/HTML window The stylesheet could be a stylesheet using high-level selectors or CSS variables.

{
  ...
  permissions: ["app-style"], // might be redundant with the applicationStylesheets field
  applicationStylesheets: ["tabs.css", "buttons.css"]
}

We could have an api controlling that as well: browser.ui.[add/remove]Stylesheet(url)

Please do note that while my API proposal at Proposal.md is more limited than what can already be done, it remains more powerful than what other vendors provide right now, with the benefits I have stated in comment 6. I don't know about standardization though.

Anyways, I will create WebExtensions Experiments for both the Proposal.md API, and the stylesheet API suggested above, and I will provide them to you so you can play with them.

louischan commented 8 years ago

The initiative of making a sustainable API is good. I am looking forward for the WebExtensions Experiments.

Quicksaver commented 7 years ago

Hi Tim, first of all I'm very sorry for not having contributed here sooner. I simply didn't have anything to add to the discussion.

It does seem like it's at least a well thought beginning for a solid and sustainable theming API, but I don't have much experience with themes, and unfortunately truly none of it really does much (read: at all) for my add-ons. There's no amount of CSS that, on its own, could ever help me do a fraction of what my add-ons currently do.

I have started a discussion in the dev-addons mailing list to try to find better solutions for my add-on, and perhaps some of it will eventually cross paths with something like this. But without knowing how the core of my add-ons could/would work as WebExtensions, there's really nothing I can add here for now.

nt1m commented 7 years ago

Firefox Developers have started the planning of their API here: https://github.com/mozilla/firefox-themes/tree/master/notes

est31 commented 7 years ago

@rhelmer

but doing it this way is dooming it to forever be Firefox-only and never part of any cross-browser standard.

Firefox-only features are a good thing from the perspective of Firefox. If there are no Firefox-only features, there will be no reason to prefer Firefox over the other Browsers anymore. Google has ran a nasty ad campaign at Firefox users, spamming them with ads on their main site about how fast and good Chrome is. They have the #1 and #2 site on the web, they can reach a much bigger audience than Mozilla has. Mozilla simply doesn't have this ability. Firefox needs something else to shine with than an ad campaign, and currently its customizeability.

I even understand that some things are harder to implement technologically with e10s or a quantum or servo renderer. But allowing the full set of CSS theming is certainly not one of those.

Yes, its a good goal to have a cross-browser extension standard. It'd be awesome to be able to run edge extensions without modifications on Firefox. Also, if add-on developers want to target stability, they should get an API that is as stable as possible. But in order to survive, Firefox must offer, and must continue to offer, a superset of those APIs. So if you have a non-css based theming API in the extension standard, why not offer a second API that is css based API just for Firefox?

This would be very similar to how another Mozilla project does it (and does it well!): Rust. Here, you have a stable release every six weeks with features that are promised to never be removed and never being broken in a major way. Then you have nightly, which includes the full set of features to experiment with. They might be removed in the future, or changed. Most of the features are to land in stable as soon as all issues with them are resolved and there is a consensus in the maintainer team to stabilize them. But some features are just impossible to get stabilized, like the intrinsics, which are a wrapper around LLVM's intrinsics, for which LLVM gives no stability guarantee.

Now most Rust programs run on stable as their authors strive to get their programs to be able to run on stable, as this widens the amount of users and reduces breakage. But some projects want or need all of Rust's features, and therefore require Nightly. But Rust developers don't say "we can't get intrinsics into stable ever so lets remove them for nightly users", they sill allow that usage.

Or to give another example: the GNU project. Bell labs doesn't develop UNIX anymore, and the original cross-unix programs only support a very limited set of features. But has that prevented the GNU project from extending coreutils programs? No, it hasn't. You have GNU extensions for all sorts of programs, giving unique features for GNU, and making all other tools less useful. Many Mac users envy the GNU/Linux users for the rich set of features they have access to, and sometimes even install GNU coreutils via homebrew.

Sorry for posting such a long comment with mostly off-topic discussion but I feel the general attitude by Mozilla towards this is self-harming and it pains me to see that.

nt1m commented 7 years ago

@Aris-t2 : I saw you saying that there's no WIP theme API to work with, sorry for not providing updates. There's a theme API being implemented here: https://bugzilla.mozilla.org/show_bug.cgi?id=webext-themes

Here are some builds you can try:

Right now, in addition to chrome APIs, you can:

Do as much as the Developer Edition theme
Do this: https://vimeo.com/190708433
It has enough APIs for VivaldiFox to work (I have a WIP port of my extension)
Dynamic theme changes work (not just static changes in the manifest like chrome)
Change toolbar icons
Set the background of in-content pages

There's currently no documentation for the API, but it builds up on top of Chrome's API. There are some examples here if you'd like to start playing with them. The examples are the files starting with "browser_ext_theme".

Also, note that you can make use of WebExtensions Experiments to suggest new APIs, those are all powerful extensions that define new WebExtensions API, you can use XPCOM/XUL whatever you like to define new APIs. You could for example define a toolbar API. Something like browser.toolbars.create({side: "bottom"}). There are some docs here: https://webextensions-experiments.readthedocs.io/en/latest/ if you'd like to experiment with creating new APIs. Note that Mozilla has set up WebExtensions Experiments to make sure extension devs can get involved into API creation as well, so please don't feel discouraged to create new WebExtensions Experiments.

Also, feel free to ask for updates on the project to either me, @msujaws, or @mikedeboer. Please let me know whether you have enough information to start porting CTR or if you need extra information.

nt1m / WebExtensions-Theming-API

Gather feedback from add-on authors #1