Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-contain-3] Add CSSOM API for CSSContainerRule #7033

Open
lilles opened this issue Feb 10, 2022 · 10 comments
Open

[css-contain-3] Add CSSOM API for CSSContainerRule #7033

lilles opened this issue Feb 10, 2022 · 10 comments

Comments

@lilles
Copy link
Member

lilles commented Feb 10, 2022

The spec needs to specify a CSSContainerRule interface for @container rules. It should extend the CSSConditionRule.

lilles pushed a commit to lilles/csswg-drafts that referenced this issue Feb 10, 2022
Might need to add @container specifics prose for conditionText like we
have for @support, but the syntax is e.g. currently missing
<general-enclosed>.
@mirisuzanne
Copy link
Contributor

mirisuzanne commented Feb 17, 2022

Still fairly new to CSSOM definitions. Can we rely on the attribute CSSOMString conditionText already defined in CSSConditionRule (similar to @supports), or do we need additional attributes here (similar to @media)?

As a start, this is a slightly modified version of what we have for @supports:

The {{CSSContainerRule}} interface represents a ''@container'' rule.

<pre class='idl'>
[Exposed=Window]
interface CSSContainerRule : CSSConditionRule {
};
</pre>

<dl class='idl-attributes'>
  <dt><code>conditionText</code> of type <code>CSSOMString</code> (CSSContainerRule-specific definition for attribute on CSSConditionRule)
  <dd>The <code>conditionText</code> attribute (defined on the <code>CSSConditionRule</code> parent rule),
    on getting, must return the condition that was specified,
    without any logical simplifications,
    so that the returned condition will evaluate to the same result
    as the specified condition
    in any conformant implementation of this specification
    (including implementations that implement future extensions
    allowed by the <<general-enclosed>> extensibility mechanism in this specification).
    In other words,
    token stream simplifications are allowed
    (such as reducing whitespace to a single space
    or omitting it in cases where it is known to be optional),
    but logical simplifications (such as removal of unneeded parentheses,
    or simplification based on evaluating results) are not allowed.
</dl>

@tabatkins
Copy link
Member

You should be able to rely on it; just copy @supports, yeah.

@mirisuzanne
Copy link
Contributor

Drafted. Agenda+ for a resolution on this approach.

@anttijk
Copy link

anttijk commented Feb 21, 2022

Please make any attributes readonly.

@lilles
Copy link
Member Author

lilles commented Feb 21, 2022

conditionText is resolved to be readonly in issue #6819, but the spec hasn't been changed yet. I added the NeedsEdits label to the issue.

@astearns astearns removed the Agenda+ label Feb 22, 2022
@astearns
Copy link
Member

I think we could resolve on this approach asynchronously. Once the spec has the readonly edit in, I’ll call for objections here and on the mailing list.

@mirisuzanne
Copy link
Contributor

Since conditionText is defined in a separate spec (css-conditional-3), I don't think the readonly change requires any edits on this CSSContainerRule definition?

@lilles
Copy link
Member Author

lilles commented Feb 22, 2022

Since conditionText is defined in a separate spec (css-conditional-3), I don't think the readonly change requires any edits on this CSSContainerRule definition?

No.

@mirisuzanne mirisuzanne moved this from In progress to Needs Edits in Container Queries [css-contain] Feb 23, 2022
andruud pushed a commit to andruud/csswg-drafts that referenced this issue May 20, 2022
- Add containerName, containerQuery.
- Reorganize syntax so that conditionText and containerQuery both map
  to productions which make sense.

w3c#7033
@SebastianZ
Copy link
Contributor

Maybe we should also have a getter for the query container. So, depending on what's set for containerName and containerQuery it returns the related element.

Sebastian

@SebastianZ
Copy link
Contributor

In the discussion in #4240, I realized that it may also be useful for authors as well as developer tools to have a getter that exposes the matching query container.

So something like queryContainer that uses the name and condition and spits out the element that currently matches them.

Sebastian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

6 participants