Repository navigation
[css-conditional] Make CSSSupportsRule expose whether its condition is met #4240
Description
You currently can't tell directly from a CSSSupportsRule whether the condition is actually fulfilled or not. To do that you have to use CSS.supports(cssSupportsRule.conditionText).
Therefore I suggest to add a getter to CSSSupportsRule (or rather to CSSConditionRule which is overwritten by the derived interfaces) that returns whether the condition is met or not, e.g supported or fulfilled.
Sebastian
Activity
FremyCompany commentedon Aug 26, 2019
Sounds reasonable to me
SebastianZ commentedon Jun 2, 2022
I think that's a very straight-forward addition. So, setting Agenda+ to discuss it in a call.
Sebastian
fantasai commentedon Jun 7, 2022
Maybe
.isTrueor something else more generic? I think it would make sense to add this to CSSConditionRule generically, not just to CSSSupportsRule.emilio commentedon Jun 7, 2022
MediaQueryListhas.matches, maybe that's good enough?emilio commentedon Jun 7, 2022
(as a name, I mean)
emilio commentedon Jun 7, 2022
But on
CSSConditionRuleit's a bit tricky, because container rules need the element as an input too, to know whether the condition matches.SebastianZ commentedon Jun 8, 2022
With the changes for
CSSContainerRulediscussed in #7033, this can stay a simple getter because the query container is determined by the container name and query.Sebastian
SebastianZ commentedon Jun 8, 2022
matchesrather refers to matching elements, though in case ofCSSSupportsRulethis is not the case.isTruesounds a little too generic to me regarding the derived rules. MaybeisConditionMetor something? Anyway, I don't have a strong opinion on the name.Sebastian
svgeesus commentedon Jul 27, 2022
Maybe
met?svgeesus commentedon Jul 27, 2022
But regardess of naming yes, I think we should have such a getter
css-meeting-bot commentedon Jul 27, 2022
The CSS Working Group just discussed
CSSSupportsRule should expose bool, and agreed to the following:RESOLVED: Add .matches to CSSMediaRule and CSSSupportsRuleThe full IRC log of that discussion
<TabAtkins> Topic: CSSSupportsRule should expose bool<faceless> present- (got to dash)
<TabAtkins> github: https://github.com//issues/4240
<astearns> ack chris
<TabAtkins> chris: Perfectly reasonable to have a getter to know whether the condition matches
<TabAtkins> chris: Most discussion is bikeshedding the name, not whether it shoudl exist or not
<TabAtkins> chris: Interested if there's arguments against
<fantasai> TabAtkins: Definitely should exist, could recreate by running it through existing APIs
<astearns> ack dbaron
<emilio> q+
<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
<astearns> ack fantasai
<TabAtkins> STrong agree
<TabAtkins> fantasai: Yeah, suggest putting it on CSSConditionRule superclass, which does exist
<TabAtkins> fantasai: emailio pointed out it's tricky on @container rules since they rely on the element being matched as well
<TabAtkins> fantasai: But we should have consistent naming even if it's individual methods on each subclass
<astearns> ack emilio
<TabAtkins> emilio: Yeah, superclass is tricky because CQs shouldn't have it
<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
<TabAtkins> emilio: So I think it should exist, but not on the superclass
<TabAtkins> TabAtkins: I suggest we just define a getter on the subclasses it makes sense for, yeah
<fantasai> ...
<fantasai> TabAtkins: .matches works, already on MQlist
<fantasai> TabAtkins: meaning carries over well
<TabAtkins> emilio: fwiw, "matches" is what we use internally in Gecko
<TabAtkins> chris: .met would work, but okay with .matches too
<TabAtkins> fantasai: Happy to go with .matches since MQList already has it
<chris> fine with matches
<fantasai> s/.../fantasai: Sure, but what's it called?/
<TabAtkins> astearns: So proposed resolution to add .matches to the relevant conditional rules
<TabAtkins> dholbert: Q about subclasses vs superclass
<TabAtkins> dholbert: Can we put in an intermediate superclass so it's shared?
<fantasai> TabAtkins: IDL supports this, but it is an observable change
<chris> emilio could you propose some IDL in the issue?
<fantasai> TabAtkins: we thought it would be useful for ConditionalRule, but less clear if it's worth it for this
<fantasai> astearns: Which rules are affected?
<emilio> chris: sure, `readonly attribute boolean matches;` on the two individual rules?
<fantasai> TabAtkins: @media and @supports
<TabAtkins> yeah, that's the IDL
<TabAtkins> RESOLVED: Add .matches to CSSMediaRule and CSSSupportsRule
17 remaining items
svgeesus commentedon Jul 17, 2024
re-tagging because the agreed edits from @fantasai are on css-conditional-3
[css-conditional-3] Add .matches to @media and @supports, #4240
svgeesus commentedon Jul 24, 2024
Missing tests collected in separate issue
[css-conditional] Support CSSConditionRule.supports
[css-conditional-3] Support CSSMediaRule.matches