v3.0 discussion

[MoOx]

I am thinking about:

• add stage/level option How should we handle "level"/stability of features? #100 by default (and maybe disable some plugins?)

Any other ideas?

---

To merge and release for v3

• color function: tint, shade, and contrast adjusters have unexpected results when used with alpha adjuster #337
• bump deps #333
• Upgrade postcss-apply dependency #318 (@apply update and breaking change)
• bump postcss-color-function to latest (small major change)

[jonathantneal]

Looks great. My two cents:

• I wouldn’t let new features (How should we handle "level"/stability of features? #100) prevent major dependency updates.
• I would pull @apply (Upgrade postcss-apply dependency #318) and :any-link (bump deps #333) and call that the next release.

What might you need from us to move forward?

[simonkberg]

Regarding #333, which would require dropping support for every node version below 6:

I don't personally use Node v4 for any active projects currently, but I would just like to clarify that there are two active LTS branches, and v4 won't enter maintenance mode until April this year, which it will stay in for 12 months until finally reaching its EOL in April 2018.

So: dropping support for Node v4 doesn't affect me personally, but it does however affect the stability of the ecosystem, which is something to take into consideration. It still also has wide usage.

From a quick look at postcss-pseudo-class-any-link it seems like the destructuring and
default function parameter is the only thing preventing v4 compatibility.

[MoOx]

Indeed, just this small syntax sugar should be replaced for a better compat imo!

[MoOx]

FYI https://twitter.com/MoOx/status/826674905215336450

[MoOx]

@jonathantneal for #100 this is not just a new feature, but will be a breaking change as we will probably disable some by default ( or maybe at least in another major version...)

[jonathantneal]

Happy to add compat if someone can show me a pattern for producing a v4 and v6 version.

Unrelated question. Will v6 leverage browserslist?

[MoOx]

browserlist is already used (maybe not the latest version...)

[MoOx]

Time to remove apply? http://www.xanthir.com/b4o00

[Semigradsky]

Is there any likelihood that nesting specification will become official? Or we should remove it too?

[pascalduez]

Time to remove apply? http://www.xanthir.com/b4o00

I would say so...
Users heavily relying on it can always add the plugin in standalone mode.

More links:
https://discourse.wicg.io/t/needed-new-champion-for-css-apply-rule/2012
WICG/webcomponents#300 (comment)

[dbox]

Time to remove apply? http://www.xanthir.com/b4o00
Is there any likelihood that nesting specification will become official? Or we should remove it too?

Let me start this by saying I love cssnext and give a huge thanks to everyone involved.

I know it's been discussed before but the major issue here is that CSSWG has no real "stages" of completion. @jonathantneal has tried to spearhead a new system for this: https://github.com/jonathantneal/css-db. But until CSSWG and cssnext can be more aligned, then the concept of cssnext doesn't work.

The concept, at least how it's presented, and how I initially understood, it was to write "future-proof" css. But that can't be done if we're allowing uncertain specs in.

IMHO the only way cssnext is relevant is to be very sure the spec'd features are actually coming, and CSSWG makes this almost impossible until the features are essentially available all browsers.

I want nothing more than to use nesting and apply (or whatever mixin solution comes next), but the archaic and crawling pace of csswg has our hands tied. Apply and nesting were, imho, the last 2 things needed to really ditch standard preprocessors and move to a fully standards-compliant workflow.

I don't have any solutions really, other than wondering if there is some way we can as a group pressure CSSWG for more transparency/teamwork or to get them on a better system like @jonathantneal has suggested.

Does anyone have contacts within CSSWG that could get the latest status update on nesting? (Clearly apply has to be removed now - it's dead. 😞 )

[pepelsbey]

If I may, I’d really recommend cssnext to focus on future-proof promise it once gave us. To become a Babel to CSS. It requires setting a strict bar to determine what to support: Tab’s napkin-drafts or something ready to be implemented or already implemented by browsers (I’d prefer the second). You could always abstract out all nesting fantasies to PostCSS plugins for everyone eager to use it, while keeping project truly cssnext, not cssfantasies.

[jonathantneal]

@pepelsbey, @apply was a unique situation. For a time it seemed like one of the ”safer“ features within cssnext, as Chrome had already implemented it behind a flag. We only later learned the csswg had never given it a formal blessing after Tab lost interest and a few of us requested it be given a new champion.

I’d love an opportunity to “sit down” with csswg members and walk through the drafts we‘ve implemented to see where they rest on some scale of realism. With such information, we really could do something like babel, including the introduction of stages.