Evaluate postcss-extend for inclusion

[travco]

postcss-extend

Developed to conform to the extend spec by Tab Atkins

'TLDR' primary points of contention:

• Order of Processing/Specificity In normal cases, the document is processed top-to-bottom, however as a feature-fallout of the implementation, it is capable of extending in an anti-pattern (extending things yet to be declared). If what you're writing is an anti-pattern, it will throw a warning.
• Extend Chaining With or without antipatterns in the code, it will (per the spec) propagate all inheritance up the chain of rules.
• Inheritance inside media blocks As per the spec (example 3), inheritance brings in statements as to be able to use the style statements of it's target rule, with the same contingency of the media block.
• Media-cross-media Inheritance Attempting to extend a rule inside a media block from within another media block is directly disallowed in the code and will throw a warning.
• Silent placeholders Includes both the @define-placeholder and it's aliases for compatibility with simple-extend, and the % placeholder from the spec. As this isn't the native parser, the placeholder will be wiped from the CSS if it goes unused (as well as throw a warning).
• Sub-class inheritance Currently doesn't log a warning for it's use, as it is not stated in the spec for or against it's behavior (despite it logically following). All sub classes of an extended 'base' class are extended, creating sub-classes for the extending class as a means of mimicking the inheritance of specific sub-class contingencies (like :active)
• 'Whiff' extention trying to extend something that doesn't exist will log an error, and like everything else, remove the @extend rule.

[MoOx]

If @tabatkins has 1 min or 2, I would be very happy to have his opinion on this.

[travco]

I'll put this here so it doesn't need to be repeated...

---

tabatkins commented on May 4 in postcss#321:

@extend, as defined in the draft, cannot be emulated by a preprocessor. It's impossible, due to the way specificity works. @extend, as Sass does it, is slightly different - specificity is different, and it has to use a number of heuristics to limit the combinations it actually generates to those most likely to be useful. ...

---

[travco]

I think tabatkins may be understandably busy to drop in on this one @MoOx.

[MoOx]

Probably, like I am :) Meanwhile, you can use it via the cssnext plugins option.

[stevenvachon]

@tabatkins yo... save us.

[tabatkins]

@travco's quote from me is correct - @extend, as defined in the spec, cannot be done in preprocessor (just like var() can't be done in a preprocessor), as it depends on live-page information/integration with the browser.

If you want to add @extend to PostCSS, just copy what Sass has done, which is a decent approximation of a "proper" @extend.

[MoOx]

@travco I don't use extends so I am not the best person to choose if this is "safe" to add. For example custom props transformation is limited to root to make a "safe but incomplete" transformation, that should work the same in browsers when they will implement custom props. Can we say the same of you extend plugin, or will the result can change when the transformation of your plugin will be handled by a browser?

[perrin4869]

Sorry if this question is stupid, but at first glance I can't see the difference between @extend and @apply... what are the different use-cases?

[travco]

@perrin4869 @apply operates very similar to var() except it can hold sets of declarations instead of values (as per it's spec). In addition, custom sets of properties you reference in an @apply overwrite each-other if you redefine them.

@extend allows you to take another rule's declarations as a template, and if needed modify/replace them in specificity. As well as extend other things that are (themselves) extending, and use sub-classes of the extended thing. As a result you can 'pull' from multiple sources with only a single line, with expectable results.

TLDR- They're both fruit for your syntactic sugar. If you need fruit, either -can- (more or less) perform the same task but @apply has a more restricted rule set and would require many more lines to do the same thing.

[tabatkins]

Right. They can both achieve the same simple cases, but each has more complex cases that are specific to them. This is mostly due to how they move information from opposite sides - @apply gets set up by the outer page and pushed into components, @extend is the component pulling styles in without the outer page having to do anything or even know it's occurring.

[travco]

that should work the same in browsers when they will implement custom props. Can we say the same of you extend plugin, or will the result can change when the transformation of your plugin will be handled by a browser?

@MoOx Sorry for missing an opportunity to reply, all of the features included in postcss-extend at current fall into one of two categories:

• "safe, but limited" because a fully-fledged representation is either impossible in a pre-processor or too computationally complex to either implement/calculate. An example being behavior around @media tags - where only what can by done by the preprocessor is done, and what can't isn't.
• A 'bonus' feature accompanied by both a warning and an entry in the README. An example being the ability to extend in an anti-pattern which will never make it's way to the browser, and throws a warning on use. Another example being the ability to preserve specificity of the extended rule (reference Example 5 in spec), which can't really be done by a preprocessor without also modifying your HTML (out of scope).

TLDR- Implementation is 'safe' and representative of per-spec browser behavior if the user follows directions and doesn't ignore warnings.

[Shyam-Chen]

.foo {
  color: red;
}

.bar {
  @extend .foo;
  background: green;
}

.baz {
  @extend .bar;
  padding: 1rem;
}

---

:root {
  --foo: {
    color: red;
  };
}

.foo {
  @apply --foo;
}

.bar {
  @apply --foo;
  background: green;
}

.baz {
  @apply --foo;
  background: green;  // need to write again
  padding: 1rem;
}

[Shyam-Chen]

https://github.com/johnotander/css-extend

[jonathantneal]

Where are we at with travco/postcss-extend? Is this still in evaluation?

[MoOx]

From what I know, it won't be a safe transformation. But if some people want to dig deeper, please share your investigations here.

[MoOx]

postcss-cssnext has been deprecated in favor of postcss-preset-env. Read more at https://moox.io/blog/deprecating-cssnext/