- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jul 2022 16:31:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSSSupportsRule should expose bool`, and agreed to the following: * `RESOLVED: Add .matches to CSSMediaRule and CSSSupportsRule` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: CSSSupportsRule should expose bool<br> <faceless> present- (got to dash)<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4240<br> <astearns> ack chris<br> <TabAtkins> chris: Perfectly reasonable to have a getter to know whether the condition matches<br> <TabAtkins> chris: Most discussion is bikeshedding the name, not whether it shoudl exist or not<br> <TabAtkins> chris: Interested if there's arguments against<br> <fantasai> TabAtkins: Definitely should exist, could recreate by running it through existing APIs<br> <astearns> ack dbaron<br> <emilio> q+<br> <TabAtkins> dbaron: agree it shoudl exist. At some point when I drafted the IDL I made a common base class for supports and media. Might not exist now, but if we make a bool like this we should make it common between the rules<br> <astearns> ack fantasai<br> <TabAtkins> STrong agree<br> <TabAtkins> fantasai: Yeah, suggest putting it on CSSConditionRule superclass, which does exist<br> <TabAtkins> fantasai: emailio pointed out it's tricky on @container rules since they rely on the element being matched as well<br> <TabAtkins> fantasai: But we should have consistent naming even if it's individual methods on each subclass<br> <astearns> ack emilio<br> <TabAtkins> emilio: Yeah, superclass is tricky because CQs shouldn't have it<br> <TabAtkins> emilio: I think the API for CQs would look a bit different, would be a function that takes an element, and it would force layout, etc<br> <TabAtkins> emilio: So I think it should exist, but not on the superclass<br> <TabAtkins> TabAtkins: I suggest we just define a getter on the subclasses it makes sense for, yeah<br> <fantasai> ...<br> <fantasai> TabAtkins: .matches works, already on MQlist<br> <fantasai> TabAtkins: meaning carries over well<br> <TabAtkins> emilio: fwiw, "matches" is what we use internally in Gecko<br> <TabAtkins> chris: .met would work, but okay with .matches too<br> <TabAtkins> fantasai: Happy to go with .matches since MQList already has it<br> <chris> fine with matches<br> <fantasai> s/.../fantasai: Sure, but what's it called?/<br> <TabAtkins> astearns: So proposed resolution to add .matches to the relevant conditional rules<br> <TabAtkins> dholbert: Q about subclasses vs superclass<br> <TabAtkins> dholbert: Can we put in an intermediate superclass so it's shared?<br> <fantasai> TabAtkins: IDL supports this, but it is an observable change<br> <chris> emilio could you propose some IDL in the issue?<br> <fantasai> TabAtkins: we thought it would be useful for ConditionalRule, but less clear if it's worth it for this<br> <fantasai> astearns: Which rules are affected?<br> <emilio> chris: sure, `readonly attribute boolean matches;` on the two individual rules?<br> <fantasai> TabAtkins: @media and @supports<br> <TabAtkins> yeah, that's the IDL<br> <TabAtkins> RESOLVED: Add .matches to CSSMediaRule and CSSSupportsRule<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4240#issuecomment-1196983719 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 July 2022 16:31:19 UTC