The problem is that you're triggering the media query off the window's width still, and not the parent element's width. So it runs into the same problem mentioned in the article.
Right, but the width of the parent element in general depends on the width of your component, and then things are just bad.
The thing about the viewport width is that it's actually fixed no matter what things inside the viewport are doing, which means you _can_ base the behavior of things inside it on the width of the viewport.
The only real alternative is to have invariants where your component's width/height is determined and it's somehow enforced that no matter how you lay out stuff inside it won't affect those numbers. Basically think the entirety of your component inside an iframe, but without the separate script global and baggage.
Sorry, I actually meant just "element's width" not "parent". But you're right it definitely gets complicated, and you know way better than I do about which pieces are impossible and which aren't :)
The viewport query is a lot easier from an implementors point of view for sure, but it's also a lot less useful from a developer's point of view.
Would it be possible to have a way of only basing the element-specific query off of the state of the element before element-query-level styles had been applied?
For example, take an element that who's height is less than 100px. And say it has a query for `height > 80px` that hid a child element, which then kicked the element's height down to 75px. Technically the query would be undone, but maybe since it is a query-specific change, it doesn't factor in.
And it gets even more complicated when considering well what about a child's or parent's queries on top of that I'm sure.
All I know is while I'm writing these styles, I have very defined things that I want to do, that can be expressed in words perfectly clearly, and if I were able to express them in code it would completely solve tons of headaches I have with managing CSS. Ideally we could figure out a syntax and implementation that can translate those kinds of thoughts into code that works.
Ian, the problem is that CSS is a constraint description language, not an imperative language. So there is no "before" or "after"; there's just a state...
On the one hand this means that as things change it updates dynamically and all.
On the other it means that you can't just base queries on some "before" state. :(
I think we all agree that there are use cases that need solving here, for sure. We just need to figure out how to do it... Ideally while not precluding parallelized evaluation of CSS selector matching, style computation, and layout, which doesn't make things any easier.
In your example you're referring to the max-width of the viewport. In Ian's example, he's referring to the max-width of the `.testimonial` element itself.
