This page is not complete.
This document contains guidelines defining how CSS inside the Firefox codebase should be written, it is notably relevant for Firefox front-end engineers.
Here are some basic tips that can optimize reviews if you are changing CSS:
!important
but if you have to use it, make sure it's obvious why you're using it (ideally with a comment). The Overriding CSS section contains more information about this.vertical-align: -2px;
. The reason you should avoid such "hardcoded" values is that, they don't necessarily work for all font-size configurations.classList
is generally better than className
. There's less chance of overwriting an existing class.:last-child
, when it is what you mean semantically. If not, using a semantic class name is more descriptive and usually better.Make sure each file starts with the standard copyright header (see License Boilerplate).
It is good practice to check if the CSS that is being written is needed, it can be the case that a common component has been already written could be reused with or without changes. Most of the time, the common component already follows the a11y/theme standards defined in this guide. So, when possible, always prefer editing common components to writing your own.
Also, it is good practice to introduce a common class when the new element you are styling reuses some styles from another element, this allows the maintenance cost and the amount of code duplication to be reduced.
linear-gradient(to bottom, black 1px, rgba(255,255,255,0.2) 1px)
!important
.Do this:
margin: 0;
Not this:
margin: 0px;
It is often harder to understand what the shorthand is doing and the shorthand can also hide some unwanted default values. It is good to privilege expanded syntax to make your intentions explicit.
Do this:
border-color: red;
Not this:
border: red;
Do this:
h1, h2, h3 { font-family: sans-serif; text-align: center; }
Not this:
h1, h2, h3 { font-family: sans-serif; text-align: center; }
lower-case-with-dashes
is the most common.camelCase
is also used sometimes. Try to follow the style of existing or related code.="true"
in attribute selectors.
option[checked]
, not option[checked="true"]
..autocomplete-item[selected] > .autocomplete-item-title
would be more efficient than .autocomplete-item[selected] .autocomplete-item-title
Before overriding any CSS rules, check whether overriding is really needed. Sometimes, when copy-pasting older code, it happens that the code in question contains unnecessary overrides. This could be because the CSS that it was overriding got removed in the meantime. In this case, dropping the override should work.
It is also good practice to look at whether the rule you are overriding is still needed: maybe the UX spec for the component has changed and that rule can actually be updated or removed. When this is the case, don't be afraid to remove or update that rule.
Once the two things above have been checked, check if the other rule you are overriding contains !important
, if that is case, try putting it in question, because it might have become obsolete.
Afterwards, check the specificity of the other selector; if it is causing your rule to be overridden, you can try reducing its specificity, either by simplifying the selector or by changing where the rule is placed in the stylesheet. If this isn't possible, you can also try introducing a :not()
to prevent the other rule from applying, this is especially relevant for different element states (:hover
, :active
, [checked]
or [disabled]
). However, never try to increase the selector of the rule you are adding as it can easily become hard to understand.
Finally, once you have checked all the things above, you can permit yourself to use !important
along with a comment why it is needed.
Before adding new CSS variables, please consider the following questions:
currentcolor
keyword?currentcolor
will prevent repetition of the value and it is usually good practice to do so.In general, it's good to first think of how some CSS could be written cleanly without the CSS variable(s) and then think of how the CSS variable could improve that CSS.
Do this:
xul|tab:hover { background-color: var(--in-content-box-background-hover); }
Not this:
#certificateErrorDebugInformation { background-color: var(--in-content-box-background-hover); }
inline-start
/inline-end
rather than left
/right
.margin-inline-start: 3px;
instead of margin-left: 3px
.inset-inline-start
/inset-inline-end
.float
: inline-start|inline-end
can be used instead of float: left|right
.border-{top/bottom}-{left/right}-radius
are border-{start/end}-{start/end}-radius
:-moz-locale-dir(ltr|rtl)
(for XUL files) or :dir(ltr|rtl)
(for HTML files).padding
: 0 3px 4px;
instead of padding: 0 3px 4px 3px;
. This makes it more obvious that the padding is symmetrical (so RTL won't be an issue).Note: See CSS Logical Properties and Values for more information.
To test for RTL layouts, you can go to about:config
and set intl.uidirection
to -1
.
Firefox supports many different platforms and each of those platforms can contain many different configurations:
browser/
directory contains styles specific to Firefoxtoolkit/
directory contains styles that are shared across all toolkit applications (Thunderbird and SeaMonkey)Under each of those two directories, there is a themes
directory containing 4 sub-directories:
shared
linux
osx
windows
The shared
directories contain styles shared across all 3 platforms, while the other 3 directories contain styles respective to their platform.
For new CSS, when possible try to privilege using the shared
directory, instead of writing the same CSS for the 3 platform specific directories, especially for large blocks of CSS.
The following directories also contain CSS:
browser/base/content/
toolkit/content/
These directories contain content CSS, that applies on all platforms, which is styling deemed to be essential for the browser to behave correctly. To determine whether some CSS is theme-side or content-side, it is useful to know that certain CSS properties are going to lean one way or the other: color - 99% of the time it will be theme CSS, overflow - 99% content.
99% theme | 70% theme | 70% content | 99% content |
---|---|---|---|
font-*, color, *-color, border-*, -moz-appearance [1] | line-height, padding, margin | cursor, width, max-width, top, bottom [2], etc | overflow, direction, display, *-align, align-*, *-box-*, flex-*, order |
If some CSS is layout or functionality related, then it is likely content CSS. If it is esthetics related, then it is likely theme CSS.
When importing your stylesheets, it's best to import the content CSS before the theme CSS, that way the theme values get to override the content values (which is probably what you want), and you're going to want them both after the global values, so your imports will look like this:
<?xml-stylesheet href="chrome://global/skin/global.css" type="text/css"?> <?xml-stylesheet href="chrome://browser/content/path/module.css" type="text/css"?> <?xml-stylesheet href="chrome://browser/skin/path/module.css" type="text/css"?>
[1] -moz-appearance is tricky. Generally, when specifying -moz-appearance: foo; you're giving hints as to how something should act, however -moz-appearance: none; is probably saying 'ignore browser preconceptions - I want a blank sheet', so that's more visual. However -moz-appearance values aren't implemented and don't behave consistently across platforms, so idealism aside -moz-appearance should always be in theme CSS.
[2] However there is probably a better way than using absolute positioning.
For common areas of the Firefox interface (panels, toolbar buttons, etc.), mozilla-central often comes with some useful CSS variables that are adjusted with the correct values for different platform configurations, so using those CSS variables can definitively save some testing time, as you can assume they already work correctly.
Using the currentcolor
keyword or inheriting is also good practice, because sometimes the needed value is already in the color or on the parent element. This is especially useful in conjunction with icons using -moz-context-properties: fill;
where the icon can adjust to the right platform color automatically from the text color. It is also possible to use currentcolor
with other properties like opacity
or fill-opacity
to have different opacities of the platform color.
On Windows high contrast mode, in the content area, Gecko does some automatic color adjustments regarding page colors. Part of those adjustments include making all box-shadow
invisible, so this is something to be aware of if you create a focus ring or a border using the box-shadow
property: consider using a border
or an outline
if you want the border/focus ring to stay visible in high-contrast mode. An example of such bug is bug 1516767.
Another adjustment to be aware of is that Gecko removes all the background-image
when high contrast mode is enabled. Consider using an actual <img>
tag (for HTML documents) or list-style-image
(for XUL documents) if rendering the image is important.
If you are not using Windows, one way to test against those adjustments on other platforms is:
The automatic adjustments previously mentioned only apply to pages rendered in the content area. The chrome area of Firefox uses colors as authored, which is why using pre-defined variables, currentcolor
or inheritance is useful to integrate with the system theme with little hassle.
If not, as a last resort, using system colors also works for non-default Windows themes or Linux. In general, the following colors are used:
-moz-Field
: textbox or field background colors, also used as the background color of listboxes or trees.-moz-FieldText
: textbox or field text colors, also used as the text color of listboxes or trees.-moz-Dialog
: window or dialog background color.-moz-DialogText
: window or dialog text color.GrayText
: used on disabled items as text color. Do not use it on text that is not disabled to desemphsize text, because it does not guarantee a sufficient contrast ratio for non-disabled text.ThreeDShadow
: Used as border on elements.ThreeDLightShadow
: Used as light border on elements.Using the background/text pairs is especially important to ensure the contrast is respected in all situations. Never mix custom text colors with a system background color and vice-versa.
Note that using system colors is only useful for the chrome area, since content area colors are overridden by Gecko anyway.
Do this:
@media (-moz-mac-yosemite-theme: 0) {
Not this:
@media not all and (-moz-mac-yosemite-theme) {
It is better to put the most common configuration (latest version of an OS, or default theme for example) outside of the media query. In the following example, -moz-mac-yosemite-theme
targets macOS 10.10 and higher, so it should be privileged over the styling for macOS 10.9.
Do this:
@media (-moz-mac-yosemite-theme: 0) { #placesList { box-shadow: inset -2px 0 0 hsla(0,0%,100%,.2); } }
Not this:
#placesList { box-shadow: inset -2px 0 0 hsla(0,0%,100%,.2); } @media (-moz-mac-yosemite-theme) { #placesList { box-shadow: none; } }
Firefox comes built-in with 3 themes: default, light and dark. The built-in light/dark themes are a bit special as they load the compacttheme.css
stylesheet. In addition to this, Firefox supports a variety of WebExtension themes that can be installed from AMO. For testing purposes, here is an example of a WebExtension theme.
currentcolor
/inheritance is again a good idea for theme support.compacttheme.css
unless that CSS isn't supposed to affect WebExtension themes.:-moz-lwtheme-brighttext
: dark window frame.:root[lwt-toolbar-field-brighttext]
: dark address bar and searchbar.:root[lwt-popup-brighttext]
: dark arrow panels and autocomplete panels.:root[lwt-sidebar-brighttext]
: dark sidebars.For clarity, CSS variables that are only used when a theme is enabled have the --lwt-
prefix.
Mixing XUL flexbox and HTML flexbox can lead to undefined behavior.
When targeting the root element of a page, using :root
is the most performant way of doing so.
See Performance best practices for Firefox front-end engineers for more information about this.
When convenient, avoid setting the opacity
property on text as it will cause text to be aliased differently.
It's recommended to use SVG since it keeps the CSS clean when supporting multiple resolutions. See the SVG Guidelines for more information on SVG usage.
However, if only 1x and 2x PNG assets are available, you can use this @media
query to target higher density displays (HDPI):
@media (min-resolution: 1.1dppx)