Nested classes in @responsive directive getting prefixed

[oscaralexander]

I decided to start rewriting our (SASS) toolkit, starting off with my grid class. It's all BEM based, and I ran into the following unexpected/undesired behavior.

I have a SASS map named $grid-gaps that has key/values pairs (e.g. xs: 0.5rem). I loop over them to set the appropriate gap modifiers and wrap them in a @responsive directive so they become responsive:

.o-grid {
    ...

    @each $key, $val in $grid-gaps {
        @responsive {
            &--gap-#{$key} {
                margin: ($val * -0.5);

                .o-grid__col {
                    padding: ($val * 0.5);
                }
            }
        }
    }
}

However, the code above also creates responsive prefixes for the child classes, yielding the following:

.l\:o-grid--gap-xs {
    margin: -0.25rem;
}

.o-grid--gap-xs .l\:o-grid__col {
    padding: .25rem;
}

Instead of the output I desired/expected:

.l\:o-grid--gap-xs {
    margin: -0.25rem;
}

.l\:o-grid--gap-xs .o-grid__col {
    padding: .25rem;
}

I guess my understanding of @responsive isn't correct, but this felt like a bug to me.

[benface]

It used to give the output you desired/expected, but it was changed in #497 to fix an issue with group-hover + responsive variants.

[adamwathan]

Hey @oscaralexander! This is a fairly annoying/complex issue so bear with me as I do my best to explain the reasons it works this way as well as possible solutions.

As @benface mentioned, it did used to work the way you are requesting, but we needed to change it to prefix the last class in a selector instead of the first one because it felt really unintuitive with our built-in group-hover feature.

There are probably just as many cases where it feels unintuitive to prefix the last class as it does the first though, like you've pointed out here.

Ultimately if we didn't have group-hover as a feature in Tailwind, I would probably make it so that trying to apply @responsive to any selector that isn't just a simple one-class utility would throw an error, because really the @responsive feature is meant for super simple utility classes like bg-red rather than more complex component classes like what you are doing with your grid stuff.

So possible solutions:

1. Use CSS Grid

If you can't use CSS Grid due to browser support (it's basically a no-go in IE11 but fine in Edge and everything else) then ignore this :)

The nice thing about CSS Grid is that gutters are specified on the parent element, so you don't have to worry about this multi-class selector stuff.

You'd just have to write something like:

.o-grid {
  display: grid;
}

@each $key, $val in $grid-gaps {
  @responsive {
    .o-grid--gap-#{$key} {
        grid-gap: $val;
    }
  }
}

We also have an example of a CSS grid plugin you could use with Tailwind too.

2. Write a plugin

Most of the stuff that I would have historically done in Less or Sass I now do with plugins in Tailwind. This lets me use JavaScript to do all the looping/variables/class name generation/etc instead, and gives me access to anything I need from the Tailwind config.

The nice thing about using a plugin for your current problem is that you could bypass the @responsive stuff completely so you have full control over where the prefixes are added.

Replacing your Sass code with a Tailwind plugin would look something like this:

// grid-plugin.js
const reduceCalc = require('reduce-css-calc')

module.exports = function(options) {
  function calc(string) {
    return reduceCalc(`calc(${string})`)
  }

  return function ({ addComponents, config }) {
    const buildGridComponents = (prefix) => {
      return {
        [`.${prefix}o-grid`]: {
          // ...
        },
        ...Object.assign({}, ...Object.entries(options.gridGaps).map(([key, val]) => {
          return {
            [`.${prefix}o-grid--gap-${key}`]: {
              margin: calc(`${val} * -0.5`)
            },
            [`.${prefix}o-grid--gap-${key} .o-grid__col`]: {
              padding: calc(`${val} * 0.5`)
            },
          }
        }))
      }
    }

    const components = {
      ...buildGridComponents('', options.gridGaps),
      ...Object.assign({}, ...Object.entries(config('screens')).map(([screen, size]) => {
        return {
          [`@screen ${screen}`]: buildGridComponents(`${screen}\\:`, options.gridGaps)
        }
      }))
    }

    addComponents(components)
  }
}

And you'd use it in your config file like this:

modules.exports = {
  // ...
  plugins: [
    // ...
    require('./my-plugins/grid-plugin')({
      gridGaps: {
        xs: '.25rem',
        sm: '.5rem',
        md: '1rem',
      }
    })
  ]
}

All that said I think we could make this sort of thing simpler by providing some helper functions for common stuff like "generate media query versions of these classes, applying the prefix to the nth class in the selector" but this is how I would do this today.

Again the main reason for the complexity is just that it's impossible to guess what the user really wants, because prefixing just the first class is just as valid as prefixing just the last class is just as valid as prefixing all classes, all depending on what you are trying to do.

The other thing to consider is that @responsive will intelligently group all media queries at the end of the stylesheet, whereas for component classes like this you probably don't want that behavior, because you want to be able to override them with utilities. That's why our built-in container component has it's own media queries that are defined before the utilities 👍

Anyways hope that is helpful, I'm on vacation in Australia with the fam right now so going to go to the beach 😅

[benface]

Hey @adamwathan, great idea, but I'm curious how this works:

        return {
          [`@screen ${screen}`]: buildGridComponents(`${screen}\\:`, options.gridGaps)
        }

Tailwind processes directives like @screen after the plugins? If so, wouldn't that try to add responsive prefixes to classes that already have them?

Also, buildGridComponents() only takes one argument the way you've written it but you give it two.

[adamwathan]

Tailwind processes directives like @screen after the plugins?

Yep!

If so, wouldn't that try to add responsive prefixes to classes that already have them?

Well with component classes added via plugins, you can't specify variants like you can with utilities anyways:

https://tailwindcss.com/docs/plugins#responsive-and-state-variants-1

Tailwind doesn't generate responsive variants for component classes at all either way, so they won't get double added.

If you were manually doing this sort of thing with utilities added by a plugin then yeah that could happen if you also told the plugin to generate responsive versions of the already responsive classes, but you have to do that explicitly, it's not something that can just happen by accident. There's no reason to be manually adding your media queries for utilities added by a plugin anyways, only really makes sense for components.

You can see the built-in container component manages media queries on its own too, just like this grid example we're talking about:

https://github.com/tailwindcss/tailwindcss/blob/master/src/plugins/container.js#L31-L39

Also, buildGridComponents() only takes one argument the way you've written it but you give it two.

Mistake from rushing it, was refactoring a bit and didn't change that 👀

[oscaralexander]

First of all, @adamwathan, thanks for taking the time out of your holiday to respond so elaborately! Really appreciate it.

I'll look into CSS grid and see if it can mimic the things our current grid system does (e.g. wrapping). I only have some basic experience with it.

At the same time, I'm wondering if a @group-responsive would be a logical directive to add to fix the root of the problem and not this particular instance?

[adamwathan]

Going to close this as intended behavior, although I'd like to make it possible to have more control over this in the future.

[davojan]

I have different issue but I'm pretty sure it is closely related.

This code was OK in 0.x but doesn't build while I'm trying to migrate to 1.x:

@variants responsive {
  .btn-default {
    @apply text-primary bg-white border-primary;

    &:hover, &:focus {
      @apply text-white bg-primary-lighter;
    }
  }
}

with error

SyntaxError

(69:5) Variant cannot be generated because selector contains no classes.

  67 |     @apply text-primary bg-white border-primary;
  68 | 
> 69 |     &:hover, &:focus {
     |     ^
  70 |       @apply text-white bg-primary-lighter;
  71 | 

Looks like postcss-nested can't be used inside @responsive or @variants responsive at all.

This is breaking change in 1.x that is not mentioned in migration guide.

Isn't it a bug? If not, what is the preferred workaround for this? Should I write a plugin just to style buttons differently on different screen size?

[adamwathan]

Make sure postcss-nested comes before Tailwind in your list of PostCSS plugins, I think that will fix it.

…

On Jul 27, 2019, 5:20 PM -0400, David ***@***.***>, wrote: I have different issue but I'm pretty sure it is closely related. This code was OK in 0.x but doesn't build while I'm trying to migrate to 1.x: @Variants responsive { .btn-default { @apply text-primary bg-white border-primary; &:hover, &:focus { @apply text-white bg-primary-lighter; } } } with error SyntaxError (69:5) Variant cannot be generated because selector contains no classes. 67 | @apply text-primary bg-white border-primary; 68 | > 69 | &:hover, &:focus { | ^ 70 | @apply text-white bg-primary-lighter; 71 | Looks like postcss-nested can't be used inside @Responsive or @Variants responsive at all. This is breaking change in 1.x that is not mentioned in migration guide. Isn't it a bug? If not, what is the preferred workaround for this? Should I write a plugin just to style buttons differently on different screen size? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[davojan]

Thanks for quick reply @adamwathan.

I've tried that already and it was ok. But unfortunately it breaks another important thing:

.block-content {
  @apply relative rounded-sm px-3;
  @screen sm {
    @apply px-5;
  }
}

This will produce broken output if tailwind plugin is placed after postcss-nested:

.block-content {
  position: relative;
  border-radius: 0.125rem;
  padding-left: 0.75rem;
  padding-right: 0.75rem;
}

@media (min-width: 576px) {
  @apply px-5;
}

With this config

plugins: [
  require('postcss-nested')(bubble: ['screen']),
  require('tailwindcss')('tailwind.config.js'),
]

🎉 Good news! 🎉

While writing this reply I've found hacky solution 🙂: removing bubble: ['screen'] and applying postcss-nested two times - before and after tailwind:

plugins: [
  require('postcss-nested')(),
  require('tailwindcss')('tailwind.config.js'),
  require('postcss-nested')(),
]

With this config css output looks like expected (and was in 0.x).

While the solution is ok (I don't think it will increase build time significantly), this still looks like a bug. Docs suggest to put postcss-nested after tailwindcss for the good reason.

[adamwathan]

Finally had a chance to look at this on my computer and play with it and it's definitely a bug. Just pushed a PR to fix:

#1053

[iSWORD]

Is solution no. 2 proposed above still the best way to do it? It's confusing without lodash. Can someone help me understand what's going on?

Thank you,

[iSWORD]

Here's what I'm trying to do:

const _ = require('lodash');

module.exports = function () {
    return ({theme, variants, e, addUtilities}) => {
        const vselectVariants = variants('vselect', {});

        const colors = theme('colors', {});

        const selectedColors = _.map(colors, (value, name) => {
            return {
                [`.${e(`v-select-selected-text-${name}`)}`]: {
                    '.vs__selected': {
                        'color': value,
                    },
                },
            }
        });

        addUtilities(selectedColors, vselectVariants);
    };
};

Here's what I'm ending up with:

.v-select-selected-text-grey-lightest .vs__selected {
  color: #f8fafc;
}

@media (min-width: 576px) {
  .v-select-selected-text-grey-lightest .sm\:vs__selected {
    color: #f8fafc;
  }
}

@media (min-width: 768px) {
  .v-select-selected-text-grey-lightest .md\:vs__selected {
    color: #f8fafc;
  }
}

@media (min-width: 992px) {
  .v-select-selected-text-grey-lightest .lg\:vs__selected {
    color: #f8fafc;
  }
}

@media (min-width: 1200px) {
  .v-select-selected-text-grey-lightest .xl\:vs__selected {
    color: #f8fafc;
  }
}

and here's what I wish it had generated:

.v-select-selected-text-grey-lightest .vs__selected {
  color: #f8fafc;
}

@media (min-width: 576px) {
  .sm\:v-select-selected-text-grey-lightest .vs__selected {
    color: #f8fafc;
  }
}

@media (min-width: 768px) {
  .md\:v-select-selected-text-grey-lightest .vs__selected {
    color: #f8fafc;
  }
}

@media (min-width: 992px) {
  .lg\:v-select-selected-text-grey-lightest .vs__selected {
    color: #f8fafc;
  }
}

@media (min-width: 1200px) {
  .xl\:v-select-selected-text-grey-lightest .vs__selected {
    color: #f8fafc;
  }
}