Is there a particular reason why :ws-only would be unacceptable? It contains what would be a new abbreviation (“ws”) in CSS, but the result is much pithier while remaining semantically unambiguous, from what I can tell.

In addition, though perhaps less importantly, :whitespace-only is inconsistent with the already-introduced white-space CSS property, which considers “white space” to be a two-word phrase.

(My apologies if this particular option has already been discussed; I could find no mention of “ws-only” in this GitHub repository, the www-style archives, or the web in general. I can only imagine the tedious bikeshedding that has been occurring for the past four-to-five years.)

Edit: I typed “ambiguous” instead of “unambiguous”.

Fwiw, there was also a discussion around maybe redefining :empty to allow white space, since that's what most people would expect it to be. The main question there would be Web-compat, I guess.

The Working Group just discussed decide on :blank.

Yeah, the white space only version would be far less niche than :empty is.

My preference is to make :empty into a functional notation, and if you leave off the parentheses it is the same as :empty(legacy) or whatever. Then you could have :empty() be the more useful version that ignores white space, and have other possible arguments to say whether non-breaking spaces, thin spaces, etc. are significant.

I suggest
:empty(strict) -- match elements with nothing inside
:empty() -- match elements that contain only '\s', '\t', '\n' or nothing
:empty(blank) -- match elements that contain nothing or '\s', '\t', '\n' or descendant elements that produce only whitespace, eg. <p></p>, <br/>, <pre> </pre>, etc...

OR

:blank(empty) -- match elements with nothing inside
:blank() -- match elements that contain only '\s', '\t', '\n' or nothing
:blank(children) -- match elements that contain nothing or '\s', '\t', '\n' or descendant elements that produce only whitespace, eg. <p></p>, <br/>, <pre> </pre>, etc...

To be clear, I'm adding Agenda+ back since while it was discussed, no conclusion was reached and it's nearly a year later now without a path forward for implementations.

Thanks @annevk, totally lost track of this one.

Related issue: #1283

The CSS Working Group just discussed decide on :blank, and agreed to the following:

• RESOLVED: :empty does cover whitespace

I really don't like the idea of a breaking change!

An example of a use-case this change would break: using :empty on a <div contenteditable></div> to set a style indicating that it hasn't been edited or show a placeholder message indicating that editing is possible (old demo of mine). It would be rather confusing if the author did edit the content but the placeholder didn't disappear.

@AmeliaBR thinking more about it: while I agree that this exact use case would “break”, for this use case the effect would be still minimal and acceptable, in my opinion. While not disappeared placeholder on whitespace input would be slightly confusing, it won't break anything — the field would work the same, the only slight annoyance would happen only if people would start writing a message from a whitespace, and the only case where this could be highly confusing is if the main/only purpose of the input would be to contain just whitespace, but the intersection of this exact use case and an :empty usage could be non-existent?

So, while I generally prefer things to be backward-compatible, in this case, I don't see enough realistic use cases where things would break considerably, and the benefits of making the default behaviour more useful and less confusing would prevail over the minor annoyances it could cause.

Extreme edge case alert: an editor for the Whitespace language might be broken by this change.

Only if it would use the :empty in this way.

Also: there is a chance that for those writing a Whitespace editor having the new default behavior for :empty could be potentially beneficial? They could use it as a very cheap validation tool, as you could target an editor containing something other than whitespaces with :not(:empty) :)

@AmeliaBR I think that such a niche use case is far outweighed by the general confusion of :empty not selecting elements which the author perceives as being empty, for example P, LI, TD, and TH elements without end tags in a properly-indented source document. I think one of the major use cases for :empty is likely to be selecting empty cells in particular, and matching the conditions that the 'empty-cells' property uses seems likely to be much more useful and intuitive for authors than considering white space to be significant content here.

If there are strong use cases for other definitions of emptiness in a selector, we can consider adding them through a functional notation in the future, as @bradkemper suggests.

@annevk Let me know if this is resolved to your satisfaction, else re-open?

I'm a little concerned that not many implementers weighed in on that decision. Are implementation bugs filed? Are the tests updated?

Also, your commit mutates the changelog in a way that's confusing me. As :blank is still there (though with new semantics).

Also, your commit mutates the changelog in a way that's confusing me. As :blank is still there (though with new semantics).

@annevk that confused me too. but it appears the :blank introduced in 2b42b64 is a brand new selector to target empty form elements. see #1283 and https://www.w3.org/blog/CSS/2018/09/27/minutes-2018-09-26/

Are implementation bugs filed?

Firefox has bug 1106296.

Thanks for linking that. In that bug @dbaron wrote the following 3 years ago:

Today the group resolved to drop :blank and change :empty to be like :blank, although I'm skeptical that this will be Web-compatible. We should do this after Blink does it, but I don't think it's worth risking Web compat on before they move first.

It seems the CSS WG decided to try this again 3 years later unless I'm missing something? Why are we expecting different results? Why didn't it happen last time?

The question is, do the pages intend for :empty to match white‑space, or ignore white‑space?

It's totally possible that the pages are using it expecting it to activate when there is still white space in the element but this is a bug in their code.

The 2% could be seen as evidence to prove how confusing :empty is for developers in it's current form.

@Dan503 By that logic there was no point looking at the counter, if you were going to argue for this change with or without a negligable count.

To be clear, I don't really think that's a question here and I don't think it's "totally possible" as developers test their pages in browsers. That they would currently be broken in some way in all browsers seems rather absurd.

Per the usual breaking change numbers it seems that would be too high and mean we cannot change the definition of :empty, right?

@annevk: right. In Chromium we use the rule of thumb of "much less than 0.1%" being an acceptable percentage for breaking changes. Anything at 2% needs to have strong evidence that it won't break sites, and also a strong justification as to why it's important enough to cause this churn for site authors.

Since web compat was mentioned:

In the HTTPArchive data, :empty is used on 12% (621,005) of the desktop sites crawled and 16.25% (964,648) of the mobile sites

The CSS Working Group just discussed [selectors] decide on :blank.

Implementing :empty per spec is a proposal for Interop 2023, see web-platform-tests/interop#180. However, the use counter already referenced in this thread is now at 2.5%. Careful analysis of a large-ish random sample of sites hitting the use counter would be needed to show that the risk is low enough.

I think a simpler route would be to have four different selectors (two of which already exist), each clearly fulfilling a different purpose, which would also help to avoid any breaking changes for that 2.5% that @foolip (via @lilles) pointed out and also to attempt to be more future proof:

• :empty – no children (no whitespace allowed)
• :blank – empty value (for form fields and related elements)
  being discussed here: Define :blank pseudo-class behavior whatwg/html#8451
• :whitespace-only – no child element nodes or non-whitespace text nodes (whitespace allowed)
• :text-only – no child element nodes (text and whitespace allowed)

Related notes:

• :whitespace-only could be nearly identical in implementation to :empty with the slight difference of assessing trimmed contents rather than untrimmed contents.
• :text-only is technically possible today (AFAICT) as a decorator using :not(:has(> *)) though there's likely a simpler way to actually implement this than as a decorator.

:empty

:blank

:whitespace-only

:text-only

This might be personal, but I find :whitespace-only and :text-only confusing.
It is not clear to me that these are related to :empty.

Something like:empty(allow-whitespace) or :empty(allow-text) makes it clear that we are matching some definition of "empty" while allowing/ignoring certain bits.

I do agree that all four features are relevant.

@romainmenke I dig that! 🙌🏼

I think :empty() could be a pseudo selector with a single argument for any exceptions, that being allow-whitespace and allow-text, which would also leave the door open in case any more options were ever to be conceived.

The one odd-ball out would be :blank which I think can stay separate, as that's rather unrelated to the empty state and has more to do with the state of a form field's value. It's a little deeper than that, but we go into that in the link I mentioned before re :blank.

The argument that :empty without including whitespace (the old spec) is confusing should be rephrased as "More than 50% of developers that have not read the documentation for :empty assumes that it includes whitespace"

...if that statement is false, then changing :empty to include whitespace would increase confusion among developers instead of decrease it. Does anyone actually have statistics for this, or is it only "many" devs found it confusing - which doesn't prove that including whitespace would decrease confusion - it just proves that :empty was poorly named?

In a made-up sample of new web developers, let say that 25% assume :empty include whitespace, 25% are unsure / no strong expectation, and 50% assume it does not include whitespace. If so then changing :empty to include whitespace would in fact double the confusion instead of improve things. Did I miss the part where solid statistics were presented?