CSSLint + Stylelint

[ai]

I think if we will merge CSSLint and Stylelint everyone will win — users will get more features, and we will have more free time. We already have great examples of ESLint + JSCS, Babel + esnext, Rails + Merb.

@XhmikosR @frvge @davidtheclark @jeddy3 what do you think?

Merging Plan Example

1. CSSLint developers will get a membership in Stylelint core team.
2. We check Stylelint rules and rewrite missed CSSLint plugin in Stylelint.
3. CSSLint 2.0 will use Stylelint as backend, but work with same old CSSLint config (it will convert CSSLint config to Stylelint config inside)
4. We provide some migration tool to convert CSSLint config to Stylelint config.

Benefits for CSSLint Developers

1. More developers will work for one tool — so less time for boring support tasks and more for developing new smart rules.
2. You will be a bigger project maintainer — more glory and respect. After merging, you will increase user base to 70%. Facebook, Github, US gov 18F, Wikipedia uses Stylelint. Bootstrap is in the migration to Stylelint.
3. Stylelint uses PostCSS — you will get many benefits from PostCSS ecosystem: SCSS, Less, Broken CSS and SugarSS parsers. There are useful development tools for PostCSS: rules benchmark and AST explorer. Autoprefixer brings a huge user base to be sure in CSS parser.
4. With PostCSS AST you could fix lint issues in CSS like eslint --fix does in JS. Stylelint already could do it for some rules with Stylefmt.
5. PostCSS parser is DOM-like, instead of SAX-like ParserLib. But with postcss-selector-parser, postcss-value-parser, and postcss-media-query-parser it will have same abilities for you.

Benefits for CSSLint Users

1. They will get more rules. Stylelint has around 150 rules including very smart: no-unsupported-browser-features, no-indistinguishable-colors, no-browser-hacks, no-descending-specificity
2. They will get SCSS and Less support.
3. With Stylefmt they will be able to fix CSS automatically according to linter rules.
4. They will be able to parse CSS once for Autoprefixer and linter. Parsing is the longest part of CSS tools.
5. They will have postcss-browser-reporter.
6. Also people like modular architecture for linters — ESLint is the great example. Stylelint based on same ESLint modular philosophy.
7. Users love when two awesome projects merge, so they are free from choosing what is best — for example, look at the reaction on ESLint + JSCS merge.

[XhmikosR]

Hey there.

All this seems nice, but personally I have very limited time at this point.

If there are developers willing to do this not just for a week, I'm totally
in favor of this.

Unfortunately we lack of manpower. I tried getting out a stable release but
I'm all alone and with limited time for CSS Lint.

On Jul 22, 2016 17:10, "Andrey Sitnik" notifications@github.com wrote:

I think if we will merge CSSLint and Stylelint http://stylelint.io/
everyone will win — users will get more features, and we will have more
free time. We already have great examples of ESLint + JSCS
http://eslint.org/blog/2016/04/welcoming-jscs-to-eslint, Babel + esnext
https://babeljs.io/blog/2015/01/12/6to5-esnext, Rails + Merb
http://yehudakatz.com/2008/12/23/rails-and-merb-merge/.

@XhmikosR https://github.com/XhmikosR @frvge https://github.com/frvge
@davidtheclark https://github.com/davidtheclark @jeddy3
https://github.com/jeddy3 what do you think?
Merging Plan Example

1. CSSLint developers will get a membership in Stylelint core team.
2. We check Stylelint rules and rewrite missed CSSLint plugin in
   Stylelint.
3. CSSLint 2.0 will use Stylelint as backend, but work with same old
   CSSLint config (it will convert CSSLint config to Stylelint config inside)
4. We provide some migration tool to convert CSSLint config to
   Stylelint config.

Benefits for CSSLint Developers

1. More developers will work for one tool — so less time for boring
   support tasks and more for developing new smart rules.
2. You will be a bigger project maintainer — more glory and respect.
   After merging, you will increase user base to 70%. Facebook
   https://code.facebook.com/posts/879890885467584/improving-css-quality-at-facebook-and-beyond/,
   Github https://github.com/primer/stylelint-config-primer, US gov 18F
   https://github.com/18F/stylelint-rules, Wikipedia
   https://github.com/wikimedia/stylelint-config-wikimedia uses
   Stylelint. Bootstrap is in the migration
   https://github.com/ntwb/stylelint-config-bootstrap to Stylelint.
3. Stylelint uses PostCSS https://github.com/postcss/postcss — you
   will get many benefits from PostCSS ecosystem: SCSS
   https://github.com/postcss/postcss-scss, Less
   https://github.com/webschik/postcss-less, Broken CSS
   https://github.com/postcss/postcss-safe-parser and SugarSS
   https://github.com/postcss/sugarss parsers. There are useful
   development tools for PostCSS: rules benchmark
   https://github.com/postcss/postcss-devtools and AST explorer
   http://astexplorer.net/#/np0DfVT78g/1. Autoprefixer brings a huge
   user base to be sure in CSS parser.
4. With PostCSS AST you could fix lint issues in CSS like eslint --fix
   does in JS. Stylelint already could do it for some rules with Stylefmt
   https://github.com/morishitter/stylefmt.
5. PostCSS parser is DOM-like, instead of SAX-like ParserLib. But with
   postcss-selector-parser
   https://github.com/postcss/postcss-selector-parser,
   postcss-value-parser https://github.com/TrySound/postcss-value-parser,
   and postcss-media-query-parser
   https://github.com/dryoma/postcss-media-query-parser it will have
   same abilities for you.

Benefits for CSSLint Users

1. They will get more rules. Stylelint has around 150 rules
   http://stylelint.io/user-guide/rules/ including very smart:
   no-unsupported-browser-features
   http://stylelint.io/user-guide/rules/no-unsupported-browser-features/,
   no-indistinguishable-colors
   http://stylelint.io/user-guide/rules/no-indistinguishable-colors/,
   no-browser-hacks
   http://stylelint.io/user-guide/rules/no-browser-hacks/,
   no-descending-specificity
   http://stylelint.io/user-guide/rules/no-descending-specificity/
2. They will get SCSS https://github.com/postcss/postcss-scss and
   Less https://github.com/webschik/postcss-less support.
3. With Stylefmt https://github.com/morishitter/stylefmt they will
   be able to fix CSS automatically according to linter rules.
4. They will be able to parse CSS once for Autoprefixer and linter.
   Parsing is the longest part of CSS tools.
5. They will have postcss-browser-reporter
   https://github.com/postcss/postcss-browser-reporter.
6. Also people like modular architecture for linters — ESLint is the
   great example. Stylelint based on same ESLint modular philosophy.
7. Users love when two awesome projects merge, so they are free from
   choosing what is best — for example, look at the reaction on ESLint + JSCS
   merge.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#668, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVVtWwFHkRPNoMR0U-0A7i1653Gxl7Wks5qYM9VgaJpZM4JSy1b
.

[ai]

@XhmikosR sure, maintaining is hard. But this merging could dramatically help you with lack of manpower ;).

I will ask my followers to help.

I think the first task will be to compare CSSLint and Stylelint rules.

[maraisr]

I'm happy to help! So use me ☝🏻️

[Xaviju]

I'll be happy to help as well. Keep me informed!

[yepninja]

I am ready to help, too.

[mjovel]

Happy to help!

[ai]

@mjovel @alanev @Xaviju @maraisr Awesome! Also I have Kirbaba developer from Russia, who want to have.

First step is to check CSSLint rules — what we can already implement in Stylelint.

Here is CSSLint rules: https://github.com/CSSLint/csslint/wiki/Rules. I count 31 rules. We have 5 developers. Let’s everyone take 6 rules:

1. Kirbaba: box-model, display-property-grouping, duplicate-properties, empty-rules, known-properties, adjoining-classes
2. @maraisr: box-sizing, compatible-vendor-prefixes, gradients, text-indent, vendor-prefix, fallback-colors
3. @Xaviju: star-property-hack, underscore-property-hack, bulletproof-font-face, font-faces, import, regex-selectors
4. @alanev: universal-selector, unqualified-attributes, zero-units, overqualified-elements, shorthand, duplicate-background-images
5. @mjovel: floats, font-sizes, ids, important, qualified-headings, unique-headings

I need you to check every rule and mark it with:

• y — we can implement it one-to-one by existed Stylelint rules (please write what rules with what options). Also don’t forget to look to third-party rules, for example https://www.npmjs.com/package/stylelint-known-property
• x — we have similar rules in Stylelint, but we need to add some features or options (write what rules and what we need to add)
• n — we have no same rules in Stylelint.

[davidtheclark]

It's awesome that all of you stepped forward to help with this!

One of the things I imagine will need to happen during the course of development is the creation of a stylelint-csslint plugin collection. See stylelint-scss for a good existing example. A number of the CSSLint rules look like they'll end up in that plugin collection rather than in stylelint's core rule set (e.g. floats, unique-headings, etc.). We can talk about each individually, of course, but just clueing you all in to a part of the process I anticipate — something for someone to take charge of if interested.

[maraisr]

@davidtheclark yeah mate - I think its so amazing too!! My two cents are, I think that @ai wanted to iron out the discrepancy between having 2 toolsets that do roughly the exact same thing, and merge them into 1 toolchain, like JSCS and ESlint did.

[davidtheclark]

@maraisr Yep, sounds right! I'm not suggesting that the merge wouldn't involve enhancements to stylelint, if it sounded like that. Just suggesting that I think to full compatibility with CSSLint's rule set will involve a combination of enhancements to existing rules, new rules, and a stylelint-csslint plugin collection.

[ai]

@davidtheclark sure, we could put extra rules in different place if they are should not be stylelint core.

Also where we can find good third-party rules list (for CSSLint rules checking)?

[davidtheclark]

I don't think anyone's compiled a comprehensive list of third party rules. @jeddy3 might know more than me here. But I've relied just on npm searches to see what's out there --- kind of weak.

[maraisr]

@davidtheclark yeah - will be interesting! In my mind I see a "polymorphic" style approach, where by you can load both your long standing csslint, and or stylelint config file, with a general move toward a standard config.

[jeddy3]

It's awesome that all of you stepped forward to help with this!

Agreed. Thanks everyone!

Just suggesting that I think to full compatibility with CSSLint's rule set will involve a combination of enhancements to existing rules, new rules, and a stylelint-csslint plugin collection.

Agreed. To expand on what @davidtheclark said, rules are only included in core if they meet these criteria. This is to ensure development of the linter remains sustainable.

@jeddy3 might know more than me here. But I've relied just on npm searches to see what's out there

Plugin authors are asked to include the stylelint-plugin keyword in their package.json. Plugins that currently do so are listed here.

Bare in mind that around three quarters of these plugins are deprecated (or have pending deprecate issues) as they can now be handled by core rules e.g. the deprecated plugin stylelint-known-property → the core rule property-no-unknown. I believe the only viable plugins (that aren't already on our curated list of plugins) are:

• https://www.npmjs.com/package/stylelint-value-list-box-shadow-inset-first
• https://www.npmjs.com/package/stylelint-selector-pseudo-class-lvhfa
• https://www.npmjs.com/package/@namics/stylelint-bem

In my mind I see a "polymorphic" style approach, where by you can load both your long standing csslint, and or stylelint config file, with a general move toward a standard config.

Would a simple migration guide from CSSLint to stylelint (in the same manner as this one for scss-lint) not be the simplest option here? If someone feels adventurous they could create a standalone tool (and/or website) that converts a CSSLint config into a stylelint one.

Either way, I agree with @ai's first step. Once we have a better idea of what CSSLint rules are already achievable using stylelint, we'll be in a better position to decide what approach is best.

@maraisr @Xaviju @alanev @mjovel FYI, you'll find the complete list of stylelint's rules here. If you're not already familiar with stylelint you might find this guide about rules useful, as it explains the naming convention and how rules are designed to work together. There is also this part of the Developer Guide that details the option conventions we use. Good luck and please don't hesitate to holler if you've any questions about the workings and conventions of stylelint :)

[delorge]

I'm a bit late but I want to help as well :) guess I will join later

[Kirbaba]

1. The same Stylelint rules
"empty-rules" is same as the "block-no-empty"

2. Similar rules in Stylelint, but we need to add some features or options:
Stylelint "declaration-block-no-ignored-properties" is same as CSSLint "display-property-grouping" but

there is no rule for combination of inline-block displaying with float.

"duplicate-properties" is looks like "declaration-block-no-duplicate-properties" but there is nothing about checking properties which containing the same value.
For example:
CSSLint considered warnings for:

.mybox {
    border: 1px solid black;
    border: 1px solid black;
}

3. There is no same rules in Stylelint
The CSSLint rules "adjoining-classes" and "box-model" doesn’t have the Stylelint analogs.

"known-properties" in the CSSLint is checking a value and ignoring all vendor-prefixes. Stylelint "property-no-unknown" is checking only property and isn't ignoring a prefixes.

[ai]

@jeddy3 awesome migration guide. But it doesn’t really work.

1. User should learn that there is Stylelint.
2. User should find this guide (I didn’t saw it, before you mention it).
3. User should find working time to do all steps manually.

As result we will have few % of users in the end of this funnel.

Of course for users will be much easy to just change "csslint": "^1.0.0" to "csslint": "^2.0.0" or run something npm install stylelint-csslint stylelint; stylelint-csslint convert ./.

[nschonni]

I'm more 👎 on this, but since I've been pretty dormant I'll go with what the other maintainers go with.
Few points:

• JSCS merged with ESLint, not JSHint. CSSLint is more like JSHint than JSCS since it deals with functional linting not style-only rules.
• npm i csslint is 1.6MB vs. npm i stylint is 26MB
• CSSLint supports Node, Java/Rhino, WSH, and browser execution.

I will probably use Stylelint in new projects projects where it makes sense, just like I've transitioned some to ESLint where it makes sense. You folks are doing awesome stuff, and I've enjoyed the Autoprefixer for along time.

[ai]

@nschonni

1. CSSLint and Stylelint are both functional linting. Am I right?
2. Yeap, npm size is always problem right now. But I think most of users prefer more rules, than less file size.
3. PostCSS and Stylelint definitely support node.js and browser. I supported Java/Rhino, but have no good tests right now. Could you recommend Travis CI solution, to test PostCSS/Stylelint with Rhino? What is WSH?

[ai]

@delorge feel free to take someone rules task if they will not get review in this evening :)

[davidtheclark]

@nschonni @ai I don't know what "functional linting" refers to, and don't see a definition on a quick search. But I agree that there's a difference in approach. I wouldn't say that CSSLint is more like JSHint than stylelint, in trying to catch real code errors (both do that); and I also wouldn't say that stylelint is restricted to "style-only" rules (there are plenty of non-style rules). A distinction that does exist, I think --- and maybe this is what you're referring to --- is that CSSLint includes rules like "too many floats", which are more like provisional suggestions that you may override in code review rather than auto-enforceable rules. (Those are in fact the kind of rules that I think would make for better stylelint plugins than core rules.)

The reason for the merge would not be to stop enforcement of those CSSLint-specific rules (plugin collection would work), but to share infrastructure and maintenance, and possibly even extend those CSSLint-specific rules to a wider audience (e.g. SCSS users).

(Why are people worried about filesize for npm modules? Is it just download time when running npm install?)

[Kirbaba]

2. Similar rules in Stylelint, but we need to add some features or options:

Stylelint rule "no-browser-hacks" can be extended to include the CSSLint rules "start-property-hack" and "underscore-property-hack"

3.There is no same rules in Stylelint

• "box-sizing"
• "text-indent"
• "fallback-colors"
• "bulletproof-font-face"
  CSSLint "gradient", "compatible-vendor-prefixes", "vendor-prefix" doesn't have Stylelint analogs, but there is no needs because we have "Autoprefixer".

[ai]

@alanev did his part too, but create for it separated issue #669

[ai]

We need to check only @Xaviju and @mjovel rules pack and then we are ready to go to next step

[delorge]

@ai neither @Xaviju nor @mjovel showed up, I'll take @mjovel tasks

[davidtheclark]

@ai Thanks for organizing! What do you envision as the next step? One possibility would be to open issues for all the CSSLint rules the do not have already have direct substitutes so we can discuss how to handle each one individually.

[Xaviju]

I'm working on my task, it should be ready today, sorry 👍

[delorge]

Existing Stylelint rules

1. ids -> selector-no-id
2. important -> declaration-no-important

CSSLint unique rules

1. floats
2. font-sizes

CSSLint rules I'm not sure about

1. qualified-headings
2. unique-headings

There are no such rules in stylelint, but selector-no-type dissalows

h3 {
    font-weight: normal;
}

and has an option to allow descendant type selectors which may cause conflict with this dissalowed declaration:

.box h3 {
    font-weight: bold;
}

I guess we need separate rules for these ones, but I don't know how to handle possible conflicts.

@ai @davidtheclark @jeddy3 any thoughts?

[Xaviju]

Disallow star hack

x Similar to no-browser-hacks

Stylelint disallow browser hacks that are irrelevant to the browsers you are targeting.
Disallow star hack only points to this specific IE hack but stylelint option is more powerful.

underscore-property-hack

x Similar to no-browser-hacks

Same as above

bulletproof-font-face

n We have no same rules in Stylelint.

This rule is aimed at preventing 404 errors in Internet Explorer 8 and earlier due to a bug in how web font URLs are parsed.

font-faces

n We have no same rules in Stylelint.

Don't use too many web fonts

import

x Similar to At rule blacklist

This rule warns when @import is being used in CSS.
In stylelint you can specify a blacklist of disallowed at-rules instead of a specific rule for import at-rule. Is more flexible.

regex-selectors

x Similar to selector-attribute-operator-blacklist

Disallow selectors that look like regular expressions
In stylelint you can specify a list of disallowed attribute operators.
If we leave it as it is in Stylelint, we will miss the useful recommendations of CSSlint on what are good and bad performance uses of this selectors.

[mjovel]

sorry. yesterday was a travel day. Thanks for picking my set up @delorge

[frvge]

I'm mostly just helping out with basic stuff/triage/quick-fixes. I leave the decisions up to the others.

[maraisr]

@delorge thank you for the overview! We're getting close guys!

[alexander-akait]

@delorge

• box-sizing -> property-blacklist
• shorthand i can help with rules, maybe good for stylelint core rules
• floats and font-sizes, i have idea create rule max-declaration-property (maybe better name) for controlling max properties in styles, example be good disable many animation

[alexander-akait]

@delorge also i don't understand what need reworked/updated in rules:

• import -> at-rule-blacklist
• regex-selectors -> selector-attribute-operator-blacklist

[davidtheclark]

I suggest as a next step to open individual issues in stylelint for each rule or option that you think should be added. We could also open issues for individual plugins, either there or here, now or later. That way we can discuss each case in its own individual issue. I think that will be more effective than trying to address them all here in this one thread.

[alexander-akait]

@davidtheclark maybe open one issue CCSLint compatibility with all rules CSSLint rules and step by step open issue on rules?

[maraisr]

@davidtheclark i tend to agree, the issues will allow us to in effect keep track of progress!

[Kirbaba]

1. Need to write:

• adjoining-classes
• box-model
• box-sizing
• text-indent
• fallback-colors

2. Need to extend or rewrite:

• no-browser-hacks -> start-property-hack + underscore-property-hack
• declaration-block-no-ignored-properties -> display-property-grouping
• declaration-block-no-duplicate-properties -> duplicate-propertie

[delorge]

@evilebottnawi I didn't examine most of the rules, I just put everything in order :)

import -> at-rule-blacklist regex-selectors -> selector-attribute-operator-blacklist
You better ask @Xaviju about that.

[delorge]

@evilebottnawi agreed with box-sizing, moving this rule to update category.

[Xaviju]

@delorge @evilebottnawi I don't think they need to be rewritten. Both at-rule-blacklist and selector-attribute-operator-blacklist are more powerful and already include the same options than CSSLint. I just pointed out that are not exactly similar.

[delorge]

@Xaviju alright, moving this to deprecated category

[alexander-akait]

Move to stylelint/stylelint#1739, let's go

[jeddy3]

I suggest as a next step to open individual issues in stylelint for each rule or option that you think should be added. We could also open issues for individual plugins, either there or here, now or later. That way we can discuss each case in its own individual issue.

Sgtm. I suggest creating the plugin issues in this issue tracker and the rule issues (that meet the criteria) in the stylelint issue tracker, so that the separation of responsibilities is maintained.

[nschonni]

@ai

CSSLint and Stylelint are both functional linting. Am I right?

Yup, definitely. The point I was making was that JSCS and ESLint wasn't 2 functional linting projects merging.

Yeap, npm size is always problem right now. But I think most of users prefer more rules, than less file size.
PostCSS and Stylelint definitely support node.js and browser.

Is there a standalone web version? The web version I saw on the site looks like it requires a backend.

I supported Java/Rhino, but have no good tests right now. Could you recommend Travis CI solution, to test PostCSS/Stylelint with Rhino?

No, I couldn't find a good way of pulling down Rhino in a build matrix, but it has been awhile since I looked. We had problems because of bugs in the last official release (when I looked), but were fixed in the unreleased version.

What is WSH?

Windows Script Host

[ai]

@nschonni

Yup, definitely. The point I was making was that JSCS and ESLint wasn't 2 functional linting projects merging.

Sure, JSCS and ESLint had more differences. But I think that idea difference is main reason against merging. If some project has some idea, they should merge to solve this idea in the best way.

Is there a standalone web version?

Just use browserify or webpack to build client side. Most of PostCSS plugins are client side ready.

We had problems because of bugs in the last official release (when I looked), but were fixed in the unreleased version.

How did you test it? We could implement this testing in Stylelint too.

But, honestly there was no WSH/Rhino issue reports in entire PostCSS ecosystem (it is much bigger) — seems like most of users was migrated to node.js.

[jeddy3]

@delorge Thanks for the summary!

@davidtheclark wrote: I suggest as a next step to open individual issues in stylelint for each rule or option that you think should be added. We could also open issues for individual plugins, either there or here, now or later. That way we can discuss each case in its own individual issue. I think that will be more effective than trying to address them all here in this one thread.

Over at stylelint we've created new issues for the rules and options that we think should be added to core. That leaves the following plugins up for discussion outside of the stylelint organisation:

Possible Errors

• box-model

Compatibility

• adjoining-classes
• compatible-vendor-prefixes
• gradients
• text-indent
• vendor-prefix
• fallback-colors
• star-property-hack
• underscore-property-hack
• bulletproof-font-face

Performance

• font-faces
• overqualified-elements
• duplicate-background-images

Maintainability & Duplication

• floats
• font-sizes

Accessibility

• outline-none

OOCSS

• qualified-headings
• unique-headings

Whoever wants to lead the stylelint-csslint plugin pack initiative, I'd recommend creating a new stylelint-csslint repo (within the CSSLint organisation). Then creating separate issues for each of these plugins. Some of these issues will be closed quickly as there are some thoughts that a few of the rules are outdated and should be deprecated. Having the decisions made, however quickly, within separate issues allows people to comment cleanly on the matter though, and keeps everything easy to reference.

In terms of inspiration of what a plugin pack might look like, I suggest checking out stylelint-scss.

From this point forward, I suggest this issue should focus on discussing the merits of different merge/migration paths e.g. @ai's suggestion of:

npm install stylelint-csslint stylelint; stylelint-csslint convert ./

If a conversion CLI tool bundled within stylelint-csslint proves to be the path forward, we can close this issue and create an new issue within the stylelint-csslint repo to discuss the details of the implementation.

One advantage I can think of the conversion tool is that current CSSLint can remain available for anyone wishing to use rules deemed outdated in stylelint-csslint or has one of the use cases that @nschonni outlined.

[seth2810]

@jeddy3 I can participate stylelint-csslint initiative. I started with implementation a couple of rules, currently without tests and build pipe, that currently are most needed for me inside personal repo, but I am pleased to share my current code base for community.

[alexander-akait]

@seth2810 can you PR in our repo?

[seth2810]

@evilebottnawi I don't understand what you mean. Of course I can make PR in your repo, but I think it is about creating a separate repo for missing rules. It would be great if the solution would work in both directions:

• use stylelint-csslint-missing inside new CSSLint core;
• ease migration from CSSLint with plug-in and configure couple of missed rules inside Stylelint configuration.