Turn stylelint-config-standard into an actual standard

[corysimmons]

It favours flexibility over strictness for things like multi-line lists and single-line rulesets, and tries to avoid potentially divisive rules.

Is fine and all, but it's not a standard.

Flexible != Standard

You should rename this repo to stylelint-config-flexible and create an actual standard.

That's kind of the whole point behind linting anything to enforce strict rules for code quality.

Please take a page out of https://github.com/feross/standard handbook and become the one standard to rule them all.

[corysimmons]

That said, @dan-gamble has some good looking work on property ordering.

https://github.com/onespacemedia/project-template/blob/develop/%7B%7Bcookiecutter.repo_name%7D%7D/stylelint.config.js

I think combining what you've got already with some nice property grouping/ordering (alphabetical isn't useful) would be a good place to start.

[dan-gamble]

I'd be all for trying to enforce a standard like feross has done with JS (We use that where we work as we use Python and realise how useful PEP8 is)

Wouldn't mind contributing towards sorting out a CSStandard!

[MoOx]

imo the name is fine. The intention of ths config is good. There is no real standard for CSS. Even feross standard is an opininated config. So maybe you should just discuss about enhancement instead of changing a name. Or maybe, it can be renamed to something like "stylelint-config-recommended" like eslint:recommended.

[corysimmons]

It favours flexibility over strictness for things like multi-line lists and single-line rulesets, and tries to avoid potentially divisive rules.

Okay, my enhancement is remove that line and add some property sorting by group and then alphabetical.

[corysimmons]

https://github.com/stylelint/stylelint-config-standard/issues/5#issuecomment-178496614 seems like it's not going to add sort rules/become a standard.

Oh well, I'm gonna get started on a standard. Thanks for the cool tool.

[MoOx]

For example feross standard don't force you to put all your var declarations at the same place. You can extends this one and add you own rules.

[jeddy3]

@MoOx's That's a good point.

5 (comment) seems like it's not going to ... become a standard.

@corysimmons I'm not sure that's a fair assessment. This config provides a standard for 60 or so rules. It just avoids a divisive rule, which I think is quite dependent on a team's choice of tooling e.g. quite a few PostCSS plugins use (name-spaced) custom declarations, should each of these be added to config and in what order?

Oh, I just noticed you built the lost grid. So, you'll understand the trouble with trying to order an unknown number of custom declarations. Nice work with lost btw :)

[dan-gamble]

The guy who made postcss-sorting has a good way on how to handle @at-rules https://github.com/hudochenkov/postcss-sorting#at-rules

I'm guessing you could do the same with custom declarations as well. But it's a fair point the PostCSS ecosystem is huge and you'd have to cover a lot of things. I think Cory's point is valid in respect that property ordering doesn't really fall under the PostCSS ecosystem as it's a core part of CSS. But if you need to start ordering custom things that you can't really extend a config as you will be overwriting most of it

[jeddy3]

@dan-gamble Thanks for the input.

It feels like it's just the rule-properties-order rule that is contentious. Perhaps we can do something similar to standard and semistandard? i.e. you guys can create something like stylelint-config-sortedstandard which just adds declaration sorting to this config.

I can add something prominent to the README here pointing people in that direction. Handling the issue around sorting, and dealing with requests for custom things, can then be handled in the stylelint-config-sortedstandard repo.

I think there are good reasons for providing sorting and good reasons for not. At least this way we won't create entirely separate and competing "standards", and everyone can benefit from the same solid 60 rules.

What do you all think?

[dan-gamble]

I do think sorting does dive down more into team preferences. I don't think sorting in the global consensus will ever evolve out of preferring alphabetical with no groups.

I'd be up for trying to create a standard but i think rule ordering will never be a happy global decision. I think the standard ruleset for the most part is fine to linking off to things extending that would probably be the better way to go :+1:

[jeddy3]

I think the standard ruleset for the most part is fine to linking off to things extending that would probably be the better way to go :+1:

Good stuff :) @corysimmons Does this sound good to you?

[corysimmons]

I'm really not trying to be contrary here, but I really don't think giving people the choice to opt in to certain features makes it a standard. I mean... they can already do that.

Consider if browsers got to pick and choose which standards they implemented. Chrome might implement box-sizing nicely, Firefox might implement position: sticky nicely, but then Safari might decide to implement sub-pixel rounding their own way, and instantly we have a ton of headaches and StackOverflow questions.

That's only several browsers and we've had innumerable issues because they didn't agree on a standard. Hell, we coined it the "Browser Wars" and everyone was so ecstatic when browsers finally started attempting to do things the same way.

That's only several browsers doing things slightly differently. With rule ordering, you'd have tens of thousands of developers doing things their own way. You'd never learn where to look for XYZ.

I genuinely believe this is something we can perfect over time. Most devs prefer to group by type. I know I do, and contrary to these issues, I really don't put a lot of thought into this stuff. I just do it naturally because it makes sense. I just wish there were rules about it.

Anyway, I closed these issues because I realized there's no point in even debating this. I want rules one way, and you want them another way. The entire purpose of creating configurable rules was to let anyone create their own way.

I'm just going to market my way as the official standard, and I hope that people will jump in the Issues to discuss ways we can improve it over time.

I'm pretty sure it'll be popular for the same reasons StandardJS is popular: people don't really care about what the standard is, as long as there is a pretty decent/popular/open-source one.

Feel free to submodule my ruleset into stylelint-config-sortedstandard though. :)

[corysimmons]

@jeddy3 What are your thoughts on adding stylelint-config-strict?

I mean, people specifically add use strict; to their JS all the time. People love strict crap.

This way we could have a strict standard (which is effectively what I'm asking for) and config-standard can stay the way it is.

[jeddy3]

You make some good points :)

I genuinely believe this is something we can perfect over time.

That is a great attitude to have and I'll do what I can to help you achieve it :)

The first hurdle to over come is the name as someone has already nabbed stylelint-config-strict. As you outlined above, "Standard" is probably the word you're after. Having "standard" will also allow you to piggy back on the traction of standardjs. And, as @MoOx , the word "recommended" is more aligned to the current goals of this repo and also parallels eslint's convention.

So, how best to go about this?...

This repo has one dependent already and a fair few downloads, but I think we can evolve the goal and therefore the strictness of the rules with a major version jump. Version 4.0.0 of standard will be more strict.

I can then create stylelint-config-recommended in the meantime to fulfil the current goals of this config i.e. "favouring flexibility over strictness for things like multi-line lists and single-line rulesets, and try to avoid potentially divisive rules."

What do you think? Which is the best way forward... a major version jump or a rename? Which has the least impact on existing users?

Before I action anything though, I'd like to get @davidtheclark trusted opinion on this. What do you think David? The idea of allowing Cory to use this name to created a strict and opinionated config, which he hopes to evolve and perfect over time (with the input of people). The creation of stylelint-config-recommended. And lastly, the migration approach.

[davidtheclark]

Honestly, I do not care about the naming for this repo, between "standard", "recommended", something else like "base", "safe", etc. I just care that this repo continues doing what it's doing, because I think it's the most important extendable config: when there are 100 rules, providing a solid baseline that most people can extend without much or any overriding is very nice.

I think that a good migration pattern generally for stuff like this is to just to provide clear deprecation/renaming notices to users. It's the best we can do :)

I am fine with @corysimmons creating using the stylelint-config-standard name to create an opinionated config of his own. I am not ok with calling it "the official standard", though, because it's not. There is no "official standard" for stylelint.

(I myself would not use a config that enforces property ordering. I think that it's more trouble than its worth. So if I were making an opinionated standard, it would not include that. For what that's worth.)

Are we all on the same page then?

[corysimmons]

I am not ok with calling it "the official standard", though, because it's not. There is no "official standard" for stylelint.

I see what you're saying. Personally I love that stylelint is so flexible (helps me integrate WP Coding Standards with my team). I never meant to insinuate that stylelint-config-standard should be the only ruleset we offer/maintain.

Instead of "this is the only ruleset" it should be "this is our strict ruleset".

So far as property ordering, a strict ruleset should definitely enforce that, and I'm in love with @dan-gamble 's property grouping/ordering/spacing. It'll all need tweaked to the right balance of strictness, but I really think the majority of users prefer grouping by type as CSS Trick's poll demonstrates.

I think the most interesting part is how unpopular alphabetical is.

Regardless, let's group by property, and sort alphabetically.

---

What's the next step forward from here? I'll get to work on that ruleset tonight and should have something pretty solid within a few hours. (I'll go ahead and add deprecation warnings and such to the README on my fork)

[davidtheclark]

Cool! I think the next set is to sort out the configure you propose, write whatever docs you want; and meanwhile you and @jeddy3 can rename things as needed.

Thanks for working on this @corysimmons.

Sent from my iPhone

On Feb 2, 2016, at 6:04 PM, Cory Simmons notifications@github.com wrote:

I am not ok with calling it "the official standard", though, because it's not. There is no "official standard" for stylelint.

I see what you're saying. Personally I love that stylelint is so flexible (helps me integrate WP Coding Standards with my team). I never meant to insinuate that stylelint-config-standard should be the only ruleset we offer/maintain.

Instead of "this is the only ruleset" it should be "this is our strict ruleset".

So far as property ordering, a strict ruleset should definitely enforce that, and I'm in love with @dan-gamble 's property grouping/ordering/spacing. It'll all need tweaked to the right balance of strictness, but I really think the majority of users prefer grouping by type as CSS Trick's poll demonstrates.

I think the most interesting part is how unpopular alphabetical is.

Regardless, let's group by property, and sort alphabetically.

What's the next step forward from here? I'll get to work on that ruleset tonight and should have something pretty solid within a few hours.

— Reply to this email directly or view it on GitHub.

[corysimmons]

No problem!

I'll come up with a good ruleset and document rationale behind decisions. :neckbeard:

Thank you all so much for being open minded about this. I really think this will be a great thing for the CSS community at large and stylelint in particular.

If we can get https://github.com/stylelint/stylelint/issues/330 (or https://github.com/morishitter/cssfmt/issues/61) sorted out as well I can easily see stylelint taking over the CSS linting scene.

:godmode:

$ npm install --save-dev stylelint stylelint-config-standard

// package.json
"scripts" : {
  "styles:format": "stylelint --config standard src/css/**/*.scss --out-dir dist/css --scss --autocorrect"
}

[corysimmons]

Is it possible to disable the ability to overwrite rules with this particular config?

Also, what's the official name of the flexible config? stylelint-config-base looks pretty good to me.

[ntwb]

...helps me integrate WP Coding Standards with my team...

@corysimmons you know that https://github.com/stylelint/stylelint-config-wordpress exists right?

[corysimmons]

@ntwb Yeah, that's what I was saying.

Personally I love that stylelint is so flexible (helps me integrate WP Coding Standards with my team)

I love the fact that stylelint is flexible enough to write any config for it. In fact, it's helping my team adhere to the WP coding style.

[ntwb]

:+1:

[corysimmons]

hah... thought this would take a few hours tops. Parsing through hundreds of rules and coming up with a definitive standard is fun fun fun. :)

We should really rip off those CSSComb folks and make one of those config generators for the future http://csscomb.com/config :O

[ntwb]

http://csscomb.com/config

Thats cool :sunglasses:

[corysimmons]

Yeah, super user friendly. We'll get there!

[jeddy3]

It sounds like you've been busy and doing some great work Cory!

Up until now we haven't really given much thought to the role of the stylelint org itself. We were too busy building stylelint :) But this feels like the right time to take stock and create a clear definition.

Much in the same way that eslint is the tool that powers the likes of standardjs. We intend to create that same distinction with stylelint by moving all but the tool itself, the tester, the website, our eslint config and an extendable baseline config out of the organisation.

Like I said above, I think your mission to create a config to unify the CSS community is a great one and it's awesome to know that stylelint is going to be used behind the scenes to power such a thing :)

And, like I also said above, I'll do what I can to help you get started. As such, the offer for you to use the stylelint-config-standard name still stands. You made some good points to why this name best represents your goals. And, as I pointed out, it'll let you piggy back on the traction of standardjs.

Let me know if you think having the stylelint-config-standard name would be helpful to you and I'll move this repo over from the stylelint org to your github user.

It'll be great if you could help us out as well by:

1. Using a major version bump and adding an explanation of the change in purpose to the changelog. I think this will be the best way of informing existing users of the config's change in purpose. It will also give them the opportunity to change to a extendable baseline, if that is what they need.
2. Making it clear within the documentation that is stylelint-config-standard isn't the "official standard" for stylelint. As David pointed out above, there is no "official standard" for stylelint :)

[dan-gamble]

I think the name would be a great help.

1. It's already an existing thing inside of the CSS linting ecosystem although the ruleset that follows with that could potentially dramatically change.
2. It aligns with JS name as well.

I wonder if it would be worth dropping the -config from it and just calling it stylelint-standard because if we are looking to plough on with creating a standard i think that names has more meaning behind it. Also if everything is stylelint-config-* we could probably lose the excess word. :)

[MoOx]

having -config is a good idea imo. It avoid confusion. People can create plugin (eg: stylelint-plugin-whatever). All smart too have some prefixes (eslint-config-, babel-preset- etc). We should not do the postcss-* mistake.

[jeddy3]

I wonder if it would be worth dropping the -config from it and just calling it stylelint-standard

As @MoOx points out, the convention is to use stylelint-config-* for stylelint configs. However, much like standardjs does, you're free to consume that config in another tool and name that tool as you wish.

I'd strongly recommend against naming that tool stylelint-standard though as that would give the wrong impresssion that it's stylelint's standard. stylelint does not have an "official standard".

Perhaps something like "standardcss" would be more apt when you reach the stage where you're consuming the config in another tool—perhaps once you have needs specific to your goal (for example, maybe something like standardjs's zero configuration.

In the beginning though, I think just providing a stylelint config called stylelint-config-standard, to match the config naming convention, will get you guys started :)

Does that make things a little clearer?

[dan-gamble]

It's a fair point and i misunderstood your last post.

I'd strongly recommend against naming that tool stylelint-standard though as that would give the wrong impresssion that it's stylelint's standard. stylelint does not have a standard.

I thought you was getting behind Stylelint enforcing a standard, that clears it all up for me!

[jeddy3]

i misunderstood your last post.

No worries, that happens a lot to me. I'm trying to improve the clarity of my writing :)

[dan-gamble]

I'm sure it was more on my behalf than yours, you always seem to be concise :+1:

[corysimmons]

@jeddy3 Little bummed stylelint-config-standard won't live here, but I'm happy to host it, and it'll free the org up to focus on stylelint as a tool rather than configs (you're migrating the other configs except the baseline out too right?).

Give me a few days (probably over this weekend) to finish up the first set of strict rules (going over 100+ rules turned out to be pretty intense, several hours in and halfway there) before we do the transfer.

Will definitely adhere to semver. Maybe you should throw an explanation up on the top of the README for a couple days for what's about to happen to the repo?

[jeddy3]

you're migrating the other configs except the baseline out too right?).

Exactly. I'll be approaching new owners shortly e.g. it feels like the most logical home for the SuitCSS config is the SuitCSS org.

it'll free the org up to focus on stylelint as a tool rather than configs

Yes, that's the intent here.

Maybe you should throw an explanation up on the top of the README for a couple days

Good idea. I'll draft something shortly.

[corysimmons]

:+1: :100:

[MoOx]

I still think that stylelint should offer a simple set of rules like eslint does with "eslint:recommended".

[jeddy3]

I still think that stylelint should offer a simple set of rules like eslint does with "eslint:recommended".

Yep, that's exactly the intention :)

As David mentioned above (and as I mentioned in the 3rd paragraph here), the stylelint org should continue to offer and maintain a recommended solid baseline that most people can extend without much or any overriding. A baseline that "favours flexibility over strictness for things like multi-line lists and single-line rulesets, and tries to avoid potentially divisive rules".

I'm going to create stylelint-config-recommended for that purpose as it aligns with eslint, and frees up stylelint-config-standard for Cory and Dan.

[MoOx]

Good to heard.

[jeddy3]

@corysimmons Sorry to mess you around, but I've just realised that this name change is going to inconvenience more users than I originally thought. I hadn't noticed that it was downloaded a couple of thousand times in the last month when I offered to change the name and make stylelint-config-standard available to you. Sorry, I should of been a bit more thorough.

It sounds like you've taken the time to go over all the rules, which is great to here and I'm sure it'll help make your strict config very good! We've been working on stylelint for over a year and so the number of rules of rules has slowly grown over that period to a heady 100+ :)

I still think your mission to try and unify the CSS community is the good one, so I wish you the best of luck with your config and I hope you find a suitable and available name for it.

[MoOx]

One alternative solution:

• deprecate stylelint-config-standard in favor of stylelint-config-recommended on npm (and don't use stylelint-config-standard anymore)
• create stylelint-config-recommended for stylelint "official"/minimal recommended rules set
• create stylelint-config-standardcss as a "standardjs" like rules set

[jeddy3]

Thanks for alternative @MoOx. stylelint-config-standardcss is a good name for Cory's mission and perhaps he will take it :)

I'm in favour of not deprecating stylelint-config-standard though as it'll needlessly inconvenience those who already use it.

I think standard is fine as a name. I originally named it as standard as in normal e.g. "You're wearing a standard looking suit today Geoff. Did you not want to put on something more fancy for a Friday?" :)

[MoOx]

I mentionned the deprecation to avoid the confusion that will be created by having 2 similars names stylelint-config-standard/stylelint-config-standardcss.

FYI, I did not have any issue/complain by deprecating cssnext package (with it downloaded like a lot) in favor of postcss-cssnext. Do not hesitate to do that. Deprecating a package does not break things. It warn the user for a change and the user can does it when he have time :)

[jeddy3]

Deprecating a package does not break things. It warn the user for a change and the user can does it when he have time :)

Thanks, I didn't know that :)

[davidtheclark]

Agreed that deprecation is not a bad way to go. npm users should be accustomed to it.

[corysimmons]

I agree with @MoOx but I think I'm going to end up calling it standard-css instead of stylelint-config-standardcss.

I want people to be able to use it with any tool that supports the ruleset.

The whole stylelint-config-standard thing would still cause some confusion, and StandardCSS would first and foremost be written/maintained as a stylelint config, so it would be nice if you could change the name of it with a deprecation warning.

I'll finish the config this weekend so you have a link to point people to.

[MoOx]

fyi, standard(js) have it's eslint config shared as eslint-config-standard.

[corysimmons]

@MoOx Ah thanks. Okay, so I'll practically mirror what feross is doing and create standardcss and stylelint-config-standardcss repos.

Or standard-css? Which do you guys like better?

[dan-gamble]

:+1:

[corysimmons]

@jeddy3 You can keep the name. I'm done with stylelint. I'll check in every month or so to see if it's usable.

[MoOx]

That's not a very constructive feedback. All that "noise" to end with something which look like "stylelint is unusable, I am done with it" does not feel good. Can you elaborate?