3 ms·
The `peer`-modifier has a very significant and unfortunate limitation which prevents it from being useful for things like styling `<label>` elements that preced
by gmaster1440 2y ago
The `peer`-modifier has a very significant and unfortunate limitation which prevents it from being useful for things like styling `<label>` elements that precede input controls, which is that it can only target a previous sibling above it and not the next sibling below, which is often the case in forms and other components. This is a limitation with CSS and not Tailwind fwiw.
- egonschiele 2y agoThat is like a surprising limitation! Any idea why?
- ezekg 2y agoHow is that a limitation of CSS? I would think the previous sibling would historically be harder (but doable with :has), since next sibling is the way CSS has always worked. .foo:has(+ .foo) vs .foo + .foo
- gmaster1440 2y agohttps://developer.mozilla.org/en-US/docs/Web/CSS/Subsequent-sibling_combinator https://developer.mozilla.org/en-US/docs/Web/CSS/Subsequent-...
- ezekg 2y agoI'm still not following the limitation. You can use ~ in place of + in my example and it'll work for subsequent siblings too, not just for next sibling.
- gmaster1440 2y agoCan you share a snippet or link to a repl showing how I can use `peer-` to make the label below have a gray text color when the input sibling is disabled? ``` <label for="email">Email</label> <input disabled id="email" type="email" /> ```
- ezekg 2y agoI don't use Tailwind but this is easy with CSS: label:has(+ input:disabled) { color: gray; } Not sure why Tailwind couldn't do this.
- gmaster1440 2y agoAh, I see. May simply be the case then that `:has()` is relatively new and it wasn't possible prior to it's general availability as recent as Dec 2023.
- mhitza 2y agoIf that's the case in some circumstances should be able to work around that by wrapping the field+label in a flex container and rendering them in reverse. That sounds like most solutions I have to come up with when using CSS for any kind of non-trivial UI :)