Handle a subset of cyclic issues with statically analyzing the CSS

[ZeeCoder]

While container query data is extracted from the css with PostCSS, we could throw an error if the code would obviously cause a loop.

Basically, if a container query on the container itself would apply styles that would invalidate the query based on its conditions, then the query is invalid and should throw an error.

Such a case would be:

div {
  @container (width > 200px) {
    width: 100px;
  }
}

It's easy to see (and detect) why this query would cause a loop, and hence the plugin shouldn't allow for it.

The following however should be fine:

div {
  @container (width > 100px) and (width < 200px) {
    width: 150px;
  }
}

Using the same method, we can predict that after applying the new width value, the query still applies, and so it wouldn't cause a loop, even though the query affects the property it queries.

The following is a more interesting, and still valid case:

div {
  @container (width > 100px) and (width < 200px) {
    width: 150px;
  }

  @container (width > 140px) and (width < 300px) {
    width: 250px;
  }
}

In this case, once the width gets more than 100, it's width first gets snapped to 150px, which in turn immediately triggers the second query, setting the width to 250px, thus ending the evaluation.

The end state is that the width is 250px, with only the second query applying.

Again, no loop occurred, and it seems to be enough to check each query individually if it would invalidate itself.

[tjbenneche]

This also seems to happen if you change the value for padding on the container element enough that the calculated width brings it back out of the query, e.g. change padding: 16px to padding: 24px at a @container (width > 600px) and the loop will trigger

[ZeeCoder]

Yeah I guess certain edge cases could be detected, like:

div {
  width: 90px;
  padding: 10px;

  @container (width >= 100px) {
    padding: 5px;
  }
}

If the width is not specified though, then it's harder to know if it's an issue.