[buddypress-trac] [BuddyPress Trac] #7028: Use stylelint to lint SCSS & CSS replacing Ruby gem `scss_lint`
noreply at wordpress.org
Wed Apr 27 09:42:48 UTC 2016
#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
> 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
> > "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;```
> ``` 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
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7028#comment:9>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac