Conversation
|
The :has() selector is not enabled in Firefox https://developer.mozilla.org/en-US/docs/Web/CSS/:has#browser_compatibility |
|
Something else to consider... when shadows are enabled, this pseudo element overlaps the input's shadow. Not sure yet how best to proceed with a fix here.
|
|
i like it. 👌 the min-height for foating-labels textarea's could also be increased a little. then it's perfect.
|
louismaximepiton
left a comment
louismaximepiton
left a comment
There was a problem hiding this comment.
I feel really exciting using this :has selector, however I feel like 85% might not be enough. For example I can't test it on FF LTS v.102. I don't know what's the policy on these features atm.
If we agree that we enable progressive enhancement, should we have a fallback ?
| position: relative; | ||
|
|
||
| &:not(.form-control:disabled)::before { | ||
| &:has(.form-control:not(:disabled))::before { |
There was a problem hiding this comment.
Maybe split the rule in two ? .form-control::before and :has(.form-control:disabled)::before in order to avoid this:
So in the second rule we might only change the bg-color ?
|
Another option in #38313. |
|
Closing for #38313. |
3 participants
This rewrites the selector to use
:has()because.form-floatingis a parent container, which has no:disabledstate. The:disabledis handled on the individual form element.That said, it'd be really cool if adding a
disabledattribute on a parent element would disabled all the elements within—right now only fieldsets do that. And I genuinely just stumbled back into thinking about this... so what if we used fieldsets here in v6? Something to think about.Anyway, the downside of using the
:has()selector is browser compatibility right now. I'm not super worried about that as this could be seen as a progressive enhancement, but it's worth calling out. With the new selector, nothing is generated for disabled fields, so we avoid that problem entirely./cc @julien-deramond @louismaximepiton @jonnysp