/**
 * core/group — "Allow shrinking below content".
 *
 * WHY IT EXISTS. A flex item's `min-width` defaults to `auto`, which floors it at the min-content
 * width of its subtree. `core/column` neutralises that in core's own stylesheet
 * (`.wp-block-column { min-width: 0 }`); `core/group` does not. So the moment a group is used as a
 * flex child — which is the ONLY way to size an item responsively, because a column carries its
 * width as an inline `flex-basis` that no `@mobile`/`@tablet` tier can override — any content with
 * a wide intrinsic minimum drags the item past the size the design asked for.
 *
 * MEASURED on this port: a card holding an `insta/slider` was given `flex-basis: 535px` and rendered
 * 848px, because the slider's slides are `min-width: 100%; flex-shrink: 0`. The slider's viewport is
 * already `overflow: hidden`, so nothing is lost by letting the item reach its declared size.
 *
 * WHY A STYLE AND NOT AN ATTRIBUTE. `min-width` has no representation in theme.json's style
 * vocabulary at the base tier — `dimensions.minWidth` is gated by the block's `supports`, and
 * core/group declares no such support, so the value is silently dropped. (It DOES apply inside a
 * responsive tier, which is precisely the asymmetry that makes a base-tier fix impossible.)
 *
 * OPT-IN. A group that does not select this keeps `min-width: auto`, so no existing layout moves.
 */

.wp-block-group.is-style-shrinkable {
	min-width: 0;
}