Feature proposal: `children` variant

[benface]

The idea would be to be able to do things like this:

Input CSS

@variants children {
    .block { ... }
}

Output CSS

.children:block > * { display: block; }
.block { display: block; }

Note: All children: variants would need to be output before the normal rule-sets so children can override rules defined by their parent (.class and .class > * have the same specificity).

HTML

<div class="children:block children:my-1">
    <a>
        I am a block with some vertical margin
    </a>
    <a>
        Me too
    </a>
    <a class="mb-0">
        I don't have bottom margin
    </a>
</div>

Advantages

• Less repetition in the HTML (easier to change things that should be changed together)
• Easier to read
• Smaller HTML file size

I think this would be particularly useful for grids and lists. What do you think?

[sebastiandedeyne]

I'd like to see this to plop on parent elements of things like generated menus.

Also, first-child and last-child variants would be welcome additions too.

[adamwathan]

Happy to look at a PR for this, I think it's a cool idea 👍

[fedetibaldo]

@aparajita In regards to variants order, I'd invite you to post on #392. This kind of thoughts will become more and more frequent as people keep suggesting and implementing new variants. Starting to group them would be useful IMO.

In regards to subtituteAtVariantRule.js, I would suggest splitting the two features into two very distinct pull requests: the first, more verbose, to implement the three variants, the second to refactor the cited script.

[benface]

@aparajita Do you also have children:hover, children:active, etc.? I think those would be quite useful.

[benface]

@aparajita Why? I would like to use it for things like this:

<nav class="children:block children:p-2 children:bg-blue children:hover:bg-blue-light">
    <a>
        Home
    </a>
    <a>
        About
    </a>
    <a class="bg-orange hover:bg-orange-light">
        Log In
    </a>
</nav>

[benface]

@aparajita

my understanding is that Tailwind is designed to avoid cascade and specificity issues

Mostly, but it still relies on the cascade for some things, like generating the hover and focus variants of each property after the property itself.

In fact your example won't work — because the children:bg-blue selector in the parent has a higher specificity than the bg-orange selector in the child, the child override has no effect.

Wrong. Please read the original post of this issue; I mention why that's not a problem:

Note: All children: variants would need to be output before the normal rule-sets so children can override rules defined by their parent (.class and .class > * have the same specificity).

EDIT: I'm not sure why @aparajita deleted his comments, but I swear I wasn't talking to myself!

[fedetibaldo]

In there any specific use case where children is actually necessary?

I mean, to avoid any kind of issue and doubt, we could force developers to apply classes directly to the child elements by leaving out the children variant from the PR

[benface]

It's never necessary, no. This feature proposal is 99% about improving developer experience, which I believe is aligned with Tailwind's goal.

[fedetibaldo]

Suppose you have a blue table where the last and first rows are red. With the current version of Tailwind, you would style those rows manually, right? So you build the table, insert three rows and complete the job.
Later, another developer gets the task of adding a row to the table. Unfortunately, he misinterprets the design and he appends a blue row instead of shifting the red one.

In this scenario, first-child, last-child or even/odd-child would surely have granted a better developer experience, letting an uninformed developer make the right choice without any kind of documentation beforehand.

On the other hand, children doesn't create better developer experience. It creates a choice in your workflow:

should I delegate styling to the parent or to the child?

The answer is always the same: the former creates limitations (e.g. hover is not applicable via the parent with the current solution), so the ladder is the preferred way.

Why creating one-way choices? Isn't that a bad developer experience?

[benface]

Suppose you have a table where all rows are exactly the same. With the current version of Tailwind, you would style those rows manually. Later, you need to change the padding of the rows. If you have 100 rows, you have to change it 100 times (assuming you're not using any templating language/system). Surely the children variant would have granted a better developer experience?

[fedetibaldo]

After the first repetitions, you likely created an @apply rule, making the changing problem pretty trivial

[benface]

Depends on what you consider worthy of a "component" (i.e. a custom CSS class using @apply). If I'm only using this table on one page, I probably wouldn't create one. This is very subjective of course.

I'm not sure what we're debating exactly. Do you propose adding the -child variants without the children variant? I would find this confusing:

<div class="first-child:bg-red last-child:bg-red">
    <div class="bg-blue">
        I'm red.
    </div>
    <div class="bg-blue">
        I'm blue.
    </div>
    <div class="bg-blue">
        I'm red.
    </div>
</div>

[OwenMelbz]

@fedetibaldo @benface

To cut the discussion short... If there's no downside to doing it - and it just enables more flexibility for people to do things with how their team feel comfortable, there should be no argument, the facility should be available.

The question might be should it built into the core or a plugin which is importable.

If there are people who have found there is a use case for it - then there's no reason to not to.

The tricker bit is finding somebody who can support this.

@adamwathan has suggested he's open to a PR for it, which suggests if somebody has time and it is implemented nicely, it will be accepted, as his life/project roadmap might not be suitable for him to add right now himself.

--

Is anybody except Adam able to provide a PR right now?

If not - Adam is this something down the line you think you're likely to add yourself?

<3 for tailwind

[benface]

Thanks @OwenMelbz. I don't think it's possible to create custom variants with a plugin at the moment, so if Adam likes the idea, I think this should be in the core. One problem I can think of is CSS bloat though. If we want maximum flexibility, it would require the addition of quite a few variants:

• children:
• [screen]:children: (responsive variants)
• children:hover:
• [screen]:children:hover:
• children:focus:
• [screen]:children:focus:
• children:active:
• [screen]:children:active:
• first-child:
• [screen]:first-child:
• first-child:hover:
• [screen]:first-child:hover:
• first-child:focus:
• [screen]:first-child:focus:
• first-child:active:
• [screen]:first-child:active:
• last-child:
• [screen]:last-child:
• last-child:hover:
• [screen]:last-child:hover:
• last-child:focus:
• [screen]:last-child:focus:
• last-child:active:
• [screen]:last-child:active:
• odd-child:
• [screen]:odd-child:
• odd-child:hover:
• [screen]:odd-child:hover:
• odd-child:focus:
• [screen]:odd-child:focus:
• odd-child:active:
• [screen]:odd-child:active:
• even-child:
• [screen]:even-child:
• even-child:hover:
• [screen]:even-child:hover:
• even-child:focus:
• [screen]:even-child:focus:
• even-child:active:
• [screen]:even-child:active:

That's ((20 + 20 * the number of screens) * the number of utilities that have those variants enabled) new classes. I imagine that can be quite considerable even with the default config. Maybe we could skip the responsive and state sub-variants at first, but I think it would be frustrating to not have that flexibility and could potentially turn people off of this feature.