Frontend

Useful CSS child selectors for when siblings may be `[hidden]`:

First visible child:

	> :not(:not([hidden]) ~ *)

Last visible child:

	> :not(:has(~ :not([hidden])))

Middle visible child:

	> :is(:not([hidden]) ~ *):has(~ :not([hidden]))

Only visible child:

	> :not(:not([hidden]) ~ *):not(:has(~ :not([hidden])))

/frontend dev・founder/decentralized data wrangler /blockhead・UI/UX abstractionist・DeFi/web3 builder・dropout・24・prev /dydx, ritual.net・x.com/darryl__yeo

(Is anything like this even remotely possible in Tailwind…?)

Generalizing to any given CSS `.selector`:

First match:

	:not(.selector ~ *)

Last match:

	:not(:has(~ .selector))

Middle match:

	:is(.selector ~ *):has(~ .selector)

Only match:

	:not(.selector ~ *):not(:has(~ .selector))

https://warpcast.com/darrylyeo/0x58b0c134

father, husband, css golfer, ux engineer, silently defining variables as /sdv sdv.wtf

Motivating use case for me is transitioning heights and margins of hidden elements to zero while also accounting for margin “collapsing” behavior. Basically, if a hidden child is flanked on both sides by visible siblings with margin, it should offset one of those with negative margin in its “outro” transition so there is no visual break once it leaves the flow and the siblings’ margins collapse.

But yes, fair points – these selectors are situationally useful, performant the way regex lookahead assertions are performant, and effectively a polyfill hack for when a serious “nth of selector” proposal hopefully eventually lands in CSS…

I love me some quirky nested css selectors as the next person, but would argue these are not ideal for anything beyond hotfixes!

- hard to read
- not performant, especially with large DOM trees
- seems like a bandaid to a larger problem (overly complex components)