Reconsider disabled properties on containers

[ZeeCoder]

As an attempt to avoid circulatory issues, refuse to parse the CSS if it's trying to change the container's width or height.

• Either via a container unit in the same rule where the container was defined,
• Or inside a @container query, whether the value's unit is container unit or not.

Also look into disabling other properties, like padding, which again could affect the container's size.

[ZeeCoder]

It's probably not worth disabling all properties though, like the ability to change the background for instance is nice.
And also, just that wouldn't solve the circular issues anyway.

[ZeeCoder]

More food for thought: sometimes even setting width / height can be harmless.
For example - assuming a "Resize Sensor" of some sort - setting height to: 5cwpx would react to width size change -> where the height's change would trigger the sensor yet again, but this time nothing would change since width didn't change.
For this reason even prohibiting the usage of container units for width / height properties would be unnecessary.
It doesn't solve the problem it's meant to solve, but limits the developer.

[ZeeCoder]

Now however, using cw / ch for the property it relates to must be forbidden.
height: 110chpx would infinitely grow in height for example.

[ZeeCoder]

For now I think restrictions should be lifted, and only obvious cases - like the one above - should be checked, where circular issues would surely arise.

To "properly" address circular issues would be a bigger undertaking:

• Try to detect issues on PostCSS parsing first,
• Maybe a clever algorithm could be written which would detect issues runtime too.

[ZeeCoder]

Use-case: Setting font-size on a button component could result in weird behaviour, if the text can wrap.

1. Font-size changes
2. text grows big, and breaks to multiple lines
3. The container gets bigger
4. Which then sets the font size bigger again
   Then back to 1)