New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[selectors] decide on :blank #1967

Open
annevk opened this Issue Nov 10, 2017 · 19 comments

Comments

Projects
None yet
@annevk
Member

annevk commented Nov 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Nov 30, 2017

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

js-choi commented Nov 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Dec 4, 2017

Contributor

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.

Contributor

fantasai commented Dec 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Dec 20, 2017

Member

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
Member

css-meeting-bot commented Dec 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bradkemper

bradkemper Dec 20, 2017

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.

bradkemper commented Dec 20, 2017

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.

@astearns astearns removed the Agenda+ label Jan 9, 2018

@whileloopa

This comment has been minimized.

Show comment
Hide comment
@whileloopa

whileloopa Sep 21, 2018

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

whileloopa commented Sep 21, 2018

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 annevk added the Agenda+ label Sep 22, 2018

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 22, 2018

Member

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.

Member

annevk commented Sep 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 26, 2018

Contributor

Thanks @annevk, totally lost track of this one.

Contributor

fantasai commented Sep 26, 2018

Thanks @annevk, totally lost track of this one.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 26, 2018

Contributor

Related issue: #1283

Contributor

fantasai commented Sep 26, 2018

Related issue: #1283

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Sep 26, 2018

Member

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?
Member

css-meeting-bot commented Sep 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR Sep 26, 2018

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 commented Sep 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@kizu

kizu Sep 27, 2018

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

kizu commented Sep 27, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@nigelmegitt

nigelmegitt Sep 27, 2018

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

nigelmegitt commented Sep 27, 2018

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

@kizu

This comment has been minimized.

Show comment
Hide comment
@kizu

kizu Sep 27, 2018

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

kizu commented Sep 27, 2018

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 added a commit that referenced this issue Oct 3, 2018

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Oct 3, 2018

Contributor

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

Contributor

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

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Oct 3, 2018

Contributor

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

Contributor

fantasai commented Oct 3, 2018

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

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 4, 2018

Member

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

Member

annevk commented Oct 4, 2018

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

This comment has been minimized.

Show comment
Hide comment
@myakura

myakura Oct 16, 2018

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/

myakura commented Oct 16, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ExE-Boss

ExE-Boss Oct 16, 2018

Are implementation bugs filed?

Firefox has bug 1106296.

ExE-Boss commented Oct 16, 2018

Are implementation bugs filed?

Firefox has bug 1106296.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 16, 2018

Member

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?

Member

annevk commented Oct 16, 2018

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?

@annevk annevk reopened this Oct 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment