Re: [csswg-drafts] [css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility (#7551)

Matching _any_ container feature does not match what we would need here. The other proposed solution above doesn't require reference to logic operators. Would this be a more acceptable change from that perspective?

- Account for <general-enclosed> in the container-selection process. As you suggest above, unknown features could invalidate container-selection, and cause the entire query to be unknown.

> In any case this feature has shipped and what is being proposed here is a potentially breaking behavior change. I'm not sure it has been justified sufficiently, or explained why it is safe to do.

The problem is if we ever want to add new dimension features in the future, they would ideally use a syntax that currently falls under 'general enclosed'. That would cause exactly the same potentially backwards-breaking behavior that we are discussing right now, except that it would happen after container queries have gained much higher production use. We could ask for a use-counter here, to prove that it is a 'safe' change now -- but more concerning to me is that the safety of this only gets worse the longer we wait.

It sounds like, either way, the current resolution needs to be revisited. Adding back to the agenda. 

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-1376194244 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 9 January 2023 19:50:50 UTC