[selectors] decide on :blank

[annevk]

Is :whitespace-only really that bad? It's a more niche case so longer names seem acceptable then? Or just decide on :blank and remove the issue marker, allowing implementations to remove the prefixed variant (if still feasible).

[js-choi]

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”.

[fantasai]

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.

[css-meeting-bot]

The Working Group just discussed decide on :blank.

The full IRC log of that discussion

<dael> Topic: decide on :blank
<dael> github: https://github.com//issues/1967
<dael> fantasai: We had an issue in the spec for name of :blank. It was a request to pick a name. There was a discussion in the past to redefine empty to allow whitepsace inside it.
<dael> fantasai: That's a Q for the WG. Question is do we want to drop :blank and have :empty allow for whitespace or do we want two descriptors? In the second case we need a name for the selector.
<dael> Rossen: Use case?
<dael> fantasai: Most of the time you're trying to pick something empty there's often white space in there. Currently if you try and select empty table cells but you didn't carefully close all tags an make sure there were no spaces then :empty doesn't work.
<dael> glazou: Another reason they're not completely empty is because if there's no content you don't have a frame to rendor and then cannot edit.
<dael> fantasai: There should be a frame
<dael> glazou: Not always.
<dael> glazou: It means we have tons of doc in the wild with whitespaces.
<bradk> :empty-ish
<dael> fantasai: Question is about the selector. We have :empty. We can say it also matches elemnents that contain whitespace. Or we can say it does not match when it has a whitespace in which cae we need another selector that matches to things with nothing or white space.
<Rossen> someone is typing loud
<dael> glazou: I favor the later.
<dael> dbaron: I think :empty has been around long enough that we would break if we changed the behavior.
<AmeliaBR> I liked :blank. But if we need to be more clear, :whitespace-only is as explicit as we can get.
<dael> florian: On the one hand I have a hard time thinking of use case to distinguish, but there is a compat concern and that's what should decide the issue.
<fantasai> AmeliaBR, it might not contain any though :)
<AmeliaBR> (Definitely don't change the current behavior of :empty. That could mess up use cases like using it to show a placeholder for a <div contenteditable>
<dael> astearns: Might be somewhat difficult to figure out web compat problems b/c it's likely code that is dealing with interaction.
<dael> glazou: Has MS commented?
<AmeliaBR> :empty-or-whitespace
<dael> Rossen: I'm interested to find out what hte webcompat is. I don't remember if we even impl :empty. I'd be surprised if there's too much interop
<dael> glazou: I was asking about the stats MS has online on props. Does it incl selectors? Do we have metrics?
<dael> glazou: On :empty usage
<dael> Rossen: I'll take a look at what the crawlers have seen. I'd be surprised if it's wildly used.
<dael> glazou: Me too.
<dael> astearns: Whether or not it's possible to redefile :empty is there a reason to have both?
<dael> Rossen: I'd be in favor of the simple way to only have :empty that fantasai desc
<bradk> :mostly-empty
<dael> astearns: Shall we need the issue as needs data?
<dael> fantasai: Yes
<dael> Rossen: Looking at CSS usage I don't see hits for :empty. fwiw there's nothing we find.
<dael> glazou: So nothing prevents us from redefining it?
<dael> Rossen: THat's my read. If anyone has data for the contrary I'm willing to take a look. On our end I don't see anything.
<dael> fantasai: To be clear the case that would break is if someone uses :empty and expects it not to select an element that includes whitespace.
<fantasai> s/whitespace/only whitespace/
<dael> Rossen: That sounds to me like a fringe case. This could be a toolability work around where an editor is carefully adding and removing and this is selecting only things not edited by a user yet. But this is an edge case. I'd say we should make the change.
<dael> glazou: Case where element is content:Editable and you wan tto make difference between entirely empty and whitespace is there.
<glazou> s/content:Editable/contenteditable
<dael> dbaron: [missed] someone tried to use :empty, it didn't work, they didn't remove it and then it suddenly matches.
<dael> Rossen: If we find those use cases let's discuss, but I don't see any usage.
<dael> astearns: Prop is redefine :empty to allow whitespace and to remove :blank
<dael> astearns: Obj?
<dael> glazou: I don't like it. I'd prefer preserve :empty and have a selector for both.
<dael> florian: You think there's a case for one or the other?
<dael> glazou: THen you can write a more coplex selector.
<dael> astearns: I thought you argued before where when you want a blank thing...
<dael> glazou: I was misunderstood. I want the two features to be able to handle sep.
<bradk> :empty(ws)
<dael> fantasai: The case where you only care about non-whitespace is the more common.
<AmeliaBR> Example of the contenteditable usecase, would be weird if it treated a space as empty: https://codepen.io/AmeliaBR/pen/QvMGmR?q=%3Aempty&limit=mine
<dael> dbaron: This doesn't feel like the kind of thing where we want to spend a lot of resources on testing for compat. Breaking changes are a lot of work
<dael> astearns: From the principle of less work, proposal is keep current definition of :empty and keep current definition of :blank and have people impl :blank if the empty with whitespace use case is useful.
<dael> dauwhe: Is there concern we have a blank pseudo class in pages?
<dael> astearns: Same syntax?
<dael> dauwhe: In a page context, but it's :blank. I think in an @rule
<dael> astearns: Does that @rule select paes with only whitespace?
<dael> dauwhe: Pages created by rendering engine that don't have content.
<fantasai> https://www.w3.org/TR/css-page/#blank-pseudo
<dael> florian: So it maches :empty not :blank
<dael> dauwhe: Yeah, although you can make master pages with content that match :blank
<dael> dauwhe: prob not confusing for most, but woth mentioning
<fantasai> :empty-ish
<dael> astearns: So an argument to change :blank name to :whitespace-only or something
<dael> astearns: First, would anyone obj to keeping :empty with current definition and havin a selector that means empty or whitespace.
<dael> florian: Not an obj, but I'm not sure keep things the way it is is really less work. People need to impl a new thing.
<dael> dbaron: But if we change empty people impl the new thing too.
<dael> astearns: Work we're avoiding is the web compat check.
<dael> Rossen: My position is if we're keeping :empty let's keep as-is. If we're changing lets do so completely and have something that's the superset. If we don't care about webcompat let's not. But if we keep :empty as is 'd oppose to change empty and have a selector that means something kinda like :empty
<dael> astearns: Yeah, I don't think that's on the table.
<dael> Rossen: THe last proposal I heard was change :empty
<dael> florian: No, fix empty to mean what blank means or get both.
<dael> fantasai: We have an empty cells prop for tables that behaves like :blank. It triggers when there's white space. So there's a comflict in meaning.
<dael> fantasai: I wouldn't obj to keeping things the way they are, but I would be annoyed because I've found the way :empty was defined to be annoying.
<dael> astearns: Two avenues and there are people that would obj or be unhappy with both.
<fantasai> https://www.w3.org/TR/CSS2/tables.html#empty-cells
<dael> Rossen: Do we go back to GH and see if we can argue more there?
<dael> fantasai: I'd like to talk with glazou more offline on his concerns.
<dael> astearns: Was there previous discussion on redefine empty?
<dael> fantasai: Yes, but nothing formal. When it was first defined I believe it was discussed and people were saying if there's a text node in the dom it's not empty, but that's not how people go about styling their pages.
<dael> astearns: I think we've had enough on the call. fantasai and glazou can discuss and summerize on GH.
<dael> dbaron: One other point is elements like :pre where whitespace is significant.
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Nov/0018.html

[bradkemper]

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.

[whileloopa]

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...

[annevk]

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.

[fantasai]

Thanks @annevk, totally lost track of this one.

[fantasai]

Related issue: #1283

[css-meeting-bot]

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

• RESOLVED: :empty does cover whitespace

The full IRC log of that discussion

<dael> Topic: decide on :blank
<dael> github: https://github.com//issues/1967
<nigel> I don't follow why we don't use the same definitions for blank and empty as are in selectors §13.2 and 13.3
<dael> fantasai: The discussion was about...one of the problems with empty selector is it does not select elements iwth only whitespace. Those are fairly common. <li>enter<li> will auto close and have a line feed and therefore is not empty.
<dael> fantasai: Issue was can we have a selector that means actually empty.
<dael> fantasai: Last conversation was either add a second selector that means empty and ignore whitespace or redefine :empty where if it contains whitespace it's still empty
<dael> fantasai: Discussion on webcompat, weren't many instances of empty. Daniel wanted a distinction somehow. Point that empty-cells ignores whitepsace the same way we proposed to redefine :empty.
<dael> fantasai: After that discussion brad proposed making empty a functional psuedo class to have different kinds of empty. That's where we're at
<dael> Rossen_: What's the favored proposal in your PoV?
<bkardell_> q+
<dael> fantasai: Ideally :empty would look from the author propsective and ignore whitepsace. If need more options make it a functional pseudo class
<dael> bkardell_: Definion of :empty is so strict that I feel part of the ask is to lessen that strictness. I don't know that getting that wrong will be more helpful.
<TabAtkins> I agree that :empty's current definition is just plain too strict to be worthwhile. I bet we can loosen it by default, and don't need to make it controllable.
<dael> bkardell_: Example if it has a link tag or style tag would an author consider that empty? What about a hidden attribute? Comments are a different node type so they don't count. THis raises a lot of questions we should carefully consider or it'll be similarly disaoppinting.
<gregwhitworth> I agree with TabAtkins here. Probably a good default is not to include white space
<dael> bkardell_: How close can you come to what people want.
<dael> florian: Good idea to consider these things you've listed. Driving use case is indenting and self-closing tags. Just loosening to consider whitespace would pretty much over the use case
<dael> bkardell_: Lots of comments and articles about editors. Closing is one, but Daniel brought up last time an editor when you create something with nothing in it how to style that is tricky. Other blog posts looking for that. Other blog posts wanting more.
<TabAtkins> We cant' ignore <style>, unfortunately - you can display those! (and make them contenteditable, for live-editting of a stylesheet).
<dael> bkardell_: Not sure why we say the use case is that unless we're sure.
<TabAtkins> But yeah, ignoring whitespace-only text nodes seems A-OK
<dael> florian: Not sure I see the use case for a selector that only selects link elements.
<dael> florian: Why would you want to select these things specifically?
<dael> bkardell_: Not only thign swith link. Select something that from author standpoint thinks is empty. Functionally if you add something from an editor it may have content, but from the viewer/author prospective it's empty.
<dael> florian: I hear you but don't agree
<TabAtkins> You can display a <link> too...
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6230
<dael> fantasai: A lot of these selectors won't work if you don't understand your markup. That's true for nth-child and only-child. THe structural selectors don't work with stray elemetns in the markup. That as a driving use case doesn't make a lot of sense. If you're in that world you need to put classes on. You can't use these without control on markup.
<dael> florian: As TabAtkins put in IRC you can display most of what you wrote.
<dael> fantasai: Def we can't change ":empty to solve that. We can't make things depend on styling. So where there's tags but no text if you style that it's very visible. From author view it does not look empty. It comes down to are you understanding your markup. If you're not the tree selctors can't help you. Can't write selectors that work based on styling of element.
<dael> fantasai: If a wysiwyg author thinks the thing is empty depends on what you see. We can only help authors in markup
<dael> bkardell_: Yes, I think what a lot of people want is not possible. Thinking through and making the least surprising thing seems good.
<dael> florian: I wonder about comments. Are they gone before we do selector parsing?
<dael> TabAtkins: They don't show in the dom tree that selectors see
<dael> florian: Only whitepsace means whitespace and comments
<dael> TabAtkins: And other nodes
<dael> florian: As long as it falls out
<dael> bkardell_: Empty clearly specifies that
<dael> fantasai: If our goal is not surprising [missed]
<dael> TabAtkins: Selector modal only sees syntax nodes. Other elements aren't seen by selectors.
<dael> florian: I think we circled around. Can we resolve on :empty also allowing whiespace?
<TabAtkins> s/syntax nodes/element and text nodes/
<dael> fantasai: sgtm
<TabAtkins> +1
<dael> Rossen_: Proposal is :empty does cover whitespace?
<dael> florian: Yep.
<dael> Rossen_: Other opinions?
<dael> Rossen_: Objections to :empty does cover whitespace?
<bkardell_> so to clarify
<dael> RESOLVED: :empty does cover whitespace
<bkardell_> lol
<bkardell_> nm
<dael> bkardell_: Wanted to clarify we're changing the existing definition of :empty?
<dael> florian: Yes.
<dael> bkardell_: Last WG there were concerns about that where someone left an :empty that was false as a test. No concerns on that?
<dael> fantasai: Last discussion I recall Rossen_ said he checked and didn't see enough use of :empty. Author mistakes or author intention it's possible someone put a stray :empty or the author put :empty and it didn't apply to every element due to whitespace. Not sure if this ould break more uses or fix more uses
<bkardell_> yes, me too, what fantasai said
<dael> florian: But it's rarely used anyway
<bkardell_> ok, no real objection then
<dael> Rossen_: And I just looked at the data since then and I don't see an uptick of usage. If there are different numbers we can revisit.
<dael> Rossen_: Anything else to resolve?

[AmeliaBR]

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.

[kizu]

@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.

[nigelmegitt]

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

[kizu]

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) :)

[fantasai]

@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.

[fantasai]

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

[annevk]

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).

[myakura]

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/

[ExE-Boss]

Are implementation bugs filed?

Firefox has bug 1106296.

[annevk]

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?

[LeaVerou]

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

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: [selectors] decide on :blank
<Guest60> present-
<dael> github: https://github.com//issues/1967
<dael> fantasai: Previous discussion wanted to see if :empty can ignore whitespace. Currently if you have any whitespace it's not considered empty. Believed that was super confusing because usually whitespace goes away. Collected compat and lots of websites use empty
<dael> fantasai: Not seeing if anyone was using empty in a way that specifically expects whitespace to not match empty
<dael> fantasai: My take is more investigation on web compat would be good. Don't know if anyone else has opinions
<fantasai> s/Not seeing/But no one did a random sample to see/
<dael> astearns: chrishtr you commented?
<dael> chrishtr: Data we have so far is whitespace appears on 2% of page loads. Without a bunch more work we wouldn't be able to confidently change
<dael> fantasai: I didn't have the data. Is any way to create a random sample of some pages with the data and I can do a human look?
<dael> chrishtr: It's http archive which you can query. Have you used that?
<dael> fantasai: No
<dael> chrishtr: I'll point you to it offline
<dael> chrishtr: I don't have other context on this so I don't know how critical it is and if it's fine towait.
<dael> fantasai: I don't think it's urgent
<dael> astearns: Next step is analyze data?
<dael> fantasai: Yep

[foolip]

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.

[brandonmcconnell]

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.

Pseudo selector	Decorator / implementation note
:empty	implementation stays as is, matches elements without any contents (whitespace will not match), spec is adjusted to exclude whitespace as allowed contents to match :empty
:blank	matches empty values as spec'd here and discussed here: https://github.com/whatwg/html/issues/8451
:whitespace-only	similar to :empty but assesses the element's trimmed contents rather than untrimmed to ignore whitespace when evaluating for emptiness
:text-only	decorator for :not(:has(> *)) to match any elements without any child elements

[romainmenke]

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.

[brandonmcconnell]

@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.

[Fast-Nick]

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?