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-conditional] Element queries #10509

Open
romainmenke opened this issue Jun 28, 2024 · 2 comments
Open

[css-conditional] Element queries #10509

romainmenke opened this issue Jun 28, 2024 · 2 comments

Comments

@romainmenke
Copy link
Member

romainmenke commented Jun 28, 2024

Container queries allow us to query a container for specific conditions, including values of custom properties through style() queries.

But they do not allow us to query the element itself.

In #10064 there is a proposal for inline conditions that do allow setting values conditionally when an element has a specific value. Implementers indicated that this would be possible

Can we have the same as an at rule?

I am assuming that this needs to be highly restricted as explained in #10064 (only style() queries with custom properties?)

.foo {
  background-color: blue;
  color: white;
  border-radius: 2px;

  @element style(--color: pink) {
    background-color: pink;
    color: black;
    border-radius: 4px;
  }
}

This example would result in a pink background on any element with class .foo when it also has --color: pink.


Nested vs. not nested gives interesting possibilities:

/* style multiple variations for `.foo`: */
.foo {
  background-color: blue;

  @element style(--color: pink) {
    background-color: pink;
  }

  @element style(--color: green) {
    background-color: green;
  }
}

/* style multiple variable elements: */
@element style(--color: green) {
  .foo {
    background-color: green;
  }

  .bar {
   color: green;
  }
}

Benefits I see to this syntax:

  • allows setting multiple declarations with a single condition
  • values can be easily invalid at parse time
@romainmenke romainmenke changed the title [css-container] Element queries [css-contain] Element queries Jun 28, 2024
@mirisuzanne mirisuzanne changed the title [css-contain] Element queries [css-conditional] Element queries Jun 28, 2024
@mirisuzanne
Copy link
Contributor

mirisuzanne commented Jun 28, 2024

Re-targeted this against css-conditional, since container queries are being moved over there, and out of the contain spec.

If we can do something like this, it would be useful. I'd be curious about trying to integrate it more into container queries - but I'm not sure if that only makes it more complicated.

The primary limitation here that CQs solve is the potential for dependency loops. As I understand it, that's easier to resolve property by property (with the if() function). If we create a loop with this syntax, does it invalidate the entire block?

.foo {
  --color: pink;
  background-color: blue;

  @element style(--color: pink) {
    --color: not-pink; /* certainly this is invalid */
    background-color: pink; /* but is this applied? */
  }
}

I imagine we can come up with an answer to that question, as far as feature design goes. But I'm not sure how hard it is to implement.

@kizu
Copy link
Member

kizu commented Jun 28, 2024

My thinking: we already can have multiple ways to have inline conditionals: https://lea.verou.me/blog/2024/css-conditionals-now, and some of them working almost as “block”-level ones as well (the @keyframes one), and then at some point we will have proper inline conditionals (as already mentioned), and any block-level conditional can be expressed as an inline one, a block-level @element () (or @if, in case we'd want to align it with the inline one) could be purely a syntax sugar and a shortcut.

Of course, that is if we'd treat them the same.

If we create a loop with this syntax, does it invalidate the entire block?

If we were to work around such conditionals with inline ones, any IACVT variables used for that condition will result in everything inside becoming also IACVT.

Then, if we will have something like !revertable (#10443) (and in some cases possible to work around today with revert-layer (https://kizu.dev/layered-toggles/)), instead of completely nuking all the affected properties we could just fall back to the previous declarations.

Interestingly, only the element itself will be affected in this way: any nested styles could already be expressed as container queries, which properly handle reverting styles when not applying.

.foo {
  --color: pink; /* becomes IACVT */
  @element style(--color: pink) {
    --color: not-pink;
    & .bar {
        background-color: pink;
    }
  }
}

In the above block, authors could separate the & .bar into a container query, which could be cumbersome, but will work as intended. I don't think there is any other way it should behave for @element, as there is no better behavior than just not applying styles similar to CQ here.

Thus, my proposal is: if an element query creates a loop in a condition, all affected styles on the element itself should be treated as !revertable, and any nested styles should be treated as covered by the same container query.

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

No branches or pull requests

3 participants