The current theming model where themes can make assumptions about the DOM structure, classes, IDs, and all that is not something we can support any more, and so we are clearly going to kill that.
This is an excellent decision, and while the transition will be painful, it will make life easier for theme/plugin developers in the long run. “Engineering-driven decisions” is music to my ears.
It is likely that some parts of the UI will be implemented using native widgets
This is probably a bad idea, what with the arbitrary designs OS vendors may force on users in future.
I like the browser chrome to be as minimal and unobtrusive as possible, and almost fade into the background. Some people like big shiny toolbars and bright buttons all over the place. Others might want the toolbars to be toggle-able using a keyboard shortcut, or only show when they move the mouse. It should be possible to cater to all these groups using an API.
Even something a lot simpler, where users can create scalable bitmaps for buttons, toolbars, icons, etc. (Does anyone remember Winamp 2 skins, or Windows 7 visual styles?) would work well - as long as themers could define widget sizes, margins, padding and so on.
What if theme developers could export a file with all the necessary CSS selectors in it? This would save a lot of hunting around in DOM Inspector. I still break into a cold sweat when I remember trying to style tree elements in Firefox/Thunderbird.
I also really like the fact that presently I can add/modify keyboard shortcuts for commands, and add/remove items from popup menus. These things should also be configurable via an API.
There have been some really bad design decisions in the past, like a giant green animated arrow popping up whenever a download starts, that doesn’t provide any useful information and is visually jarring. (I think it was only in the nightlies, but that particular idea should never have seen the light of day). If I’d prefer to see small, styleable progress bars in the status bar for each download, I should be able to implement that. If someone wants a textual readout, they should be able to do that.
Keyboard navigation should be a first-class feature. I remember when logging in to a website for the first time, I could tell Firefox to remember the password by pressing Alt-R on a familiar dialog box. Then the dialog box turned into a fancy, non-theme-compliant popup, and Alt-R no longer worked. I remember when I could clear the download history by pressing Alt-C on the download history dialog. Can’t do that any more. Users should be able to define their own keyboard shortcuts in text-based config files.
To do something as simple as take a screenshot in Firefox, I have to either open a console and type screenshot --fullpage, or open Developer Tools then hunt-and-click on the camera icon. Why shouldn’t I be able to edit a text config file and specify, for instance, that Ctrl+PrtScr = DevTools.Screenshot ? Again, it should be easy to export all available commands to a plain text config file, like cvarlist and cmdlist in Quake.
As another example of why this is necessary, Thunderbird has some powerful keyboard shortcuts that don’t use any modifiers like Ctrl or Alt. So if I mistakenly think I’ve focused a search box and start typing, before I know it, a bunch of emails have been archived, or marked as junk, or something of the sort. This has caused me a great deal of unnecessary pain a number of times.
I should be able to enable/disable addons via user-configurable keyboard shortcuts. Presently if I want to disable, say, uBlock Origin, I need to open the addons page, then hunt for uBlock Origin, then click Disable. Why can’t I define Ctrl-Alt-U to toggle uBlock?
There’s no need to put esoteric options in the Tools > Options dialog box, about:config is fine. If a high level of configurability is a pain to provide support for, just provide a button labeled “Reset all UI changes” - like “safe mode” for the UI - and require users to click that before they ask for support.
Make configurations easily export- and import-able. uBlock Origin does this very well. One-click exports to/imports from human-readable text files.
And please, please, please make the status bar an integral component. Those who don’t want it should be able to hide it, but for some of us it’s essential.
Lastly, keep some sort of barrier to entry to being a theme/addon developer. Have a strict API, unforgiving of errors and intolerant of bad practices. That’ll go a long way towards not letting people create themes/addons that are badly designed and built.