palantir / stylelint-config-palantir Goto Github PK

not sure what work is necessary here, but our current peerDep is ^7.9.0.

Opening this issue as a place to discuss CSS property ordering.

Our property ordering is claimed to be loosely based on the "concentric css" model described here: https://rhodesmill.org/brandon/2011/concentric-css/. This model is based on css available in 2011, which was a much different place than where we stand today. The model roughly lays out css in a way that describes the box "from the outside in" (based on the comments noted on the linked page):

1. how does this box interact with elements around it
2. visibility of the box
3. intrinsic height and width definitions outside of the box's content
4. intrinsic height and width definitions of the content
5. styles that affect internals of the box (like color)

This model is no longer semantically meaningful with new css patterns, like flex containers. There are a number of flex properties which affect different behaviors of an element. If we want to maintain the rough semantics of "outside in", for example, flex should be defined under 1), since it affects how this element interacts with its parent (how it grows, shrinks, and the effective intrinsic size), but flex-direction should be defined under 5), since it affects how its children are laid out (a style internal to this element). However, it's obviously not ideal to have flex and flex-direction be defined so far apart from one another while reading. Currently, we arbitrarily decide to group all flex properties at the start. Since we're already breaking the semantics defined by the concentric css model, it can be confusing knowing where to find a specific property or type of property.

Additionally, new css properties are constantly being added and supported. CSS grid level 2 is nearly supported, so our property-ordering will need to be updated to support subgrids soon as well. Lack of definition will place the property below all those defined, creating further confusion about where to find a property (you now have to know which properties are defined in our spec).

I propose standardizing on alphabetical ordering, since alphabetization is a property that will be resilient to future CSS spec levels. Modern css specs already largely group rules in a way that consistent with alphabetization (e.g. all flex related rules are prefixed with flex) -- it's only a few old rules that would be negatively affected (like top/right/bottom/left).

Could we add stylelint's length-zero-no-unit rule? Units are just cruft on 0 values in CSS.

i.e.

Disallow

a { margin-top: 0px; }

Allow

a { margin-top: 0; }

See the link above for all the nuance.

Latest stylelint has a few warnings about some future deprecation rules and it's now also recommended to use hudochenkov/stylelint-order.

See stylelint/stylelint#5133 (comment), https://stylelint.io/user-guide/rules/list/no-invalid-position-at-import-rule/

no-invalid-position-at-import rule is now enabled by default, but this doesn't work for Sass files that use the @use syntax unless you configure the following override:

    "no-invalid-position-at-import-rule": [true, {
        "ignoreAtRules": ["use"]
    }],

this should be configured out of the box. maybe stylelint-config-standard-scss does it for us...?

We want to ban custom color declarations and use exclusively Blueprint colors rather than just hex-format color declarations. This rule: https://github.com/stylelint/stylelint/tree/master/src/rules/declaration-property-value-whitelist would be a good way to restrict the set of allowed color properties.

(Not sure about how this works given that this repo is open-source but Blueprint is not)