- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Nov 2018 17:41:31 +0000
- To: public-css-archive@w3.org
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> <dael> Topic: Let :matches() have better error-recovery behavior than normal Selectors<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3264<br> <dael> Rossen: Is TabAtkins on?<br> <dael> fantasai: I can take it<br> <dael> fantasai: When we have a list of selectors :foo, :bar<br> <dael> fantasai: Browser doesn't rec :foo so the entire style rule is thrown out<br> <dael> fantasai: That's selectors invalidation.<br> <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> <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> <dael> fantasai: Issue proposes we adopt MQ-like invalidation inside the pseudoclasses that take selectors.<br> <dael> fantasai: :foo || :bar, [known selector] we'd only do the part we recognize.<br> <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> <dael> Rossen: Sounds reasonable.<br> <dael> Rossen: Opinions?<br> <dael> myles: Thoughts from people that teach this? Seems like could be confusing<br> <dael> Rossen: leaverou or rachelandrew ?<br> <dbaron> Were you suggesting doing different things for :matches() vs. :is() ?<br> <tantek> agreed with myles, it could be confusing. would definitely want webdev teacher feedback on this.<br> <dael> fantasai: dbaron this was from before we renamed. Title should be is. Applies to is, not, has, nth-child, and maybe current<br> <dael> dbaron: One worry is some have been around for a while and might have compat issues<br> <dael> fantasai: :not with commas isn't widely supported.<br> <dael> fantasai: Not with a single argument that's invalid makes the whole thing invalid<br> <dael> florian: I think not with a comma is supported in Safari and Viviostyle<br> <dael> fantasai: Not is trickier because it's a negation<br> <dael> leaverou: Trying to decide error recovery or syntax?<br> <dael> fantasai: Error recovery<br> <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> <dael> emilio: Doesn't solve unknown pseudo elements issue, right?<br> <dael> fantasai: No, sep.<br> <dael> emilio: I think that's biggest issue authors want to solve<br> <dael> fantasai: There's a rule for the webkit<br> <dael> emilio: Want to style a video control for webkit and edge it's not stanard. That's the biggest source of duplication<br> <dael> fantasai: This would solve, put it in all one :is<br> <dael> emilio: Syntax allow psuedo elements inside?<br> <bradk> I’m still concerned about :not. Can we find out how much authors have :-webkit and commas inside not?<br> <dael> fantasai: This is work for pseudo classes. Elements is next on agenda<br> <florian> I support this<br> <dael> Rossen: bradk point about not and his concern, can we address that now?<br> <dael> Rossen: Concern is the :not and defining how much authors have commas inside a not?<br> <dael> florian: It's safari only<br> <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> <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> <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> <dael> bradk: That solution would be okay<br> <dael> smfr: I don't think we have enough [missed]<br> <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> <dael> smfr: No feeling for how common comma use is to know if it's risky<br> <dael> Rossen: Would you be okay with current proposal in the absense of this information?<br> <dael> smfr: I think so<br> <dael> Rossen: Anything else before we try and resolve?<br> <bradk> No strong objection<br> <dael> fantasai: Use media query style invalidation inside psuedo classes that accept selector lists<br> <dael> Rossen: Objections to ^?<br> <dael> emilio: Would like behavior for :not clarified<br> <dael> fantasai: Makes sense<br> <dael> RESOLVED: Use media query style invalidation inside pseudo classes that accept selector lists<br> <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