preventing cycles?

[bkardell]

It might be worth consider things like creating a new stacking context and/or defaulting or demanding this to be contained/overflowed/clipped to avoid the possibility of (easily) creating cycles through the complex machinery that is CSS.

[Heydon]

@bkardell Hi! I am unaware of which cycles in which complex machinery you are talking about. Could you be more specific?

I'm not sure how overflow (etc) is liable to affect the way <watched-box> behaves that would be out of the ordinary for any HTML element.

[bkardell]

Sorry for the confusion, I thought somehow we had discussed this or you had the context and this was just me leaving a note, and then I missed the notification that you replied..

For context - there are a lot of hard problems in sorting out 'container queries' - it's possible to create all kinds of cycles. ResizeObserver prevents one kind - that developers can't influence - it keeps things from getting stuck within the CSS layout itself with .no hope of resolution. It can't prevent you from creating cycles though.

Here's a codepen (https://codepen.io/bkardell/pen/ZEbrORp) using your thing to illustrate with the sort of simple canonical example:

.w-gt-15em {
  width: 10em;
}

It's easy to say "well... don't do that" - but this example is only used because it's so easy to understand... The number of ways that you can influence that size are myriad and it is astonishingly easy to create situations that behave like that and hard to find or predict them.

Basically though: If you can affect the thing that you are also measuring - this is ultimately the case. There are new developments in CSS like containment which are trying to give you tools to say things like 'the stuff inside this can't affect this box'. However, we're not there yet: Implementation of this is currently behind in WebKit and it is currently lacking the ability to do 'containment in a single direction' (auto height) which is often what you want, but we're working on it. So --- Short of that, you need to find some way/strategy to approximate the effects of preventing circularity. There are lots of good tries and things that get you closer... If you create a new stacking context via positioning, for example, you limit the effects you can have back up, for example. If you overflow, same.

I'd be happy to meet up and discuss some prior art/efforts to discuss. Unfortunately I can't tell you specifically "do this" because there are degrees of perfect and trade-offs here. With no mitigation at all tho, you'll almost certainly run into this. I did using Phil Walton's which is the same idea, and my own first take which was similar (ie, both custom elements + resize observer). Several months ago I worked with some folks on another take which I think was pretty good, but wound up in a proposal so we didn't share it.

[Heydon]

@bkardell Thanks for the lengthy explanation of what you meant. I understand the issue better having read this, and Tab's article (https://www.xanthir.com/b4PR0). I think I'll add a warning to the README, and cite your example. Of course, positioning doesn't really fix this specific issue, but I imagine it can help when child elements are involved.

[bkardell]

Yeah, good.. Sorry for the length :(

Maybe someone should write a good piece that all of these could link to so people can try to make good choices. Like I say, it's just an easy example: In that same pen the same rule could have used font-size, margin, padding, whitespace, linebreaking, min-width, max-width, maybe transforms, etc etc etc to blow it up just as easily, but less obviously - and , if you don't contain it somehow - that winds up going into any child too.

It would be great if the advice could somehow easily say "generally, don't try to style the thing you are observing and make sure you try to contain the stuff inside the thing you are observing so they don't either" and here's a link explaining why..