Beta test the new features coming in Tailwind CSS v3.2 #9504
Replies: 9 comments 19 replies
-
Though I understand the use-case, I can't possibly imagine writing |
Beta Was this translation helpful? Give feedback.
-
Hello |
Beta Was this translation helpful? Give feedback.
-
Some comments on
See this TailwindPlay
{
t: "top",
r: "right",
b: "bottom",
l: "left",
} should be under {
values: {
t: "top",
r: "right",
b: "bottom",
l: "left",
}
} |
Beta Was this translation helpful? Give feedback.
-
I like the use of / as it conceptually feels like system folders and
makes sense being a subset of the former
…On Sun, Oct 9, 2022 at 6:40 AM Brandon McConnell ***@***.***> wrote:
Personally, I feel like using a dot . feels to similar to a plain CSS
class name which this is not, so I’d want to avoid that.
@adamwathan <https://github.com/adamwathan> What are the factors you’re
considering in the placement/order of hover in group<label>-hover and
group-hover/label. Why in one is the label director after group but after
the hover in the other? Would these two concepts have the same effect?
—
Reply to this email directly, view it on GitHub
<#9504 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA7WGVEUVTRS7DGWKZ34DDWCLDM5ANCNFSM6AAAAAAQ7WS4Z4>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
Is it expected to get the following error with
|
Beta Was this translation helpful? Give feedback.
-
I have integrated it into a project, and everything runs smoothly. Especially the |
Beta Was this translation helpful? Give feedback.
-
Exciting stuff ! 👌 I see a nice opportunity for out-of-the-box support of |
Beta Was this translation helpful? Give feedback.
-
Great! Like the Multiconfig feature a lot. Its great for special sites within a site like a Conference website. Thanks for that! 🔥 |
Beta Was this translation helpful? Give feedback.
-
is the nested group syntax available on the playground yet? and using which format ? |
Beta Was this translation helpful? Give feedback.
-
Hey everyone! We're planning to release Tailwind CSS v3.2 in the next couple of weeks, and we'd love to get some more people flexing the new features we're working on before we tag it and can't turn back.
A lot of the new things we've been working on this time around involve brand new syntax and concepts. With Tailwind being such a widely used tool these days, we'd really love for people to put this stuff to test ahead of the release and make sure we aren't making any API decisions that create really painful integration problems when working with tools we don't use ourselves.
To install the latest pre-release, install our insiders build from npm:
You can also try the new features directly in Tailwind Play by choosing "Insiders" from the version dropdown, but it's better for us if you actually install it in your project so we can get more information about how all this stuff is going to work alongside different UI libraries, templating languages, and build tools.
Here's a breakdown of the new stuff we'd love some help putting through its paces!
@config
@supports
rulesgroup-[...]
andpeer-[...]
variantsmatchVariant
group
and multiplepeer
support using <labels>Multiple config files in one project using
@config
We've added a new
@config
directive that you can use in a CSS file to specify which Tailwind CSS config to use for that file:This makes it a lot easier to build multiple stylesheets in a single project that have separate Tailwind configurations. For example, you might have one config file for the customer-facing part of your site, and another config for the admin/backend area.
Config files specified with
@config
are resolved relative to the CSS file where the@config
directive is being used.One known pain-point right now is that when using
postcss-import
, you can't put@config
at the top of the file becausepostcss-import
is strict about all@import
statements having to come first as per the CSS spec. We might wrappostcss-import
with our own import plugin to remove this limitation, but for now if you're using@import
statements, your@config
directive will need to come after them:The Tailwind CSS IntelliSense plugin also doesn't have support for this stuff in any sort of automatic way yet, so you might not see the completions you expect depending on how you have things configured. We're working on this though, and hope to have a solution in place before the actual v3.2 release.
New variant for
@supports
rulesYou can now conditionally style things based on whether a certain feature is supported in the user's browser with the
supports-[...]
variant, which generates@supports rules
under the hood.The
supports-[...]
variant takes anything you'd use with@supports (...)
between the square brackets, like a property/value pair, and even expressions usingand
andor
.For terseness, if you only need to check if a property is supported (and not a specific value), you can just specify the property name:
Dynamic
group-[...]
andpeer-[...]
variantsWe're making it possible to create custom
group-*
andpeer-*
variants on the fly by passing your selector between square bracketsWhatever you pass will just get tacked on to the end of the
.group
or.peer
class in the selector by default, but if you need to do something more complex you can use the&
character to mark where.group
/.peer
should end up in the final selector relative to the selector you are passing inParameterized variants with
matchVariant
Both the new
supports-[..]
feature and dynamicgroup-*
/peer-*
variants are powered by a newmatchVariant
plugin API that you can use to create your own dynamic/parameterized variants.Here's an example of creating a
placement-*
variant for some imaginary tooltip library that uses adata-placement
attribute to tell you where the tooltip is currently positioned:The variant defined above would give you variants like
placement-t
andplacement-b
, but would also support the arbitrary portion in square brackets, so if this imaginary tooltip library had other potential values that you didn't feel the need to create built-in values for, you could still do stuff like this:When defining a custom variant with this API, it's often important that you have some control over which order the CSS is generated in to make sure each class has the right precedence with respect to other values that come from the same variant. To support this, there's a
sort
function you can provide when defining your variant:Nested
group
and multiplepeer
support using <labels>Sometimes you can run into problems when you have multiple
group
chunks nested within each other because Tailwind has no real way to disambiguate between them.To solve this, we're trying out this new idea called labels, which are a new dynamic chunk that lives in the variant that you can use to give each group/peer your own identifier.
Here's what it looks like:
This lets you give each group a clear name that makes sense for that context on the fly, and Tailwind will generate the necessary CSS to make it work.
I'm really excited to have a solution out there for this because it's something I've been trying to land on a good approach for solving for several years, and this is the first thing we've come up with that really feels like it offers the power and flexibility I think it should.
This feature is probably the riskiest one in terms of creating issues with different tools though, because we're using new characters in the class names (
<
and>
). So really flex this one and see how it works for you in your projects with the other libraries and build tools you like to use.So that's everything! We have a few other smaller ideas we might try to squeeze in before now and the actual release, but this is all of the stuff I'd really appreciate help testing so we can make any API changes we need to make before it's too late and we become prisoners to the cruel bastard that is semantic versioning.
So install
tailwindcss@insiders
, beat the hell out of it, and let us know what you find!Beta Was this translation helpful? Give feedback.
All reactions