New rule: indentation about stylelint

[jeddy3]

There might be a bigger (and more contentious) question here about what should and shouldn't be in core. And if there is stuff outside of core, how do users plug that stuff in?

The indention options are complex because I think it is trying to support an indentation method where rule-sets are indented based on their selector. The example below includes the options for indenting rule-sets with a pseudo class by two tabs, bem elements by one and bem modifiers by none etc ...

{
  "indentation": {
    "default": 1,  // e.g. "1" tab or "2" spaces
    "char": "\t", // probably better to have a keyword here e.g. "tab"|"space"

    "block": true, // indent blocks by the default amount and char.
    "rule-set-by-selector-class-bem-element": true, // same with bem elements
    "rule-set-by-selector-class-bem-modifier": false, // not with bem modifers
    "rule-set-by-selector-pseudo-classes": 2, // indent with 2 of the char e.g. tabs
    "rule-set-by-selector-pseudo-element": true // default amount and char
  }
}

To support a method like:

.A { } 
  .A-element { } 
    .A-element:pseudo-class { }
.A--modifier { }

I can see the advantages to such an approach, but should this be in core? Unlike everything else we've done so far it does not feel timeless i.e. if BEM is ever replaced by a different methodology this will become redundant. Whereas everything else has been about the CSS language itself, and not an architecture methodology. Does it feel like a good candidate for a plugin or something similar?

If the code in core didn't tackle the bem stuff then I think the options could become:

{
  "indentation": {
    "quantity": 1,  // e.g. "2" tab or "4" spaces
    "char": "tab"|"space"
    "block": "always"|"never", // not sure if we need these
    "value": "always"|"never" // too complicated?
  }
}

So, given:

{
  "indentation": {
    "quantity": 2,
    "char": "space",
    "block": "always",
    "value": "always"
  }
}

This is valid:

a {
  color: pink;
  background-image: url(x.jpg),
    url(y.jpg),
    url(z.jpg);
  height: 0;
}

The scsslint implementation, csscomb one and the one in eslint for supporting something simpler like this looks pretty complicated to begin with.

What are you two's thoughts on getting something similar to work in core first before expanding out into, perhaps, plugins and the like?

[davidtheclark]

Yes, I think that building BEM into the core is too much. I say we leave it for a plugin.

I guess "block": "always"|"never" is important, because it means some people could do:

@media print {

a { color: pink; }

b { color: orange; }

}

Right?

"value" makes sense to me as an option, too --- but I guess I'm wondering if anybody would ever set it to "never"? This would be pretty nasty ...

a {
  color: pink;
  background-image: url(x.jpg),
  url(y.jpg),
  url(z.jpg);
  height: 0;
}

[davidtheclark]

Another possibility that came to mind, a little bit nonstandard but maybe fitting the scenario, would be we have boolean options like ignoreBlock, ignoreValue, ignoreSingleLine. These would be simpler than an always/never pair of keywords and might get the job done, right?

[MoOx]

Not a fan of the ignore* approach.

We can have default value for the details, cause we can easily agree that most people will indent block in block and value like in your background-image example.

I must agree that having "bem" seems weird seems it's not a word from the css vocabulary.
That said I like the idea of handling a such case in core (maybe not for the start).
What about something like "class-children" and "class-variation" ? (with a way to define this patterns somewhere so people can define how to find children (eg: bem elements) and how to find variations (eg: bem modifier).

For a start we can go with minimal options. I like how eslint differentiate tab from space. Since people are unlikely to use multiple tab, eslint have one parameter to define "tab" or a number of spaces (which make sense to me).

[davidtheclark]

I agree that multiple tabs is not a necessary option.

So how about this to start:

{
  "indentation": {
    "space": 2, // or 4 or "tab"
    "block": "always", // or "never"
    "value": "always" // or "never"
  }
}

Or "space" could be "indent"?

[davidtheclark]

I got a start on this rule in the branch "indentation" (f158562), which I pushed so you could look at it (but of course I don't want to merge it into master yet): https://github.com/stylelint/stylelint/tree/indentation

(I have not yet messed with the block or value options, and have only created enough test cases to see if I'm on the right track with the rule's implementation.)

I think one of the most significant aspects of doing this one right will be in accumulating good, thorough test cases. (Notice that the ability to use ES6 template literals makes writing these test cases nice, without the need for external fixtures!) So it would be really helpful if anybody could help churn out test cases, either adding to the branch or just posting them here.

[MoOx]

What you did seems pretty good to me.

[jeddy3]

What you did seems pretty good to me.

Agreed. It's fantastic to see you tackle so many rules in a just a week!