update readme

README.md

@@ -413,19 +413,13 @@ Having done this, make sure your `chrome_debugger_profile` folders do not have `
 
 <br/>
 
-Using autoconfig places some constraints on design. We can't always write these scripts in exactly the same style that Firefox components are written, because Firefox scripts are executed in a different way. And the way the scripts are loaded encourages a procedural style. Some might prefer this from the outset for various reasons. I do use a procedural style for the shortest scripts that are least likely to change or be extended. But for the most part you'll notice a more object-oriented style in these scripts, which might seem weird. A lot of scripts have classes that are only instantiated once per script execution, for example.
+Using autoconfig places some constraints on design. We can't always write these scripts in exactly the same style that Firefox components are written, because Firefox scripts are executed in a different way. And the way the scripts are loaded encourages a procedural style. Some might prefer this from the outset for various reasons. I do use a procedural style for the shortest scripts that are least likely to change or be extended. But for the most part you'll notice a more object-oriented style in these scripts, which might seem weird. A lot of scripts have singleton classes, for example.
 
-The main reason I use this style in spite of the subscript loader is because it makes it a lot easier to hook into the scripts from outside. My goal in doing that isn't encapsulation, it's just creating little modules that other scripts can access and modify without re-instantiating them, that can be modified or debugged from the browser console. This is why I will often define a script's class instance on a property of the global object, even though everything in the script references it with `this`.
+The main reason I use this style in spite of the subscript loader is because it makes it a lot easier to hook into the scripts from outside. My goal in doing that isn't encapsulation, it's just creating scripts that double as modules or services that other scripts can access and modify without re-instantiating them, that can be modified or debugged from the browser console. This is why they often define a script's class instance on a property of the global object, even though everything in the script references it with `this`.
 
 Another reason is because, at least in my opinion, the bulk of Firefox's JavaScript component code is object-oriented, not necessarily by choice but because of other constraints on component code. For example, [JSActors](https://firefox-source-docs.mozilla.org/dom/ipc/jsactors.html) _must_ use classes, by design. And custom element definitions always use classes or function factories because custom elements are object-oriented by definition.
 
-One way or another, something like half of these scripts are modifying object-oriented components, and nearly another half are creating new object-oriented components. Keeping in lockstep with Firefox's JavaScript conventions makes everything easier, from initial design to debugging and to updating. So that's why I do it even if it's not as concise and performant as a more procedural style would be.
-
-Even within a given script, I will often use object properties instead of block scoped variables even though they're only referenced in one block. This is because I may need to write another script to be compatible with it, so another script may need to access that state. I also may need to mutate it from the browser console in the process of debugging. And it doesn't work to write the script in one style for debugging, then refactor it for release. Nothing is ever final on this repo, because it's all anchored to Firefox Nightly. Firefox is updated daily, so these scripts need to be updated regularly too.
-
-Another goal is to make every script as "standalone" and "portable" as possible. I don't want to write scripts with a bunch of dependencies. So my intention is that each script is a single file and requires nothing else except Firefox and fx-autoconfig, the script loader. Some of the scripts are written primarily to extend duskFox (the CSS theme) so those scripts will obviously require the theme as well. But to get one of the scripts below to work, you shouldn't need to download other files.
-
-There are a few exceptions. [Restore pre-Proton Tab Sound Button](#restore-pre-proton-tab-sound-button) is listed as an autoconfig script, but the bulk of that mod is actually a replacement of [tabbrowser-tab.js](https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser-tab.js). As mentioned earlier, that kind of replacement can only be done through the component registrar, by using the `override` syntax in [chrome.manifest](#resources--manifest). And it also requires restoring CSS for the removed elements. So those who use duskFox will already have that replacement and the necessary CSS. The script is just for dealing with tooltips on the sound & close tab buttons. So in that sense, it's not standalone. Non-duskFox users will need to download additional files, as discussed in the script description.
+Another goal is to make every script as "standalone" and "portable" as possible. So my intention is that each script is a single file and requires nothing else except Firefox and fx-autoconfig, the script loader. Some of the scripts are written primarily to extend duskFox (the CSS theme) so those scripts will obviously require the theme as well. But to get one of the scripts below to work, you shouldn't need to download a heap of dependencies.
 
 Some of the scripts, like [Restore pre-Proton Star Button](#restore-pre-proton-star-button), come in two versions — a duskFox version and a standalone version. The difference is simply whether the script includes the necessary CSS. duskFox already includes all the CSS for those scripts, because it's easier to read in stylesheet form. So if you want to modify it, you can. But we don't want to load a bunch of redundant CSS, so I made versions of these scripts that simply have the CSS removed. That means these versions are not standalone, but they're only intended for those who are using or plan to use duskFox.