Add vars to media-queries

[zoepage]

https://www.npmjs.com/package/postcss-media-variables

[zoepage]

This is failing for me, so lets postpone that issue as its not blocking. If anyone wants to take over, feel free. :)

[magsout]

After updated postcss-* and added postcss-media-variables

Running "watch" task
Waiting...
>> File "webcompat/static/css/src/grid.css" changed.
Running "postcss:dist" (postcss) task
Node#before is deprecated. Use Node#raws.before
>> 1 processed stylesheet created.

Done.

So I think there is a package which is not updated for the postcss version 6..

[magsout]

I'm reading that https://github.com/postcss/postcss-custom-properties/issues/24 and https://github.com/MoOx/postcss-cssnext/issues/253

Not sure it's a good idea to add this kind of plugin.

@zoepage @miketaylr ?

[magsout]

Maybe we can just add custom-media-queries in variables.css and let the comment to rely on the var(--page-size-m) like this

// rely on var(--page-size-m)
@custom-media --page-min-size-m (max-width: 665px);

and use as:

@media (--page-min-size-m) {
  .grid-row {
    margin: 0 calc(-1 / 2 * var(--unit-space)) var(--grid-outermargin-m);
  }

  .grid-show-gap .grid-cell {
    margin-bottom: var(--grid-outermargin-m);
  }

  .x1-fix {
    max-width: var(--unit-modul-s);
  }
}

[miketaylr]

Yeah, I dunno. If it's a current limitation of CSS, maybe it's just better to live with it.

[magsout]

@miketaylr the good thing, we can update postcss with latest versions without error ;)

[Regaddi]

Even though CSS custom properties are a nifty feature, maybe porting some code to Sass might be valid? I know it's another layer in the toolchain. But this would completely allow usage of functions, mixins, nesting and variables everywhere you need it. It will also help making the code more DRY. However, when it comes to nesting styles, I'm a big fan of BEM to avoid over-nesting. There are also ready-to-use stylelint configs available.

Porting to Sass is pretty easy, since CSS is completely valid Sass code.

[magsout]

@Regaddi to clarify my comments, I'm not a big fan of Sass, not anymore, I used Sass couple of years.

The question is What can we do with Sass we can not do with css?

IMO, Sass is motly another layer writing a subset of css. it helps writing css wich is repeating but that's it.

[Regaddi]

The question is What can we do with Sass we can not do with css?

We can use vars in or for media queries and solve this issue 😅

Joking aside, CSS has matured a lot in the last few years and I'm really happy about this evolution. One thing that I still dislike is that I have to repeat parts of my selectors over and over again. But this is probably just personally. If I have the opportunity to do the same thing with less code, why not? 😄

So basically yes, Sass is mostly another layer of CSS, but IMO a pretty convenient one for developers.

In the end it's an architectural decision and I just wanted to drop my ideas 😄

[magsout]

@Regaddi

We can use vars in or for media queries and solve this issue 😅

good point 👍

If I have the opportunity to do the same thing with less code, why not? 😄

another good point

So basically yes, Sass is mostly another layer of CSS, but IMO a pretty convenient one for developers.

yes, it is.

In the end it's an architectural decision and I just wanted to drop my ideas 😄

and you're totaly right, it's a good thing ;) thanks for that.

[zoepage]

To give some context, we didn't see a need for SASS before. This is why we also didn't use it. I think, the option for usage of functions, mixins, nesting and variables is a pro on using it.

My only concern is that SASS can blow up the code massively (as already mentioned), this is why I really like the OOCSS approach, which goes well with React as well as other frameworks. BEM is something we decided against as its a design pattern that has been used in various ways by developers and although there is a very clear definition of it, devs like to use it in their versions (my experience in the past few years and various projects).

As OOCSS is already the base and BEM would also include a re-factor of the CSS, I'd be contra BEM, but okay with SASS.

[miketaylr]

To me it feels like switching to SASS to solve this one issue feels like a bit much. I'm a respectful -1, though I appreciate the PR and contribution from @Regaddi.

[Regaddi]

@miketaylr It is not really solely solving this particular issue. With Sass we're able to establish a clean stylesheet architecture, which can't be achieved with pure CSS in a satisfying way. Sass allows to strictly divide the stylesheet code into configurational, reusable and applying parts. It allows to e.g. abstract the styles for labels without duplicating CSS code (as we currently do). So for this particular issue here the switch seems like a big cannonball, but in the long-term I can see great advantages.

[zoepage]

The biggest advantage I see it the normalisation of margins / paddings and gaps between the grid elements through functions that can live in one place and be reused. solving the breakpoints issue is a bonus for me.

[miketaylr]

With Sass we're able to establish a clean stylesheet architecture, which can't be achieved with pure CSS in a satisfying way.

This feels a bit subjective, since clean and satisfying mean different things to each of us. :)

Sass allows to strictly divide the stylesheet code into configurational, reusable and applying parts.

Yeah, this could be good. I feel like we should consider this at some point, and maybe collect concrete use cases for it now, but I don't see that we need it today.

Related, https://engineering.linkedin.com/blog/2018/04/css-at-scale--linkedins-new-open-source-projects-take-on-stylesh is an interesting read. Obviously we're not at LinkedIn scale, but they list some problems they had with bloat caused by using Sass mixins and the like.

[miketaylr]

I'm going to WONTFIX this, we can revisit if we feel like we need it.