If I understand this right, you're saying: if my `.user` or `.something-else` has a `.modal .message .error`, then colour all the text in the `.user` red.
I think this is a mistake in system design. CSS doesn't know or care or work with what a user is, what a foo is, what a bar is or how any of those interact conceptually. CSS operates on the rendered output of decisions made at that level: it shouldn't make those decisions, nor encode knowledge of those decisions. That's what JS is for, and what it's better at.
I think it makes much more sense architecturally to have JS respond to whatever condition triggered the error state by updating some metadata on everything involved (User{}, Booking{}, Etc{}).
```
// pseudo JS
uiEvents.subscribe('error message', () => {
appState.User.hasBadData = true;
})
uiEvents.subscribe('error message', () => {
appState.Booking.hasBadData = true;
})
function validateForm(fields) {
fields.forEach(field => {
if(field.hasError) {
uiEvents.publish({some: "error message"});
}
}
}
// pseudo React/Vue/whatever in pseudo TypeScript
render(({user, booking}: TAppState) => (
<>
<div class={`user ${user.hasBadData? 'user--error' : ''}`}>/\* user icons and text */</div>
<div class={`booking ${booking.hasBadData? 'booking--error' : ''}`}>
/* booking stuff \*
</div>
<>
});
```
You could replace all the JS with server-side logic (which would probably take it closer to the "single source of truth" of users and booking anyway). Further, maybe you're making application with multiple communication modalities, and you want to play a sound or trigger speech when the user enters bad data, instead/as well as colouring everything red. CSS can't help you there. It's much better to keep the logic, state and behaviours out of the CSS and use it only to "dress up" the rendered markup, otherwise you make maintenance harder.