Permalink
Browse files

Use "tab-size" for list-item-indent

  • Loading branch information...
1 parent 4a854b1 commit 5da956de0fea57a6e6ef1a6ebb3fd4585213eb42 @jeddy3 jeddy3 committed Aug 27, 2016
View
Oops, something went wrong.
View
@@ -10,10 +10,10 @@ We are committed to making participation in this project a harassment-free exper
Examples of unacceptable behavior by participants include:
-- The use of sexualized language or imagery
-- Personal attacks
-- Publishing other's private information, such as physical or electronic addresses, without explicit permission
-- Public or private harassment
+- The use of sexualized language or imagery
+- Personal attacks
+- Publishing other's private information, such as physical or electronic addresses, without explicit permission
+- Public or private harassment
This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
View
@@ -8,19 +8,19 @@ A mighty, modern CSS linter that helps you enforce consistent conventions and av
## Features
-- **Over one hundred and fifty rules:** Including those that:
- - **Catch errors**: e.g. invalid hex colors, indistinguishable colors, or overriding shorthand properties.
- - **Enforce best practices**: e.g. keeping specificity low or disallowing vendor prefixes in your source code.
- - **Control what languages features can be used**: e.g. whitelisting specific units, properties and functions, or disallowing certain selector types.
- - **Enforce code style conventions**: e.g. checking the spacing around the colon in declarations or specifying patterns for class selectors.
-- **Support for the latest CSS syntax:** Including custom properties, range context for media features, calc() and nesting.
-- **Understands *CSS-like* syntaxes:** The linter is powered by [PostCSS](https://github.com/postcss/postcss), so it understands any syntax that PostCSS can parse, including SCSS, [SugarSS](https://github.com/postcss/sugarss), and *experimental support* for Less.
-- **Completely unopinionated:** Only enable the rules you want, and configure them with options that tailor the linter to your needs.
-- **Support for plugins:** It's easy to create your own rules and add them to the linter.
-- **Automatically fix some stylistic warnings:** By using [stylefmt](https://github.com/morishitter/stylefmt) which supports stylelint configuration files.
-- **Shareable configs:** If you don't want to craft your own config, you can extend a shareable config.
-- **Options validator:** So that you can be confident that your config is valid.
-- **Growing community**: Used by [Facebook](https://code.facebook.com/posts/879890885467584/improving-css-quality-at-facebook-and-beyond/), [Github](https://github.com/primer/stylelint-config-primer), [Wikimedia](https://github.com/wikimedia/stylelint-config-wikimedia), [GSA](https://github.com/18F/stylelint-rules/), and [WordPress](https://github.com/ntwb/stylelint-config-wordpress/) among others.
+- **Over one hundred and fifty rules:** Including those that:
+ - **Catch errors**: e.g. invalid hex colors, indistinguishable colors, or overriding shorthand properties.
+ - **Enforce best practices**: e.g. keeping specificity low or disallowing vendor prefixes in your source code.
+ - **Control what languages features can be used**: e.g. whitelisting specific units, properties and functions, or disallowing certain selector types.
+ - **Enforce code style conventions**: e.g. checking the spacing around the colon in declarations or specifying patterns for class selectors.
+- **Support for the latest CSS syntax:** Including custom properties, range context for media features, calc() and nesting.
+- **Understands *CSS-like* syntaxes:** The linter is powered by [PostCSS](https://github.com/postcss/postcss), so it understands any syntax that PostCSS can parse, including SCSS, [SugarSS](https://github.com/postcss/sugarss), and *experimental support* for Less.
+- **Completely unopinionated:** Only enable the rules you want, and configure them with options that tailor the linter to your needs.
+- **Support for plugins:** It's easy to create your own rules and add them to the linter.
+- **Automatically fix some stylistic warnings:** By using [stylefmt](https://github.com/morishitter/stylefmt) which supports stylelint configuration files.
+- **Shareable configs:** If you don't want to craft your own config, you can extend a shareable config.
+- **Options validator:** So that you can be confident that your config is valid.
+- **Growing community**: Used by [Facebook](https://code.facebook.com/posts/879890885467584/improving-css-quality-at-facebook-and-beyond/), [Github](https://github.com/primer/stylelint-config-primer), [Wikimedia](https://github.com/wikimedia/stylelint-config-wikimedia), [GSA](https://github.com/18F/stylelint-rules/), and [WordPress](https://github.com/ntwb/stylelint-config-wordpress/) among others.
## Example output
@@ -30,46 +30,45 @@ A mighty, modern CSS linter that helps you enforce consistent conventions and av
With stylelint, it's easy to start linting your CSS:
-1. Decide how you want to use stylelint:
- - [via the stylelint CLI](/docs/user-guide/cli.md)
- - [via a plugin for your build tool](/docs/user-guide/complementary-tools.md#build-tool-plugins) (gulp, webpack etc)
- - [via a plugin for your text editor](/docs/user-guide/complementary-tools.md#editor-plugins) (atom, sublime text etc)
- - [via the stylelint Node API](/docs/user-guide/node-api.md)
- - [via the stylelint PostCSS plugin](/docs/user-guide/postcss-plugin.md)
-2. Create your [configuration object](/docs/user-guide/configuration.md) by either extending a shared config or crafting your own:
- - To extend a shared config, we recommend using [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard). It includes over 80 of stylelint's rules with sensible defaults. (You can always override specific rules after extending the config.) We update the config with each new release of stylelint. Alternately, you can [search for](https://www.npmjs.com/browse/keyword/stylelint-config) a community config and [extend](/docs/user-guide/configuration.md#extends) that instead.
- - To craft your own config, first [learn about how rules are named and how they work together](/docs/user-guide/about-rules.md), then either:
- - Start small and only learn about [the rules](/docs/user-guide/rules.md) you want to turn on and enforce. *All of the rules are off by default*, and so you can start small, growing your config over time as you have a chance to explore more of the rules.
- - Or copy-paste [this example configuration](/docs/user-guide/example-config.md), which lists all of stylelint's rules and their primary options. Then you can edit the options of each rule to your liking, and remove (or turn off with `null`) the rules that you don't care to enforce.
-
-3. Lint!
+1. Decide how you want to use stylelint:
+ - [via the stylelint CLI](/docs/user-guide/cli.md)
+ - [via a plugin for your build tool](/docs/user-guide/complementary-tools.md#build-tool-plugins) (gulp, webpack etc)
+ - [via a plugin for your text editor](/docs/user-guide/complementary-tools.md#editor-plugins) (atom, sublime text etc)
+ - [via the stylelint Node API](/docs/user-guide/node-api.md)
+ - [via the stylelint PostCSS plugin](/docs/user-guide/postcss-plugin.md)
+2. Create your [configuration object](/docs/user-guide/configuration.md) by either extending a shared config or crafting your own:
+ - To extend a shared config, we recommend using [`stylelint-config-standard`](https://github.com/stylelint/stylelint-config-standard). It includes over 80 of stylelint's rules with sensible defaults. (You can always override specific rules after extending the config.) We update the config with each new release of stylelint. Alternately, you can [search for](https://www.npmjs.com/browse/keyword/stylelint-config) a community config and [extend](/docs/user-guide/configuration.md#extends) that instead.
+ - To craft your own config, first [learn about how rules are named and how they work together](/docs/user-guide/about-rules.md), then either:
+ - Start small and only learn about [the rules](/docs/user-guide/rules.md) you want to turn on and enforce. *All of the rules are off by default*, and so you can start small, growing your config over time as you have a chance to explore more of the rules.
+ - Or copy-paste [this example configuration](/docs/user-guide/example-config.md), which lists all of stylelint's rules and their primary options. Then you can edit the options of each rule to your liking, and remove (or turn off with `null`) the rules that you don't care to enforce.
+3. Lint!
## Guides
You'll find more detailed information on using stylelint and tailoring it to your needs in our guides:
-- [User guide](docs/user-guide.md) - Usage, configuration, FAQ and complementary tools.
-- [Developer guide](docs/developer-guide.md) - Contributing to stylelint and writing your own plugins & formatters.
+- [User guide](docs/user-guide.md) - Usage, configuration, FAQ and complementary tools.
+- [Developer guide](docs/developer-guide.md) - Contributing to stylelint and writing your own plugins & formatters.
## Help out
There is always a lot of work to do, and already well over 100 rules to maintain. So please help out in any way that you can:
-- Create, enhance, and debug rules (see our guide to ["Working on rules"](docs/developer-guide/rules.md)).
-- Improve documentation.
-- Chime in on any open issue or pull request.
-- Open new issues about your ideas for making stylelint better, and pull requests to show us how your idea works.
-- Add new tests to *absolutely anything*.
-- Work on [improving performance of rules](docs/developer-guide/benchmarks.md).
-- Create or contribute to ecosystem tools, like the plugins for Atom and Sublime Text.
-- Spread the word.
+- Create, enhance, and debug rules (see our guide to ["Working on rules"](docs/developer-guide/rules.md)).
+- Improve documentation.
+- Chime in on any open issue or pull request.
+- Open new issues about your ideas for making stylelint better, and pull requests to show us how your idea works.
+- Add new tests to *absolutely anything*.
+- Work on [improving performance of rules](docs/developer-guide/benchmarks.md).
+- Create or contribute to ecosystem tools, like the plugins for Atom and Sublime Text.
+- Spread the word.
We communicate via [issues](https://github.com/stylelint/stylelint/issues) and [pull requests](https://github.com/stylelint/stylelint/pulls).
There is also [stackoverflow](http://stackoverflow.com/questions/tagged/stylelint), which is our preferred QA forum. Tag your post with "stylelint".
## Important documents
-- [Changelog](CHANGELOG.md)
-- [Contributing Guidelines](CONTRIBUTING.md)
-- [License](https://raw.githubusercontent.com/stylelint/stylelint/master/LICENSE)
+- [Changelog](CHANGELOG.md)
+- [Contributing Guidelines](CONTRIBUTING.md)
+- [License](https://raw.githubusercontent.com/stylelint/stylelint/master/LICENSE)
@@ -1,8 +1,8 @@
# Developer guide
-- [Rules](/docs/developer-guide/rules.md) - working on stylelint's rules.
-- [Plugins](/docs/developer-guide/plugins.md) - writing your own plugins.
-- [Processors](/docs/developer-guide/processors.md) - writing your own processors.
-- [Formatters](/docs/developer-guide/formatters.md) - writing your own formatters.
-- [Rule testers](/docs/developer-guide/rule-testers.md) - using and writing rule testers.
-- [Benchmarks](/docs/developer-guide/benchmarks.md) - running benchmarks on rules.
+- [Rules](/docs/developer-guide/rules.md): Working on stylelint's rules.
+- [Plugins](/docs/developer-guide/plugins.md): Writing your own plugins.
+- [Processors](/docs/developer-guide/processors.md): Writing your own processors.
+- [Formatters](/docs/developer-guide/formatters.md): Writing your own formatters.
+- [Rule testers](/docs/developer-guide/rule-testers.md): Using and writing rule testers.
+- [Benchmarks](/docs/developer-guide/benchmarks.md): Running benchmarks on rules.
@@ -38,9 +38,9 @@ A few of stylelint's internal utilities are exposed publicly in `stylelint.utils
You will want to use:
-- `report`: Report your linting warnings. *Do not use `node.warn()` directly.* If you use `report`, your plugin will respect disabled ranges and other possible future features of stylelint, so it will fit in better with the standard rules.
-- `ruleMessages`: Tailor your messages to look like the messages of other stylelint rules.
-- `validateOptions`: Help your user's out by checking that the options they've submitted are valid.
+- `report`: Report your linting warnings. *Do not use `node.warn()` directly.* If you use `report`, your plugin will respect disabled ranges and other possible future features of stylelint, so it will fit in better with the standard rules.
+- `ruleMessages`: Tailor your messages to look like the messages of other stylelint rules.
+- `validateOptions`: Help your user's out by checking that the options they've submitted are valid.
**`stylelint.util.styleSearch` is deprecated and will be removed in v7. Use the external module [style-search](https://github.com/davidtheclark/style-search) instead.**
@@ -72,9 +72,9 @@ If your plugin can accept an array as its primary option, you must designate thi
In addition to the standard parsers mentioned in the ["Working on rules"](/docs/developer-guide/rules.md) doc, there are other external modules used within stylelint that we recommend using. These include:
-- [normalize-selector](https://github.com/getify/normalize-selector) - Normalize CSS selectors.
-- [postcss-resolve-nested-selector](https://github.com/davidtheclark/postcss-resolve-nested-selector) - Given a (nested) selector in a PostCSS AST, return an array of resolved selectors.
-- [style-search](https://github.com/davidtheclark/style-search) - Search CSS (and CSS-like) strings, with sensitivity to whether matches occur inside strings, comments, and functions.
+- [normalize-selector](https://github.com/getify/normalize-selector) - Normalize CSS selectors.
+- [postcss-resolve-nested-selector](https://github.com/davidtheclark/postcss-resolve-nested-selector) - Given a (nested) selector in a PostCSS AST, return an array of resolved selectors.
+- [style-search](https://github.com/davidtheclark/style-search) - Search CSS (and CSS-like) strings, with sensitivity to whether matches occur inside strings, comments, and functions.
Have a look through [stylelint's internal utils](https://github.com/stylelint/stylelint/tree/master/src/utils) and if you come across one that you need in your plugin, then please consider helping us extract it out into a external module.
@@ -88,5 +88,5 @@ To make a single module provide multiple rules, simply export an array of plugin
## Sharing plugins and plugin packs
-- Use the `stylelint-plugin` keyword within your `package.json`.
-- Once your plugin is published, please send us a Pull Request to add your plugin to [the list](/docs/user-guide/plugins.md).
+- Use the `stylelint-plugin` keyword within your `package.json`.
+- Once your plugin is published, please send us a Pull Request to add your plugin to [the list](/docs/user-guide/plugins.md).
@@ -6,11 +6,11 @@ Processors are functions that hook into stylelint's pipeline, modifying code on
Processor modules are functions that return an object with the following properties. The properties are functions that hook into the processing of each file.
-- **code**: A function that accepts two arguments, the file's code and the file's path, and returns a string for stylelint to lint.
-- **result**: A function that accepts two arguments, the file's stylelint result object and the file's path, and either mutates the result object (returning nothing) or returns a new one.
+- **code**: A function that accepts two arguments, the file's code and the file's path, and returns a string for stylelint to lint.
+- **result**: A function that accepts two arguments, the file's stylelint result object and the file's path, and either mutates the result object (returning nothing) or returns a new one.
Processors can enable stylelint to lint the CSS within non-stylesheet files. For example, let's say you want to lint the CSS within `<style>` tags in HTML. If you just feed stylelint your HTML code, you'll run into problems, because PostCSS does not parse HTML. Instead, you can create a processor that does the following:
-- In the `code` processor function, extract CSS from the `<style>` tags in the HTML code. Return a CSS string, which is what stylelint will inspect.
-- Build a sourcemap while performing that extraction, so warning positions can be tailored to match the original source HTML.
-- In the `result` processor function, modify the line/column position of each warning using your sourcemap.
+- In the `code` processor function, extract CSS from the `<style>` tags in the HTML code. Return a CSS string, which is what stylelint will inspect.
+- Build a sourcemap while performing that extraction, so warning positions can be tailored to match the original source HTML.
+- In the `result` processor function, modify the line/column position of each warning using your sourcemap.
Oops, something went wrong.

0 comments on commit 5da956d

Please sign in to comment.