Sort-order shortcuts

[kizu]

There is one thing I don't like in messing with sort-order option. It's that I need to use the existing example of sort-order, 'cause it contains all the props and if I would write this option from scratch I would surely forget something etc.

What I'd want is this option to be smart enought to understand such way of adding it:

{
    "sort-order": [
        [
            "position"
        ],
        [
            "width",
            "height",
            "padding",
            "border",
            "margin"
        ],
        [
            "font"
        ],
        [
            "color",
            "background"
        ]
    ]
}

This example should be treated as something like that:

{
    "sort-order": [
        [
            "position",
            "z-index",
            "top",
            "right",
            "bottom",
            "left"
        ],
        [
            "width",
            "min-width",
            "max-width",
            "height",
            "min-height",
            "max-height",
            "padding",
            "padding-top",
            "padding-right",
            "padding-bottom",
            "padding-left",
            "border",
            "border-collapse",
            "border-width",
            "border-style",
            "border-color",
            "border-top",
            "border-top-width",
            "border-top-style",
            "border-top-color",
            "border-right",
            "border-right-width",
            "border-right-style",
            "border-right-color",
            "border-bottom",
            "border-bottom-width",
            "border-bottom-style",
            "border-bottom-color",
            "border-left",
            "border-left-width",
            "border-left-style",
            "border-left-color",            
            "margin",
            "margin-top",
            "margin-right",
            "margin-bottom",
            "margin-left"
        ],
        [
            "font",
            "font-family",
            "font-size",
            "font-weight",
            "font-style",
            "font-variant",
            "font-size-adjust",
            "font-stretch",
            "font-effect",
            "font-emphasize",
            "font-emphasize-position",
            "font-emphasize-style",
            "font-smooth",
            "line-height"
        ],
        [
            "color",
            "background",
            "filter:progid:DXImageTransform.Microsoft.AlphaImageLoader",
            "background-color",
            "background-image",
            "background-repeat",
            "background-attachment",
            "background-position",
            "background-position-x",
            "-ms-background-position-x",
            "background-position-y",
            "-ms-background-position-y",
            "-webkit-background-clip",
            "-moz-background-clip",
            "background-clip",
            "background-origin",
            "-webkit-background-size",
            "-moz-background-size",
            "-o-background-size",
            "background-size",
        ]
    ]
}

There could be a lot of nuances, but the main rules could be:

1. There should be groups of properties like width, max-width, min-width or the position above, so when you use one of them in settings and other properties from that list are not listed in config, they should go where the one of them was defined.
2. There should be automatic groups like for the prefixed properties (it would make sense not to mention them in the config — user don't need to know which browsers support which prefixes), however if user wants, he could move some of the prefixes here and there, so this should be, again, a default.
3. If only few properties are defined in a config, those properties should go at the start of the block and all the other stuff would go after them (as it works in the original CSSComb, I guess).
4. This behaviour should be a default one, but there could be a satellite option to prevent the use of the default groups, for those control freaks who don't like them.
5. There could be, actually, some shortcuts lists embedded in csscomb, so you could call them just by using a keyword. For example, the config could consist only from "sort-order": "yandex", this way the build-in group yandex would be used etc.

While this is not that trivial and would need to have some defaults embedded in csscomb.js, this would be really handy and would make creating and maintaining such sort lists really easy and straightforwad.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1519080-sort-order-shortcuts?utm_campaign=plugin&utm_content=tracker%2F214563&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F214563&utm_medium=issues&utm_source=github).

[mishanga]

Agree.
Sometime...

[kizu]

After some thinking, I think this is how this feature should be implemented.

Defining groups

There should be some groups defined by default in CSSComb.js, this would allow users to write really small and maintainable sort-order option.

I'd say, it could be sort-order-group option that would have defaulted value like this:

{
  "positioning": [
    "position",
    "z-index",
    "top",
    "right",
    "bottom",
    "left"
  ],
  "box-model": [
    "box-sizing",
    "width",
    "min-width",
    "max-width",
    "height",
    "min-height",
    "max-height",
    "margin",
    "margin-top",
    "margin-right",
    "margin-bottom",
    "margin-left",
    "padding",
    "padding-top",
    "padding-right",
    "padding-bottom",
    "padding-left"
  ]
}

etc.

The important things:

• this list would have names for groups (that could later used in sort-order in some way);
• the order inside each group is not important — it won't impact on anything (questionable, see below);
• there won't be any prefixed properties if there is an unprefixed variant — as the order won't matter in those groups, we could throw them out and check things for them automatically (*maybe we should move the order of prefixed properties to another option, so we won't clutter the sort-order with those (except for the ones we need to go after unprefixed ones)? This would also remove the need to *).

While there would be a predefined groups, they would be a bit optionated, but they won't influence on anything unless you would use them explicitly. And people could (if they would want) assign anything they would like to this option.

Using groups and values inside of them

Groupings could be used in sort-order value in a very simple fashion: you just append ... to any property name or use the group name with the ... like positioning..., and CSSComb would expand such group to the one that have this name or have this property inside.

Moreover, such group would take all the properties that start with its name, so margin... used in sort-order would take both margin and all the margin-… properties.

As the order in groups in not important, we should output all the properties got from the group in the order they were in the source (this is arguable, actually — should be use the order in the groups? This would be much easier than to mix the strict order with the loose one got from groups)

This could sound a bit complicated, but the logic behind this is really easy.

Expanding the sort-order using defined groups

We should look at this option's value at the time we parse the sort-order's value, expanding all the things in run-time.

1. For the start we should filter out the groups by removing all the properties that were defined in the sort-order option.
2. Then, for each group call in the sort-order we should find the first groups that would either have the name equal to the called group, or would contain the property that starts with this name.
3. Then we replace the group call in sort-order with all the properties we get from the group (if we would use the order, it is easy, if the order should have the same order as in the source, we should make some extra work).
4. Profit.

This means, the groups are only expanding existing sort-order option and it won't break anything as it introduces the syntax for the groups that is based on the existing one.

This feature would allow us to write the sort-order in an easy, understandable and maintainable way.

Questions left

1. Should the order inside the group mean anything? At first I thougt it shouldn't, but when thinking on the implementation, it becomes obvious that it would be really easier to make it count.
2. Should there be subgroups and calls to them inside groups? This way we could split big groups to smaller ones, so more sort-order variants could be explained using groups.

Example usage of the groups

Example of sort-order from csscomb.json using groups could look like this (not everything is moved to groups, but you get the idea — see how much readable it is):

{
    "sort-order": [
        [
            "font...",
            "line-height"
        ],
        [
            "position...",
        ],
        [
            "display",
            "visibility",
            "float",
            "clear",
            "overflow...",
            "-ms-overflow-...",
            "clip",
            "zoom",
            "flex...",
        ],
        [
            "box-sizing",
            "width...",
            "height...",
            "margin...",
            "padding...",
        ],
        [
            "table...",
            "list-style...",
        ],
        [
            "content...",
            "resize",
            "cursor",
            "user-select",
            "nav-...",
            "transition...",
            "transform...",
            "animation...",
            "text-align...",
            "vertical-align",
            "white-space",
            "text-decoration",
            "text-emphasis...",
            "text-indent",
            "text-justify",
            "letter-spacing",
            "word-spacing",
            "-ms-writing-mode",
            "text-...",
            "word-wrap",
            "word-break",
            "-ms-word-break",
            "tab-size",
            "hyphens",
            "pointer-events"
        ],
        [
            "opacity...",
            "-ms-interpolation-mode",
            "color",
            "border...",
            "border-top...",
            "border-right...",
            "border-bottom...",
            "border-left...",
            "border-radius...",
            "border-image...",
            "outline...",
            "background...",
            "background-size",
            "box-decoration-break",
            "shadows..."
        ]
    ]
}

[jdalton]

Hi All!

I'm closing this because unless a PR is created it won't likely be addressed.
If you feel strongly about this request I encourage you to dig in and submit a PR 😸