92 | `;
93 | }
94 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | ## Contributing to this database
2 |
3 | Pull requests are the most helpful contributions.
4 |
5 | I love folks who can add missing features and keep existing features up to date.
6 | A new feature only needs a **title**, **id**, **description**, and a link to
7 | its **specification**.
8 |
9 | Non-CSSWG members can still update CSS features by including **citations** to
10 | public notes that show how the CSSWG is advancing a feature. If you need
11 | further clarification, read [why we are doing this](#why-are-we-doing-this).
12 |
13 | ### Updating a feature
14 |
15 | Is one of these CSS features out-of-date? Open [`cssdb.settings.json`] and find
16 | the feature you want to update. It’s a JSON file, so make changes directly to
17 | the file, commit it, and then [make a pull request](#making-a-pull-request).
18 |
19 | ### Adding a new feature
20 |
21 | Is a CSS feature not listed here? Add the feature to [`cssdb.settings.json`].
22 | Again, it’s a JSON file, so make changes directly to the JSON, commit it, and
23 | then [make a pull request](#making-a-pull-request).
24 |
25 | ### Making a Pull Request
26 |
27 | For best results, be sure your contributions make sense to everyone else. If
28 | you’re unfamiliar with git, consider the following workflow.
29 |
30 | 1. To begin; [fork this project] and then clone your fork locally
31 | ```bash
32 | # Clone your fork of this project
33 | git clone git@github.com:YOUR_USER/cssdb.git
34 |
35 | # Navigate to your fork of this project
36 | cd cssdb
37 |
38 | # Install the tools necessary for testing this project
39 | npm install
40 |
41 | # Assign the original repo to a remote called "upstream"
42 | git remote add upstream git@github.com:csstools/cssdb.git
43 | ```
44 |
45 | 2. Create a branch for your feature or fix:
46 | ```bash
47 | # Move into a new branch for your feature
48 | git checkout -b feature/thing
49 | ```
50 | ```bash
51 | # Move into a new branch for your fix
52 | git checkout -b fix/something
53 | ```
54 |
55 | 3. If your code follows our practices, then push your feature branch:
56 | ```bash
57 | # Test your code
58 | npm test
59 | ```
60 | ```bash
61 | # Push the branch for your new feature
62 | git push origin feature/thing
63 | ```
64 | ```bash
65 | # Or, push the branch for your update
66 | git push origin update/something
67 | ```
68 |
69 | ---
70 |
71 | ## Advanced Usage: How the JSON file looks
72 |
73 | The only fields you’ll see in [`cssdb.settings.json`] are, in order:
74 |
75 | - `id`: the feature shortname, similar to a specification [Shortname].
76 | - `title`: the name of the feature.
77 | - `description`: a brief description of the feature.
78 | - `specification`: a link to the specification for the feature.
79 | - `stage`: the current [stage](README.md#staging-process) of the feature; where
80 | + `0` means **Stage 0** — *Aspirational*,
81 | + `1` means **Stage 1** — *Enthusiastic*,
82 | + `2` means **Stage 2** — *Experimental*,
83 | + `3` means **Stage 3** — *Allowable*,
84 | + `4` means **Stage 4** — *Embraced*,
85 | + `5` means **Stage 5** — *Standardized*, and
86 | + `-1` means **Rejected**.
87 | - `polyfills`: a list of polyfills used to simulate the feature; each including
88 | + `type`: the type of polyfill (e.g. *PostCSS*, *JS Library*), and
89 | + `link`: the URL to the repository for the polyfill.
90 |
91 | All contributions must follow the existing syntax and style of the JSON file,
92 | which;
93 |
94 | 1. Exists as `cssdb.settings.json`, and;
95 | 2. Includes at least the required fields; **title**, **description**,
96 | **specification**, and **stage** (which is `0` if you don’t know it).
97 |
98 | Did you write the specification you are submitting? It must;
99 |
100 | 1. Describe what the feature does in as few words as possible.
101 | 2. Describe why the feature exists in as few words as possible.
102 | 3. Describe how the feature and its parts operate as clearly and completely as
103 | possible.
104 |
105 | If you’re changing the **stage** of a feature, be sure to include a link along
106 | with your PR to prove the new position.
107 |
108 | ---
109 |
110 | ## Join the CSSWG
111 |
112 | Passionate and informed developers should consider joining the CSSWG. Read the
113 | [instructions for joining the CSSWG]. This is a very difficult to actually
114 | accomplish, so I welcome pull requests to update this section with some
115 | beginner-friendly instructions.
116 |
117 | ### Why are we doing this?
118 |
119 | The CSSWG doesn’t follow the [TC39 process]. How they operate [in theory](https://www.w3.org/Style/CSS/specs.en.html) versus [in real life](https://fantasai.inkedblade.net/weblog/2011/inside-csswg/) is unclear, and
120 | browsers
121 | [don’t necessarily follow their process anyway](https://www.chromestatus.com/feature/5753701012602880),
122 | so we have to discern what’s really going on ourselves. If we didn’t, we
123 | probably wouldn’t need this repository.
124 |
125 | [`cssdb.settings.json`]: cssdb.settings.json
126 | [fork this project]: fork
127 | [instructions for joining the CSSWG]: https://www.w3.org/2004/01/pp-impl/32061/instructions
128 | [staging process]: README.md#staging-process
129 | [TC39 process]: https://thefeedbackloop.xyz/tc39-a-process-sketch-stages-0-and-1/
130 | [Section Heading ID]: https://tabatkins.github.io/bikeshed/#section-links
131 | [Shortname]: https://tabatkins.github.io/bikeshed/#metadata-shortname
132 |
--------------------------------------------------------------------------------
/public/images/css-tools.svg:
--------------------------------------------------------------------------------
1 |