Join GitHub today
[selectors] decide on :blank #1967
Is there a particular reason why
In addition, though perhaps less importantly,
(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”.
The Working Group just discussed
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.
<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?
<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
<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.
<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.
<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.
<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
<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.
<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.
Yeah, the white space only version would be far less niche than
My preference is to make
:blank(empty) -- match elements with nothing inside
The CSS Working Group just discussed
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?
<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...
<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
<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
<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?
I really don't like the idea of a breaking change!
An example of a use-case this change would break: using
@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
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.
Only if it would use the
Also: there is a chance that for those writing a Whitespace editor having the new default behavior for
added a commit
Oct 3, 2018
@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 that confused me too. but it appears the
Thanks for linking that. In that bug @dbaron wrote the following 3 years ago:
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?