Re: [csswg-drafts] [selectors] decide on :blank (#1967)

> Is the intent for this to match any _general_ elements that have no content (eg, `<span></span>`) or interactive controls that have no content (eg, `<input value="">` and `<textarea></textarea>` but _not_ `<span></span>`)? The draft spec says it's for interactive controls but some comments in this thread seem to be implying the idea is "`:empty` except whitespace nodes don't count"

This is my understanding, going off of [Selectors Level 4](https://drafts.csswg.org/selectors/):

If you're talking about [:blank](https://drafts.csswg.org/selectors/#blank), it is intended to specifically target elements that accept user input, as long as there is no input entered (so <code>input.defaultValue</code> and <code>input.value</code> are both empty strings). Currently, I believe this is only achievable if the developer includes a placeholder and uses [:placeholder-shown](https://drafts.csswg.org/selectors/#placeholder-shown-pseudo), which is simply not possible with some elements that accept input (e.g. date inputs, file inputs, select, etc.).

If you're talking about [:empty](https://drafts.csswg.org/selectors/#the-empty-pseudo), it's intended to select any element with zero child nodes. Current implementations include whitespace text nodes when considering :empty, though that is out of spec. So:
<code>&lt;span&gt;&lt;/span&gt;</code> Will always get selected by :empty, but
<code>&lt;span&gt;&emsp;&emsp;&lt;/span&gt;</code>  Will not be selected by :empty with current implementations (but should be).

Blocks with only a newline will also be ignored, which is where the problem with :empty really arises in my opinion. 
<code>&lt;span&gt;
&lt;/span&gt;</code>
Using :not(:has(*)) would select the empty element above, but I can't imagine that's incredibly efficient.

Updating :empty to ignore whitespace would definitely make it more useful. I use PHP frequently in my work, and not being able to include whitespace within an element can be a nightmare for readability. The spec addresses this issue, but implementations have failed to do so thus far. I can understand this to an extent if there is a significant number of websites using it, but I don't see it often (if ever).

I do believe there is a place for :blank, and I do feel it is distinct enough from :empty that the two can coexist. :blank should be for form elements, whereas :empty is for container elements (paper is blank, a bucket is empty).

At least one issue I can foresee is any element with the contenteditable attribute, since it accepts user input. Would it be considered :blank, :empty, or possibly even both or neither?


-- 
GitHub Notification of comment by EricBMoreno
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1967#issuecomment-3438284616 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 23 October 2025 17:37:57 UTC