[buddypress-trac] [BuddyPress Trac] #7028: Use stylelint to lint SCSS & CSS replacing Ruby gem `scss_lint`

[buddypress-trac]

#7028: Use stylelint to lint SCSS & CSS replacing Ruby gem `scss_lint`
---------------------------------------+-----------------------------
 Reporter:  netweb                     |       Owner:
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  Future Release
Component:  Tools - Build Process      |     Version:  2.3.0
 Severity:  normal                     |  Resolution:
 Keywords:  needs-patch needs-refresh  |
---------------------------------------+-----------------------------

Comment (by netweb):

 Replying to [comment:7 hnla]:
 > >Yes, the coding standards state: "Use shorthand (except when overriding
 styles) for background, border, font, list-style, margin, and padding
 values as much as possible. (For a shorthand reference, see CSS
 Shorthand."
 >
 > And how does this automated test determine when styles are attempting to
 override something that perhaps is located somewhere in the Cascade?

 This is one of the great things about PostCSS (stylelint is a PostCSS
 plugin), it loads up the entire file CSS, SCSS, Less, whatever into an
 [https://en.wikipedia.org/wiki/Abstract_syntax_tree abstract syntax tree
 (AST)] to iterate over all the properties, values, declarations at once.
 PostCSS plugins such as stylelint can then analyse where each declaration
 is in the AST tree to determine if it is related to another declaration,
 property, or value elsewhere in the AST tree.

 Or for a more technical explanation that is far better than I could ever
 explain myself:
 > http://davidtheclark.com/its-time-for-everyone-to-learn-about-postcss/
 > > "The tool itself is a Node.js module that parses CSS into an abstract
 syntax tree (AST); passes that AST through any number of “plugin”
 functions; and then converts that AST back into a string, which you can
 output to a file. Each function the AST passes through may or may not
 transform it; sourcemaps will be generated to keep track of any changes."
 > >
 > > "The AST provides a straightforward API that developers can use to
 write plugins. For example, you can cycle through each rule set in a file
 with `css.eachRule()`, or each declaration in a rule with
 `rule.eachDecl()`. You can get the selector of a rule with
 `rule.selector`, or the name of an at-rule with `atRule.name`. From these
 few examples you can see that the PostCSS API makes it pretty easy to work
 with CSS source code (much easier and more accurately than if you were to
 rely on regular expressions, like a chump)."


 Replying to [comment:7 hnla]:
 > The reference to 'shorthand' actually covers both:
 >
 > ``` property: 0 0 0;```
 >
 > and
 >
 > ``` property: 0 0 0 0;```
 >
 > Programatically it is next to impossible to tell why one is used over
 another and neither is actually incorrect ( this is very similar to an
 issue that always used to exist in the jigsaw validator).
 >
 > Aspects like this of CSS coding are tricky and where we always preferred
 that people would write `0 0 0` especially if obvious this was perhaps the
 only occurrence of this property on a selector, in larger scenarios it
 becomes harder to enforce this.

 Correct, neither are technically incorrect, but WordPress has chosen the
 `property: 0 0 0` type format, why this was chosen over the other is one
 for the history books and that I do not know. I'd has at a guess like many
 of the other CSS coding standards it has evolved over many years to be the
 "more common" style format used throughout the codebase so it was then
 standardised as the preferred format.

 This codex article goes into the WordPress CSS shorthand coding standards
 a little further in regard to CSS shorthand
 https://codex.wordpress.org/CSS_Shorthand

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7028#comment:9>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac