hidden in v4 no longer overrides all display classes

[staaky]

Combining hidden with inline-flex, inline-block etc. no longer hides an element in v4.

In v3 hidden was the bottom display class in css, so it would override the others when combined.

In v4.0.6 the order seems alphabetical, so that breaks things.

<span class="inline-flex hidden">hidden in v3, visible in v4</span>

v3	v4.0.6

[wongjn]

See #15884 (comment)

[staaky]

Thanks, I've commented there #15884 (comment), even with it being closed, since Philipp mentioned the breaking change was made "for now", seems like it's still up for discussion. I expect I won't be the last to run into this.

I'll summarize the arguments for keeping hidden last:

• Consistency - With block, flex and grid, you now have different behavior in v4:

<span class="block hidden">hidden in v3 and v4</span>
<span class="inline-flex hidden">hidden in v3, visible in v4</span>

• Composability - Components often have their own display class, being able to add hidden and always have it work helps with composability. It was also mentioned that two display classes should not be added in the same context, and that the IntelliSense extension warns about this. In practice though hidden is often added in a separate context, so there won't be any warnings:

// renders as `inline-flex hidden`, without IntelliSense warning
<Component className={'hidden'} />

function Component({ className }) {
    return <div className={classNames('inline-flex', classname)} />;
}

• The push for switching to the hidden attribute might assume attributes can be modified as easily as classes. This isn't always the case given how things are composed in frameworks. Third-party components might not allow attribute modification, so you'll have to resort to wrappers.

const ImportedFromNpm = ({ className }) => <div className={className}>hi from npm!</div>;

// can't assign hidden attribute
<ImportedFromNpm hidden />

• With Tailwind being a CSS framework, should it even be opinionated on the use of attributes over classes? Wouldn't it be better to ensure classes work consistently regardless?

[philipp-spiess]

@staaky Thanks for sharing your points on this, it's always great to hear more opinions and we invite everyone else who feels strongly about this to join our discussions. That said, let's keep the discussion around this topic in the existing (for now closed) issue so it's easier for us to keep track of everything.

[staaky]

@philipp-spiess no problem, hope you reconsider. If you’d like more feedback I suggest mentioning the breaking change in the upgrade guide.