Skip to content
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 · 48 comments
Open

[selectors] decide on :blank #1967

annevk opened this issue Nov 10, 2017 · 48 comments

Comments

@annevk
Copy link
Member

@annevk 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
Copy link

@js-choi 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
Copy link
Collaborator

@fantasai 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
Copy link
Member

@css-meeting-bot 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
Copy link

@bradkemper 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
Copy link

@whileloopa 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
Copy link
Member Author

@annevk 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
Copy link
Collaborator

@fantasai fantasai commented Sep 26, 2018

Thanks @annevk, totally lost track of this one.

@fantasai
Copy link
Collaborator

@fantasai fantasai commented Sep 26, 2018

Related issue: #1283

@css-meeting-bot
Copy link
Member

@css-meeting-bot 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
Copy link
Contributor

@AmeliaBR 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
Copy link

@kizu 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
Copy link

@nigelmegitt nigelmegitt commented Sep 27, 2018

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

@kizu
Copy link

@kizu 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
Copy link
Collaborator

@fantasai 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
Copy link
Collaborator

@fantasai fantasai commented Oct 3, 2018

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

@annevk
Copy link
Member Author

@annevk 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
Copy link
Contributor

@myakura 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
Copy link
Contributor

@ExE-Boss ExE-Boss commented Oct 16, 2018

Are implementation bugs filed?

Firefox has bug 1106296.

@annevk
Copy link
Member Author

@annevk 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
@bradkemper
Copy link

@bradkemper bradkemper commented Nov 14, 2018

Is there a definition of what is considered white space for this issue? Is it just spaces, tabs, and line breaks/feeds? I would really like a version that also ignored nonbreaking spaces, thin spaces, etc.

Even if those were to be added later as arguments to a function, making the new version be :empty() with the parentheses would prevent backward compatibility problems, while also setting it up for accepting arguments in the future.

@fantasai
Copy link
Collaborator

@fantasai fantasai commented Nov 21, 2018

@bradkemper Yes, it's just spaces, tabs, and line breaks -- things that are used for formatting source code and can be collapsed away. Otherwise, you should just not put those spaces into the document. :)

@ExE-Boss
Copy link
Contributor

@ExE-Boss ExE-Boss commented Nov 21, 2018

I am personally in favour of how :blank and :empty are defined right now in commit selectors-4/Overview.bs@5f2e1b53.

@caillou
Copy link

@caillou caillou commented Nov 22, 2018

@ExE-Boss The way the :blank and :empty selectors are defined, does not allow for whitespace only content to still be selected.

My understanding is that we are trying to find or redefine a selector, that can be used in real world scenarios. Given that whitespace and newlines are not usually considered when outputting HTML, we are in need of a selector that could identify the following example:

  <div class="drop-zone">
  </div>
.drop-zone:blank {
  content: 'Drop File Here To Upload';
}
@Dan503
Copy link

@Dan503 Dan503 commented Aug 7, 2019

I need some clarification on this.

So if :blank is being dropped completely, is :empty being updated to also cover <input> and <textarea> elements that have no text in them?

If yes, does white space count as content in these form elements?

I agree completely that for regular HTML elements :empty should not count white space as content. For form elements though I think it should count.

The primary use case for supporting :empty on form elements is for supporting the floating label design pattern.

<label>
    <input/>
    <span>label text</span>
</label>
input:focus + span,
input:empty + span {
    /* styles that move the label out of the input area */
}

When the input is empty and doesn't have focus, the label looks like placeholder text. When it has focus, or has content, the label moves out of the way and looks more like a regular label.

I think it is useful for users if, for form elements, :empty counts white space as content. That way, if the user has entered spaces and no text, and the user has removed focus from the field, the label still displays in label form rather than placeholder form.

The advantage to the user here is that the field looks empty but since the label is displaying differently, the user is able to recognise that there is some white space content in there. If this matters for form submission then it is better for the user to be aware of what fields have only white space in them. Having white space only form submissions probably isn't that big of a deal though so having :empty not count white space in form elements isn't that bad.

@ExE-Boss
Copy link
Contributor

@ExE-Boss ExE-Boss commented Aug 8, 2019

I’d rather have :blank for user input elements, since <textarea> uses textContent as the textual content, and as such, :empty would have to behave differently for it, which results in a selector that ignores whitespace except for some elements, which goes against the goal of simplicity.

@Dan503
Copy link

@Dan503 Dan503 commented Aug 8, 2019

I would be in favor of :blank being exclusively for form elements and counts white space as content and :empty being exclusively for HTML elements and not counting white space as content.

@zocky
Copy link

@zocky zocky commented Nov 1, 2019

It's obvious that :empty should be left as is, and a new pseudo should be used for elements that have no other content than white space. :blank is as good a choice as any.

Also, inputs should be entirely left out of this. It is coincidental that this can be used to detect empty textareas. This cannot be made useful for detecting values of inputs in general (consider selects). It's a separate issue, and would need a separate solution.

@ExE-Boss
Copy link
Contributor

@ExE-Boss ExE-Boss commented Nov 1, 2019

I want :empty to be fixed, so that we can finally remove one item from the long, ever expanding, list of legacy CSS mistakes.

@Sora2455
Copy link

@Sora2455 Sora2455 commented Nov 1, 2019

@Dan503 Just a quick note that your use-case can be done with :placeholder-shown:

input:placeholder-shown + span {
    /* styles that move the label into the input area */
}
@Dan503
Copy link

@Dan503 Dan503 commented Nov 1, 2019

@Sora2455 that only works if the input has placeholder text to show. If there is no placeholder text then it doesn't work.

@Sora2455
Copy link

@Sora2455 Sora2455 commented Nov 1, 2019

@Dan503 Huh, so it does. Firefox activates the pseudo-selector if there's an empty Placeholder, though Chrome requires a space. Can't test Safari from here. See fiddle.

@ExE-Boss
Copy link
Contributor

@ExE-Boss ExE-Boss commented Nov 2, 2019

@Sora2455

@Dan503 Huh, so it does. Firefox activates the pseudo-selector if there's an empty Placeholder, though Chrome requires a space. Can't test Safari from here. See fiddle.

It doesn’t work without a space on iOS, so I doubt it works without a space on desktop.

P.S.: How does Internet Explorer fare with its :‑ms‑input‑placeholder pseudo‑class?

@Sora2455
Copy link

@Sora2455 Sora2455 commented Nov 2, 2019

@ExE-Boss In Edge/IE they just always stay in "floated" mode, meaning that they're still usable even though the selector is unsupported. Is that what it looks like in Safari?

:-ms-input-placeholder sort of works, only the transition only seems to happen once a hover event happens. See fiddle (in IE, obviously).

@Dan503
Copy link

@Dan503 Dan503 commented Nov 2, 2019

Firefox activates the pseudo-selector if there's an empty Placeholder, though Chrome requires a space.

I never thought of using an empty space in the placeholder attribute to create the effect. Nice suggestion 😊

@ExE-Boss
Copy link
Contributor

@ExE-Boss ExE-Boss commented Nov 2, 2019

Is that what it looks like in Safari?

I forgot to specify that it only doesn’t work for an empty placeholder.

It works fine‑ish with a space.

Essentially, the behaviour is comparable to that of Google Chrome.

@TimVevida
Copy link

@TimVevida TimVevida commented Sep 14, 2020

@lilles It has been a while since you added the counter, any results yet?

@lilles
Copy link
Member

@lilles lilles commented Sep 15, 2020

2% of page loads has a white-space only fail for :empty:

https://www.chromestatus.com/metrics/feature/timeline/popularity/2624

@annevk
Copy link
Member Author

@annevk annevk commented Sep 15, 2020

@lilles okay, so that means that on pages that use :empty, it results in a non-match 2% of the time where it would have resulted in a match if we ignored whitespace? Per the usual breaking change numbers it seems that would be too high and mean we cannot change the definition of :empty, right?

@ExE-Boss
Copy link
Contributor

@ExE-Boss ExE-Boss commented Sep 15, 2020

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

@Dan503
Copy link

@Dan503 Dan503 commented Sep 15, 2020

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.

@Sora2455
Copy link

@Sora2455 Sora2455 commented Sep 16, 2020

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

@annevk
Copy link
Member Author

@annevk annevk commented Sep 16, 2020

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.

@annevk annevk added the Agenda+ label Sep 16, 2020
@chrishtr
Copy link
Contributor

@chrishtr chrishtr commented Oct 7, 2020

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.

@LeaVerou
Copy link
Contributor

@LeaVerou LeaVerou commented Oct 7, 2020

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

@fantasai fantasai added Needs Data and removed Agenda+ labels Oct 7, 2020
@css-meeting-bot
Copy link
Member

@css-meeting-bot css-meeting-bot commented Oct 7, 2020

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.