Re: [csswg-drafts] [selectors] Let :matches() have better error-recovery behavior than normal Selectors (#3264)

The CSS Working Group just discussed `Let :matches() have better error-recovery behavior than normal Selectors`, and agreed to the following:

* `RESOLVED: Use media query style invalidation inside pseudo classes that accept selector lists`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Let :matches() have better error-recovery behavior than normal Selectors<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3264<br>
&lt;dael> Rossen: Is TabAtkins  on?<br>
&lt;dael> fantasai: I can take it<br>
&lt;dael> fantasai: When we have a list of selectors :foo, :bar<br>
&lt;dael> fantasai: Browser doesn't rec :foo so the entire style rule is thrown out<br>
&lt;dael> fantasai: That's selectors invalidation.<br>
&lt;dael> fantasai: Other style of invalidation is media queries-like where you throw out a section. So if you have foo, screen we recognize screen<br>
&lt;dael> fantasai: Can't do MQ like because it would break the web for selectors. TabAtkins pointed out we have ability to do it within the new selectors in L4<br>
&lt;dael> fantasai: Issue proposes we adopt MQ-like invalidation inside the pseudoclasses that take selectors.<br>
&lt;dael> fantasai: :foo || :bar, [known selector] we'd only do the part we recognize.<br>
&lt;dael> fantasai: Makes a lot os sense to me together with @supports rule we added. Gives authors much better tools. If they want more granular they can use something else<br>
&lt;dael> Rossen: Sounds reasonable.<br>
&lt;dael> Rossen: Opinions?<br>
&lt;dael> myles: Thoughts from people that teach this? Seems like could be confusing<br>
&lt;dael> Rossen: leaverou or rachelandrew ?<br>
&lt;dbaron> Were you suggesting doing different things for :matches() vs. :is() ?<br>
&lt;tantek> agreed with myles, it could be confusing. would definitely want webdev teacher feedback on this.<br>
&lt;dael> fantasai: dbaron this was from before we renamed. Title should be is. Applies to is, not, has, nth-child, and maybe current<br>
&lt;dael> dbaron: One worry is some have been around for a while and might have compat issues<br>
&lt;dael> fantasai: :not with commas isn't widely supported.<br>
&lt;dael> fantasai: Not with a single argument that's invalid makes the whole thing invalid<br>
&lt;dael> florian: I think not with a comma is supported in Safari and Viviostyle<br>
&lt;dael> fantasai: Not is trickier because it's a negation<br>
&lt;dael> leaverou: Trying to decide error recovery or syntax?<br>
&lt;dael> fantasai: Error recovery<br>
&lt;dael> leaverou: Sounds amazing thing to do. It might be a little confusing, but it's worth it. In talks I only use webkit version and have to mention verbally it's just webkit. As an author I would love it<br>
&lt;dael> emilio: Doesn't solve unknown pseudo elements issue, right?<br>
&lt;dael> fantasai: No, sep.<br>
&lt;dael> emilio: I think that's biggest issue authors want to solve<br>
&lt;dael> fantasai: There's a rule for the webkit<br>
&lt;dael> emilio: Want to style a video control for webkit and edge it's not stanard. That's the biggest source of duplication<br>
&lt;dael> fantasai: This would solve, put it in all one :is<br>
&lt;dael> emilio: Syntax allow psuedo elements inside?<br>
&lt;bradk> I’m still concerned about :not. Can we find out how much authors have :-webkit and commas inside not?<br>
&lt;dael> fantasai: This is work for pseudo classes. Elements is next on agenda<br>
&lt;florian> I support this<br>
&lt;dael> Rossen: bradk point about not and his concern, can we address that now?<br>
&lt;dael> Rossen: Concern is the :not and defining how much authors have commas inside a not?<br>
&lt;dael> florian: It's safari only<br>
&lt;dael> bradk: Safari on iphone is used a lot. :not has been without commas for a while, but it's used in mobile web a lot. That's my suggestion, I'd like actual data<br>
&lt;dael> florian: This is hard data to get. Need to find usage that would break the page if it started working in a different way. That's a judgement call<br>
&lt;dael> Rossen: Another way to ask is if any Apple folks have an issue with this. If they feel comfortable with compat risk we can resolve<br>
&lt;dael> bradk: That solution would be okay<br>
&lt;dael> smfr: I don't think we have enough [missed]<br>
&lt;dael> smfr: I don't thinkw e have enough information to know. When we impl :not we got compat issues b/c people using it in wrong ways<br>
&lt;dael> smfr: No feeling for how common comma use is to know if it's risky<br>
&lt;dael> Rossen: Would you be okay with current proposal in the absense of this information?<br>
&lt;dael> smfr: I think so<br>
&lt;dael> Rossen: Anything else before we try and resolve?<br>
&lt;bradk> No strong objection<br>
&lt;dael> fantasai: Use media query style invalidation inside psuedo classes that accept selector lists<br>
&lt;dael> Rossen: Objections to ^?<br>
&lt;dael> emilio: Would like behavior for :not clarified<br>
&lt;dael> fantasai: Makes sense<br>
&lt;dael> RESOLVED: Use media query style invalidation inside pseudo classes that accept selector lists<br>
&lt;dael> Rossen: fantasai and TabAtkins will have clarification in spec<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3264#issuecomment-440752606 using your GitHub account

Received on Wednesday, 21 November 2018 17:41:33 UTC