3 ms·

:focus-within is a favourite of mine since it is one of the few CSS selectors where child element state is significant. Thus it is very nice for drop-downs. It

:focus-within is a favourite of mine since it is one of the few CSS selectors where child element state is significant. Thus it is very nice for drop-downs. It also works with CSS transitions, so my pure CSS drop-downs have a 150ms easing in & out (tip: transition the visibility property, since display:none can't be delayed). There is another, however. An element whose state depends on that of other elements, and it's even more general. A form element moves between :valid and :invalid based on its inputs, allowing us to use form:{in}valid with any of the descendant, child, sibling or adjacent combinators. A hidden required checkbox is sufficient. Radio inputs work too (tip: you can clear radios back to :invalid with an input type="reset"). The really, truly monstrous part of this, however, is that the associated input doesn't even have to be a child of the form. Using the form attribute (i.e., <input form="whatever">) means they can be anywhere on the page, and they can themselves be hidden and targeted from somewhere else on the page again, with a <label> element. I once documented the horrifying potential of this in a company wiki, along with a lovely modal slideover that was wrapped in a <form> element and transitioned to visible based on form:valid via a hidden required radio button, and whose backdrop was a reset button, and this was rightly labelled NSFW and banned by popular acclaim from ever appearing in our HTML.

pickpuck 5y ago
The form/valid one is very interesting but I'm not sure I completely follow, especially the last example. Would you be able to post a Codepen?
- inopinatus 5y ago
  Done. I've posted a sample usage, it's in a reply to a comment a bit further down.
- e12e 5y ago
  I'm assuming the input is toggled via js (or server rendered html) - and the selector is used for cascading "state" into the html?
- eyelidlessness 5y ago
  Since it just finally made sense to me... it’s basically the checkbox hack but without a sibling structure requirement. Given markup like this: <form id="foo"></form> <div class="target">...</div> <div class="doesnt-matter"> <input type="checkbox" form="foo" required> </div> You can target `.target` with: #foo:invalid ~ .target Because the checkbox is required/unchecked. (And the inverse if it’s checked using `:valid`.)
  - lenkite 5y ago
    Ok, this is a great hack - but what would one practically use this for ? I mean the standard checkbox hack works too right ? Or is there some place where this technique excels ?
    - deleted 5y ago
      [deleted]
    - inopinatus 5y ago
      There are two bonus capabilities from using the form:valid hack: 1. The input element(s) can now be anywhere on the page. You can, for example, use adjacency to style a control button, without torturing your HTML to squeeze the button into being a sibling of whatever it's activating. 2. You can use form:valid as a parent selector i.e. as a wrapper element. You couldn't use an input:checked as a parent selector because the <input> element's content model is "nothing" i.e. there are no child elements under an <input>, but you sure can with a <form>. The result is less brittle to code-rot. This is extremely freeing and allows you to use, for example, a :checked adjacency for styling an activation button and a wrapper element (a form:valid) for the large complex component (modal? drop-down? slideover? video content?) that it activates. Heck, it can even be an iframe. Here's the bones of an example: https://codepen.io/inopinatus/pen/vYxrOeR?editors=1100 https://codepen.io/inopinatus/pen/vYxrOeR?editors=1100 There are two downsides: 1. Behaviour of some elements is different inside a <form>. Most obviously, don't nest a <form> inside with the same scope. 2. Your HTML maybe become a mess of scattered <form>, <input>, and <label> elements that many other developers will look at and say "WTF was this person thinking" and "what does this button do?"
eyelidlessness 5y ago
Oh my gosh. I’ve read this comment over and over, and didn’t “get it” until it finally clicked just now. You found a way to use form validity as a parent selector! Monstrous for sure, but fucking brilliant and I’m ashamed I haven’t thought of it as I’ve been trying to justify... all manner of things to claw sibling selectors back from things I want to use but div/custom-element wrap in ways I can’t abide.
- inopinatus 5y ago
  Try imagining the possibilities when using validation-capable inputs other that checkboxes and radios, too. How about a range slider, or a text input with a validation regex... For further inspiration, I recommend reading the entirety of the HTML Living Standard and the current CSS Snapshot about once a year. I'm currently excited about the opportunities for [open], particularly with the <details> and <dialog> elements. My biggest disappoints of the year are with <datalist>, unfortunately, which is so mysteriously half-baked it's practically worthless; followed by Webkit dragging its heels over <dialog> support and customized built-in element support.

pickpuck 5y ago

The form/valid one is very interesting but I'm not sure I completely follow, especially the last example. Would you be able to post a Codepen?

inopinatus 5y ago
Done. I've posted a sample usage, it's in a reply to a comment a bit further down.
e12e 5y ago
I'm assuming the input is toggled via js (or server rendered html) - and the selector is used for cascading "state" into the html?
eyelidlessness 5y ago
Since it just finally made sense to me... it’s basically the checkbox hack but without a sibling structure requirement. Given markup like this: <form id="foo"></form> <div class="target">...</div> <div class="doesnt-matter"> <input type="checkbox" form="foo" required> </div> You can target `.target` with: #foo:invalid ~ .target Because the checkbox is required/unchecked. (And the inverse if it’s checked using `:valid`.)
- lenkite 5y ago
  Ok, this is a great hack - but what would one practically use this for ? I mean the standard checkbox hack works too right ? Or is there some place where this technique excels ?
  - deleted 5y ago
    [deleted]
  - inopinatus 5y ago
    There are two bonus capabilities from using the form:valid hack: 1. The input element(s) can now be anywhere on the page. You can, for example, use adjacency to style a control button, without torturing your HTML to squeeze the button into being a sibling of whatever it's activating. 2. You can use form:valid as a parent selector i.e. as a wrapper element. You couldn't use an input:checked as a parent selector because the <input> element's content model is "nothing" i.e. there are no child elements under an <input>, but you sure can with a <form>. The result is less brittle to code-rot. This is extremely freeing and allows you to use, for example, a :checked adjacency for styling an activation button and a wrapper element (a form:valid) for the large complex component (modal? drop-down? slideover? video content?) that it activates. Heck, it can even be an iframe. Here's the bones of an example: https://codepen.io/inopinatus/pen/vYxrOeR?editors=1100 https://codepen.io/inopinatus/pen/vYxrOeR?editors=1100 There are two downsides: 1. Behaviour of some elements is different inside a <form>. Most obviously, don't nest a <form> inside with the same scope. 2. Your HTML maybe become a mess of scattered <form>, <input>, and <label> elements that many other developers will look at and say "WTF was this person thinking" and "what does this button do?"

eyelidlessness 5y ago

Oh my gosh. I’ve read this comment over and over, and didn’t “get it” until it finally clicked just now. You found a way to use form validity as a parent selector! Monstrous for sure, but fucking brilliant and I’m ashamed I haven’t thought of it as I’ve been trying to justify... all manner of things to claw sibling selectors back from things I want to use but div/custom-element wrap in ways I can’t abide.

inopinatus 5y ago
Try imagining the possibilities when using validation-capable inputs other that checkboxes and radios, too. How about a range slider, or a text input with a validation regex... For further inspiration, I recommend reading the entirety of the HTML Living Standard and the current CSS Snapshot about once a year. I'm currently excited about the opportunities for [open], particularly with the <details> and <dialog> elements. My biggest disappoints of the year are with <datalist>, unfortunately, which is so mysteriously half-baked it's practically worthless; followed by Webkit dragging its heels over <dialog> support and customized built-in element support.