Enforce a specific ordering of attributes

[jdforrester]

"declaration-block-properties-order": [ "content", "background-image", "backg
round-origin", "background-position", "background-repeat", "background-size", "color"
, "list-style", "filter", "opacity", "display", "clip", "overflow", "visibility", "fl
oat", "clear", "position", "top", "left", "bottom", "right", "z-index", "box-sizing",
 "min-width", "max-width", "width", "height", "outline", "margin", "padding", "border
", "border-radius", "box-shadow", "direction", "hyphens", "font-family", "font-size",
 "font-weight", "line-height", "text-align", "text-decoration", "text-overflow", "tex
t-shadow", "text-transform", "vertical-align", "white-space", "cursor", "zoom", "anim
ation", "transition" ],

[Nikerabbit]

Where does this order come from? Csscomb has some presets: https://github.com/csscomb/csscomb.js/tree/master/config

[edg2s]

...or don't do this. It has little benefit (selector lists are usually not that long so keeping them ordered doesn't make them more readable), and will just waste developer time fixing more "errors".

[Nikerabbit]

If the fixing can be automated, I don't see it as a problem. The benefits are not that big for well written CSS because this does not really affect inside-a-block readability, but for less than well written CSS it is helpful, because it makes comparing separate blocks easier.

[Volker-E]

We've had some conversation about that already on the CSS Coding Conventions talk page including a proposal from my years of working with CSS. Ability to scan over selectors quickly and find the most important (most often used) properties, like colors, display, position easily or orientate in box model definition by not changing order of (from outside to inside) margin, padding and border constantly from one selector to another are bringing –when working in an environment like ours– strong advantages in my opinion.

[edg2s]

If the fixing can be automated it is less objectionable - although I maintain it is exceptional for a class to have more than rules that can be scanned easily, so it still seems more trouble that is it worth.

[Nikerabbit]

csscomb can automate it, but I have no experience on stylelint.

[Volker-E]

I agree, that not-automated ordering might seem like a burden or even out of scope. Maybe it would be preferable as a build step after developer has ended work. For completely new projects it would make sense though to have a guideline (and a possible enforcement). As I'm spending a good amount of time in CSS/Less(/SCSS/Post-processor enhanced) files, I'm personally convinced, that certain property order is a time-saver.

[edg2s]

Users may also want to group non adjacent rules for clarity, consider: // Reduce width for border width: 98px; border: 2px;

[jdforrester]

(Upstream has deprecated this from core and moved into a plugin.)

[Volker-E]

With 'stylelint-order' a maintained and powerful stylelint plugin existst. Provided https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/483638/ as example. It has stylelint autofix capabilities, although the example given by @edg2s above shows, why autofix should be used with a grain of salt. As somebody who spends a good time in CSS, I'd be still inclined to have some order of properties for cleaner, better readable CSS structure.

[edg2s]

Per discussion this might be useful an optional plugin (e.g. wikimedia/ordered) that could be used by CSS-heavy projects such as OOUI, but shouldn't be a default on projects where there aren't enough properties for it to increase readability so it just adds developer burden. I would suggest just using custom rules in OOUI to begin with, then we can extract to a plugin if there is demand elsewhere.

[danisztls]

csscomb is not maintained since 2019

Alternatives (besides stylelint-order):

• https://github.com/Siilwyn/css-declaration-sorter/
• https://github.com/hudochenkov/postcss-sorting/

[Volker-E]

Thanks @danisztls. Note that we've already added and are actively using stylelint-order to Codex since my last comment here.