- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Sep 2018 16:47:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `decide on :blank`, and agreed to the following: * `RESOLVED: :empty does cover whitespace` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: decide on :blank<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1967<br> <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<br> <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.<br> <dael> fantasai: Issue was can we have a selector that means actually empty.<br> <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<br> <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.<br> <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<br> <dael> Rossen_: What's the favored proposal in your PoV?<br> <bkardell_> q+<br> <dael> fantasai: Ideally :empty would look from the author propsective and ignore whitepsace. If need more options make it a functional pseudo class<br> <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.<br> <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.<br> <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.<br> <gregwhitworth> I agree with TabAtkins here. Probably a good default is not to include white space<br> <dael> bkardell_: How close can you come to what people want.<br> <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<br> <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.<br> <TabAtkins> We cant' ignore <style>, unfortunately - you can display those! (and make them contenteditable, for live-editting of a stylesheet).<br> <dael> bkardell_: Not sure why we say the use case is that unless we're sure.<br> <TabAtkins> But yeah, ignoring whitespace-only text nodes seems A-OK<br> <dael> florian: Not sure I see the use case for a selector that only selects link elements.<br> <dael> florian: Why would you want to select these things specifically?<br> <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.<br> <dael> florian: I hear you but don't agree<br> <TabAtkins> You can display a <link> too...<br> <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/<br> <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6230<br> <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.<br> <dael> florian: As TabAtkins put in IRC you can display most of what you wrote.<br> <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.<br> <dael> fantasai: If a wysiwyg author thinks the thing is empty depends on what you see. We can only help authors in markup<br> <dael> bkardell_: Yes, I think what a lot of people want is not possible. Thinking through and making the least surprising thing seems good.<br> <dael> florian: I wonder about comments. Are they gone before we do selector parsing?<br> <dael> TabAtkins: They don't show in the dom tree that selectors see<br> <dael> florian: Only whitepsace means whitespace and comments<br> <dael> TabAtkins: And other nodes<br> <dael> florian: As long as it falls out<br> <dael> bkardell_: Empty clearly specifies that<br> <dael> fantasai: If our goal is not surprising [missed]<br> <dael> TabAtkins: Selector modal only sees syntax nodes. Other elements aren't seen by selectors.<br> <dael> florian: I think we circled around. Can we resolve on :empty also allowing whiespace?<br> <TabAtkins> s/syntax nodes/element and text nodes/<br> <dael> fantasai: sgtm<br> <TabAtkins> +1<br> <dael> Rossen_: Proposal is :empty does cover whitespace?<br> <dael> florian: Yep.<br> <dael> Rossen_: Other opinions?<br> <dael> Rossen_: Objections to :empty does cover whitespace?<br> <bkardell_> so to clarify<br> <dael> RESOLVED: :empty does cover whitespace<br> <bkardell_> lol<br> <bkardell_> nm<br> <dael> bkardell_: Wanted to clarify we're changing the existing definition of :empty?<br> <dael> florian: Yes.<br> <dael> bkardell_: Last WG there were concerns about that where someone left an :empty that was false as a test. No concerns on that?<br> <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<br> <bkardell_> yes, me too, what fantasai said<br> <dael> florian: But it's rarely used anyway<br> <bkardell_> ok, no real objection then<br> <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.<br> <dael> Rossen_: Anything else to resolve?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1967#issuecomment-424788796 using your GitHub account
Received on Wednesday, 26 September 2018 16:47:19 UTC