Skip to content

Commit 59a08ab

Browse files
authored
Propose naming scheme for styling files (#752)
1 parent 5658c4e commit 59a08ab

File tree

1 file changed

+65
-0
lines changed

1 file changed

+65
-0
lines changed

lib/Styles/CONTRIBUTING.md

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# Contributing
2+
3+
## Padding, Margins, and Border Radii
4+
5+
The base grid unit should be 3px. Sometimes widgets with borders will be "off by one" to align visually.
6+
7+
Border radii should increase as they nest where reasonable. The largest border radii is 9px, used by windows. Popovers and On Screen Displays use a border radius half that.
8+
9+
## Levels and Dark Style Theory
10+
11+
Widget backgrounds are styled according to "level" or "elevation". Elements gets darker the further away they are in interaction hierarchy. For example, buttons are lightest and containers like sidebars are darkest. Widgets in dark style should follow this same progression from lightest in front to darkest in back, and not simply be inverted.
12+
13+
## A11y
14+
15+
* Colors should pass WCAG AA contrast requirements
16+
* Where possible, use the `rem()` function so that padding, margins, etc scale when users' adjust text size in system settings
17+
18+
## Focus, Hover, Backdrop, etc
19+
20+
Accent should be used to indicate the current area of focus. When selected, but not focused, use nuetral highlights.
21+
22+
Focused widgets should be highlighted with a ring where possible.
23+
24+
Backdrop states should use nuetral color and reduced depth. Contrast can be reduced in some cases, but be mindful of WCAG requirements even for backdrop elements.
25+
26+
## File Name Conventions
27+
28+
A file should be named after the CSS node it addresses. For instance,
29+
the file addressing `GtkButton` and its descendants would use the file name
30+
`Button.scss`. As a `GtkCheckButton` has a different CSS node (`checkbutton`),
31+
it would be placed into it's own file, named `CheckButton.scss`. If you are
32+
unsure of what node something uses, it's node can be found under the "Name"
33+
column of the "CSS Nodes" tab of the "Objects" page in Gtk Inspector.
34+
35+
For nodes that are rarely used outside of the context of a parent node (i.e.
36+
`check` is rarely used outside of the context of `checkbutton`), they can be
37+
placed in the parent node file.
38+
39+
CSS style classes, such as `Granite.CssClass.CARD`, should be placed in a
40+
`_classes.scss` file under the relevant library directory (e.g. Granite, Gtk,
41+
Adw).
42+
43+
## Testing Changes
44+
45+
Apps may need to be restarted or the system stylesheet may need to be changed before installed changes take effect.
46+
47+
You can also test changes live with Gtk Inspector. Make sure you have Gtk development libraries installed, then enable the inspector shortcut:
48+
49+
```bash
50+
apt install libgtk-4-dev
51+
gsettings set org.gtk.gtk4.Settings.Debug enable-inspector-keybinding true
52+
```
53+
54+
Open an app you wish to test your changes on. Open Gtk Inspector with the keyboard shortcut Shift + Ctrl + D, then navigate to the tab "CSS" in Gtk4. Your changes here will take immediate effect on the focused app. You may have to toggle the "pause" button in the top left before changes take effect.
55+
56+
## Proposing Changes
57+
58+
Changes should be tested against the following apps to avoid breakage:
59+
* Gtk Demo
60+
* Gtk Widget Factory
61+
* Granite Demo
62+
63+
Avoid hardcoding palette colors where possible. `accent_color` should be used for any hightlights or selection states that should adapt to users' color preferences. Use semantic variables like `warning_color` where possible since these are contrast checked for dark and light styles.
64+
65+
Please provide before and after screenshots of your change where applicable

0 commit comments

Comments
 (0)