1730228 - (tb-super-css) [meta] CSS reorganization and clean up

Status: NEW

(Thunderbird :: Theme, task, P4)

Description

[Alessandro Castellani [:aleca]]

This is a meta bug to collect and organize all the bugs and work necessary to improve our current CSS structure and clean things up.

Richard already landed some massive improvements to reduce duplication and create an easier and more consistent file structure, so let's continue that work.

Some initial pointers (WIP list that will be expanded with time)

Variables file

• Create a variables.css file to embed in all main windows, or imported by other files/dialogs.

This will allow us to avoid importing the messenger.css file everywhere just to inherit default colors and styling.
This file will also allow us to easily manage themes and dark mode variation by having all variables in one place and handling variations via media queries.

More generic names, less specific files
There are cases where we have unique CSS files called something like specific-dialog-name.css which includes mostly repeated CSS for styling the layout and elements.

We should try to have a components-oriented approach in order to make things more modular, BUT without going too granular.
Example:

• All our dialogs should look and behave the same, so having a dialog.css file makes sense, and we should try to have generic class names we can easily reuse.
• We should avoid going too granular with files like buttons.css or input-fields.css as that will force us to import multiple files just to style a simple layout.

Use shared files and less OS-specific files
We have many situations in which an OS specific file only has 1 declaration, or even none.
We should try to drop unnecessary OS variation files, where possible.

Selectors consistency

• ID selectors should follow a camelCase formatting without dashes or underscores.
• CLASS selectors should be lowercase-with-dashes, with no uppercase or underscores.

Note: Let's discuss here other suggestions, concerns, and an action plan before starting to work on this.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

Not sure if this is quite in scope, but we can also tidy up the jar.mn entries for the CSS files.

First, we can stick to alphabetical ordering of the entries (they are currently almost alphabetical).

Second, we can stop using /shared/ for the chrome path for CSS files that do not (yet) have any platform specific styling. This way, we can always use the import path chrome://messenger/skin/style.css instead of chrome://messenger/skin/shared/style.css. Whether a stylesheet is platform specific or not does not need to enter the logic of an xhtml import. If it becomes platform specific, we just need to change the jar.mn entries, without changing the import path.

For example, in mail/themes/shared/jar.inc.mn, the following use /shared/ in their chrome path but I don't think they do not have any platform specific entries (I just used some shell scripting to get the list)

aboutDownloads.css
abContactsPanel.css
accountManager.css
accountProvisioner.css
addressbook.css
cardDAV.css
cardDialog.css
converterDialog.css
EditorDialog.css
EdInsertChars.css
feedSubscribe.css
fieldMapImport.css
glodacomplete.css
messengercompose.css
sanitizeDialog.css
grid-layout.css

However, we already have some entries in this file without any /shared/ in their path https://searchfox.org/comm-central/rev/35c9e2929a5ae37d07192315db3787dc01f73441/mail/themes/shared/jar.inc.mn#106-120

Note that calendar/base/themes/common/jar.inc.mn only uses /shared/.

You can roughly check the current usage with https://searchfox.org/comm-central/search?q=chrome.*%2Fshared%2F.*css&path=xhtml&case=true&regexp=true and https://searchfox.org/comm-central/search?q=chrome.*%2Fshared%2F.*css&path=js&case=true&regexp=true

Comment 2

[Alessandro Castellani [:aleca]]

Some other necessary clean up:

• The messenger.css file is getting a bit out of hand, pretty much for all platforms. We need to decide if we want these files to hold all the most generic selectors that need to be applied everywhere, or be a bit more specific.
• The titlebar and toolbar styling are a bit all over the place, with similar selectors added in the messenger.css, the tabmail.css, the primaryToolbar.css, and the mailWindow1.css.
• Do we need to keep the mailWindow1.css file? The name is super weird.

Comment 3

[Lasana Murray]

When this reaches far enough, can we document these guidelines as well as the proper way to add new css styles on developer.thunderbird.net?

I wanted to bring this up for a while but was not sure where the best place might be. This seems like it. What do you think about re-organizing all content related files into their respective folders. That is to say, css,js,svg etc. all in one folder for each widget, component, dialog etc.
It would make for a more component oriented approach as everything related to any one component will be in its folder and would make navigating the code base easier. I imagine it may cause some problems with the way themes are currently done but should not be impossible.

Comment 4

[Lasana Murray]

(In reply to Henry Wilkes [:henry] from comment #1)

First, we can stick to alphabetical ordering of the entries (they are currently almost alphabetical).
...

This is something I always found should be done via some tool, such as a linter or even a cli script. It's strange to have to go through 100+ lines of declarations just to add a new one in alphabetical order.

Comment 5

[Alessandro Castellani [:aleca]]

Another thing to keep under consideration is a proper and globally applied :-moz-window-inactive.
Right now we don't do a good job in fading out a lot of parts of the application when the window is not focused.
It should be more obvious, but we should use color variables for it, rather than applying that property to every element.