|
1 | 1 | # CSS Coding Standards |
2 | 2 |
|
3 | | -Like any coding standard, the purpose of the WordPress CSS Coding Standards is to create a baseline for collaboration and review within various aspects of the WordPress open source project and community, from core code to themes to plugins. Files within a project should appear as though created by a single entity. Above all else, create code that is readable, meaningful, consistent, and beautiful. |
| 3 | +Like any coding standard, the purpose of the WordPress CSS Coding Standards is to create a baseline for collaboration and review within various aspects of the WordPress open source project and community, from core code to themes and plugins. Files within a project should appear as though created by a single entity. Above all else, create code that is readable, meaningful, consistent, and beautiful. |
4 | 4 |
|
5 | 5 | Within core stylesheets, inconsistencies will often be found. We are working on addressing these and make every effort to have patches and commits from this point forward follow the CSS coding standards. More information on the above and contributing to UI/front-end development will be forthcoming in a separate set of guidelines. |
6 | 6 |
|
@@ -123,7 +123,7 @@ Above all else, choose something that is meaningful to you and semantic in some |
123 | 123 | - Colors and Typography |
124 | 124 | - Other |
125 | 125 |
|
126 | | -Things that are not yet used in core itself, such as CSS3 animations, may not have a prescribed place above but likely would fit into one of the above in a logical manner. Just as CSS is evolving, so our standards will evolve with it. |
| 126 | +Things that are not yet used in core itself, such as CSS3 animations, may not have a prescribed place above but likely would fit into one of the above in a logical manner. Just as CSS is evolving, our standards will evolve with it. |
127 | 127 |
|
128 | 128 | Top/Right/Bottom/Left (TRBL/trouble) should be the order for any relevant properties (e.g. `margin`), much as the order goes in values. Corner specifiers (e.g. `border-radius-*-*`) should be ordered as top-left, top-right, bottom-right, bottom-left. This is derived from how shorthand values would be ordered. |
129 | 129 |
|
@@ -157,7 +157,7 @@ Example: |
157 | 157 |
|
158 | 158 | Updated on 2014-02-13, after [[27174](https://core.trac.wordpress.org/changeset/27174)]: |
159 | 159 |
|
160 | | -We use [Autoprefixer](https://github.com/postcss/autoprefixer) as a pre-commit tool to easily manage necessary browser prefixes, thus making the majority of this section moot. For those interested in following that output without using Grunt, vendor prefixes should go longest (-webkit-) to shortest (unprefixed). All other spacing remains as per the rest of standards. |
| 160 | +We use [Autoprefixer](https://github.com/postcss/autoprefixer) as a pre-commit tool to easily manage necessary browser prefixes, thus making the majority of this section moot. For those interested in following that output without using Grunt, vendor prefixes should go longest (-webkit-) to shortest (unprefixed). All other spacing remains as per the rest of the standards. |
161 | 161 |
|
162 | 162 | ```css |
163 | 163 | .sample-output { |
|
0 commit comments