contain-css-svelte 1.2.3 → 1.4.0

package/dist/layout/Inline.svelte

@@ -32,7 +32,33 @@ const el = $derived(elementProps({ justify, align, gap, wrap, ...restProps }, "i
   {@render children?.()}
 </div>
 
-<style>/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
+<style>/* Per-level heading (h1-h6) box/typography properties, resolved to PRIVATE,
+   inheriting custom properties (--_h1-color, --_h2-font-size, etc) rather than
+   assigned directly to a matched h1-h6 selector. Nothing in this file matches
+   an actual heading element anymore -- see typography-context.css (vars/), which
+   is the single, global, :where()-scoped rule that actually reads these vars
+   and applies them to real elements. That split is what lets a component
+   nested arbitrarily deep (through <article>, <Tile>, whatever) still get the
+   nearest ancestor's heading styling: these are ordinary inherited custom
+   properties, so DOM proximity decides which component's values apply, not
+   selector specificity or stylesheet order. See AGENTS-INTERNAL.md. */
+/* All six heading levels' context vars in one call -- what every
+   "typography container" component (Container, Card, Tile, TextLayout, ...)
+   includes on itself once, alongside the shared --_heading-* vars below. */
+/* Shared prose-measure group: p, blockquote, dl, ul, ol. li/dt/dd don't get
+   their own vars -- they're never wider than their ul/ol/dl parent's own
+   max-width box, so they're already bounded for free by ordinary block
+   layout, not by anything selector-based reaching them individually. */
+/* p specifically also gets the fuller typography-props-bare treatment
+   (paragraph-prefixed), which -- same as in the original selector-based
+   version -- is declared/consumed AFTER the shared prose vars above, so it
+   wins for whichever properties both groups set. */
+/* The first paragraph in a typography context (p:first-of-type, or a p right
+   after a heading) gets its own, slightly different treatment -- larger lede
+   text, no top margin. Structural matching (:first-of-type, `h1 + p`) still
+   has to happen where the real element is, in the global consumer rule; only
+   the VALUES move to context vars here. */
+/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
    one value (both sides equal) or two (start end), so there is no separate
    "which side" prop to remember and no 4-value shorthand order to get wrong.
    Defaults to 0 on purpose -- unlike padding-props above, a margin that
@@ -40,6 +66,18 @@ const el = $derived(elementProps({ justify, align, gap, wrap, ...restProps }, "i
    day this mixin got added to a new component. Callers opt in with an actual
    value. (Container does not use this mixin: it wants --gap/auto as its
    defaults, which do not fit the "0 unless asked" contract here.) */
+/* The width at or below which a Sidebar swaps its grab-bar rail for the sheet
+   affordance -- a floating button that opens a panel over the content.
+
+   Page has to agree with Sidebar about this, because Page is what floats the
+   aside out of flow and reserves the strip of padding the sheet button sits
+   in. They used to disagree: Sidebar switched at 512px and Page at 600px,
+   which left a band between 513 and 600 where Page had already lifted the
+   aside out of the layout while the Sidebar inside it was still showing a
+   rail -- a grab bar floating on top of the content, which is the affordance
+   we deliberately avoid everywhere else.
+
+   One definition, used by both, so they cannot drift again. */
 /* Warning: because we define a fallback
   media query, the media query can override the container
   if we stack a bunch of these in a row and aren't thoughtful about the order.
@@ -60,6 +98,12 @@ const el = $derived(elementProps({ justify, align, gap, wrap, ...restProps }, "i
   border-bottom: var(--inline-border-bottom, var(--border-bottom, var(--inline-border, var(--border, none))));
   border-left: var(--inline-border-left, var(--border-left, var(--inline-border, var(--border, none))));
   border-radius: var(--inline-border-radius, var(--border-radius, none));
+  /* A layout helper, not a surface: padding comes only from
+     --inline-padding (or the `padding` prop), never from the theme's
+     --padding. box-props falls back to --padding, which is inherited, so
+     without this every Inline picked up the page's padding -- or
+     whatever padding an enclosing Card set. */
+  --_padding: var(--inline-padding, 0);
   --_margin-block: var(--inline-margin-block, var(--margin-block, 0));
   --_margin-inline: var(--inline-margin-inline, var(--margin-inline, 0));
   margin-block: var(--_margin-block);

package/dist/layout/MenuList.svelte

@@ -26,7 +26,33 @@ const el = $derived(elementProps(restProps, "menu", [
   {@render children?.()}
 </ul>
 
-<style>/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
+<style>/* Per-level heading (h1-h6) box/typography properties, resolved to PRIVATE,
+   inheriting custom properties (--_h1-color, --_h2-font-size, etc) rather than
+   assigned directly to a matched h1-h6 selector. Nothing in this file matches
+   an actual heading element anymore -- see typography-context.css (vars/), which
+   is the single, global, :where()-scoped rule that actually reads these vars
+   and applies them to real elements. That split is what lets a component
+   nested arbitrarily deep (through <article>, <Tile>, whatever) still get the
+   nearest ancestor's heading styling: these are ordinary inherited custom
+   properties, so DOM proximity decides which component's values apply, not
+   selector specificity or stylesheet order. See AGENTS-INTERNAL.md. */
+/* All six heading levels' context vars in one call -- what every
+   "typography container" component (Container, Card, Tile, TextLayout, ...)
+   includes on itself once, alongside the shared --_heading-* vars below. */
+/* Shared prose-measure group: p, blockquote, dl, ul, ol. li/dt/dd don't get
+   their own vars -- they're never wider than their ul/ol/dl parent's own
+   max-width box, so they're already bounded for free by ordinary block
+   layout, not by anything selector-based reaching them individually. */
+/* p specifically also gets the fuller typography-props-bare treatment
+   (paragraph-prefixed), which -- same as in the original selector-based
+   version -- is declared/consumed AFTER the shared prose vars above, so it
+   wins for whichever properties both groups set. */
+/* The first paragraph in a typography context (p:first-of-type, or a p right
+   after a heading) gets its own, slightly different treatment -- larger lede
+   text, no top margin. Structural matching (:first-of-type, `h1 + p`) still
+   has to happen where the real element is, in the global consumer rule; only
+   the VALUES move to context vars here. */
+/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
    one value (both sides equal) or two (start end), so there is no separate
    "which side" prop to remember and no 4-value shorthand order to get wrong.
    Defaults to 0 on purpose -- unlike padding-props above, a margin that
@@ -34,6 +60,18 @@ const el = $derived(elementProps(restProps, "menu", [
    day this mixin got added to a new component. Callers opt in with an actual
    value. (Container does not use this mixin: it wants --gap/auto as its
    defaults, which do not fit the "0 unless asked" contract here.) */
+/* The width at or below which a Sidebar swaps its grab-bar rail for the sheet
+   affordance -- a floating button that opens a panel over the content.
+
+   Page has to agree with Sidebar about this, because Page is what floats the
+   aside out of flow and reserves the strip of padding the sheet button sits
+   in. They used to disagree: Sidebar switched at 512px and Page at 600px,
+   which left a band between 513 and 600 where Page had already lifted the
+   aside out of the layout while the Sidebar inside it was still showing a
+   rail -- a grab bar floating on top of the content, which is the affordance
+   we deliberately avoid everywhere else.
+
+   One definition, used by both, so they cannot drift again. */
 /* Warning: because we define a fallback
   media query, the media query can override the container
   if we stack a bunch of these in a row and aren't thoughtful about the order.

package/dist/layout/Page.svelte

@@ -89,7 +89,33 @@ onMount(() => {
   </footer>
 </section>
 
-<style>/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
+<style>/* Per-level heading (h1-h6) box/typography properties, resolved to PRIVATE,
+   inheriting custom properties (--_h1-color, --_h2-font-size, etc) rather than
+   assigned directly to a matched h1-h6 selector. Nothing in this file matches
+   an actual heading element anymore -- see typography-context.css (vars/), which
+   is the single, global, :where()-scoped rule that actually reads these vars
+   and applies them to real elements. That split is what lets a component
+   nested arbitrarily deep (through <article>, <Tile>, whatever) still get the
+   nearest ancestor's heading styling: these are ordinary inherited custom
+   properties, so DOM proximity decides which component's values apply, not
+   selector specificity or stylesheet order. See AGENTS-INTERNAL.md. */
+/* All six heading levels' context vars in one call -- what every
+   "typography container" component (Container, Card, Tile, TextLayout, ...)
+   includes on itself once, alongside the shared --_heading-* vars below. */
+/* Shared prose-measure group: p, blockquote, dl, ul, ol. li/dt/dd don't get
+   their own vars -- they're never wider than their ul/ol/dl parent's own
+   max-width box, so they're already bounded for free by ordinary block
+   layout, not by anything selector-based reaching them individually. */
+/* p specifically also gets the fuller typography-props-bare treatment
+   (paragraph-prefixed), which -- same as in the original selector-based
+   version -- is declared/consumed AFTER the shared prose vars above, so it
+   wins for whichever properties both groups set. */
+/* The first paragraph in a typography context (p:first-of-type, or a p right
+   after a heading) gets its own, slightly different treatment -- larger lede
+   text, no top margin. Structural matching (:first-of-type, `h1 + p`) still
+   has to happen where the real element is, in the global consumer rule; only
+   the VALUES move to context vars here. */
+/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
    one value (both sides equal) or two (start end), so there is no separate
    "which side" prop to remember and no 4-value shorthand order to get wrong.
    Defaults to 0 on purpose -- unlike padding-props above, a margin that
@@ -97,6 +123,18 @@ onMount(() => {
    day this mixin got added to a new component. Callers opt in with an actual
    value. (Container does not use this mixin: it wants --gap/auto as its
    defaults, which do not fit the "0 unless asked" contract here.) */
+/* The width at or below which a Sidebar swaps its grab-bar rail for the sheet
+   affordance -- a floating button that opens a panel over the content.
+
+   Page has to agree with Sidebar about this, because Page is what floats the
+   aside out of flow and reserves the strip of padding the sheet button sits
+   in. They used to disagree: Sidebar switched at 512px and Page at 600px,
+   which left a band between 513 and 600 where Page had already lifted the
+   aside out of the layout while the Sidebar inside it was still showing a
+   rail -- a grab bar floating on top of the content, which is the affordance
+   we deliberately avoid everywhere else.
+
+   One definition, used by both, so they cannot drift again. */
 /* Warning: because we define a fallback
   media query, the media query can override the container
   if we stack a bunch of these in a row and aren't thoughtful about the order.
@@ -415,7 +453,11 @@ footer {
   overflow: hidden;
 }
 
-@container (max-width: 600px) {
+/* Must match Sidebar's own compact breakpoint exactly -- everything in
+   this block exists to accommodate the sheet affordance, so switching at a
+   different width than the Sidebar does leaves a band where Page has
+   floated the aside but the Sidebar still shows a rail. */
+@container (max-width: 512px) {
   .side-by-side {
     gap: 0;
   }

package/dist/layout/RowContainer.svelte

@@ -21,7 +21,33 @@ const el = $derived(elementProps(restProps, "row-container", ROW_CONTAINER_VARS)
   {@render children?.()}
 </section>
 
-<style>/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
+<style>/* Per-level heading (h1-h6) box/typography properties, resolved to PRIVATE,
+   inheriting custom properties (--_h1-color, --_h2-font-size, etc) rather than
+   assigned directly to a matched h1-h6 selector. Nothing in this file matches
+   an actual heading element anymore -- see typography-context.css (vars/), which
+   is the single, global, :where()-scoped rule that actually reads these vars
+   and applies them to real elements. That split is what lets a component
+   nested arbitrarily deep (through <article>, <Tile>, whatever) still get the
+   nearest ancestor's heading styling: these are ordinary inherited custom
+   properties, so DOM proximity decides which component's values apply, not
+   selector specificity or stylesheet order. See AGENTS-INTERNAL.md. */
+/* All six heading levels' context vars in one call -- what every
+   "typography container" component (Container, Card, Tile, TextLayout, ...)
+   includes on itself once, alongside the shared --_heading-* vars below. */
+/* Shared prose-measure group: p, blockquote, dl, ul, ol. li/dt/dd don't get
+   their own vars -- they're never wider than their ul/ol/dl parent's own
+   max-width box, so they're already bounded for free by ordinary block
+   layout, not by anything selector-based reaching them individually. */
+/* p specifically also gets the fuller typography-props-bare treatment
+   (paragraph-prefixed), which -- same as in the original selector-based
+   version -- is declared/consumed AFTER the shared prose vars above, so it
+   wins for whichever properties both groups set. */
+/* The first paragraph in a typography context (p:first-of-type, or a p right
+   after a heading) gets its own, slightly different treatment -- larger lede
+   text, no top margin. Structural matching (:first-of-type, `h1 + p`) still
+   has to happen where the real element is, in the global consumer rule; only
+   the VALUES move to context vars here. */
+/* Logical, not top/bottom/left/right: margin-block/margin-inline already take
    one value (both sides equal) or two (start end), so there is no separate
    "which side" prop to remember and no 4-value shorthand order to get wrong.
    Defaults to 0 on purpose -- unlike padding-props above, a margin that
@@ -29,6 +55,18 @@ const el = $derived(elementProps(restProps, "row-container", ROW_CONTAINER_VARS)
    day this mixin got added to a new component. Callers opt in with an actual
    value. (Container does not use this mixin: it wants --gap/auto as its
    defaults, which do not fit the "0 unless asked" contract here.) */
+/* The width at or below which a Sidebar swaps its grab-bar rail for the sheet
+   affordance -- a floating button that opens a panel over the content.
+
+   Page has to agree with Sidebar about this, because Page is what floats the
+   aside out of flow and reserves the strip of padding the sheet button sits
+   in. They used to disagree: Sidebar switched at 512px and Page at 600px,
+   which left a band between 513 and 600 where Page had already lifted the
+   aside out of the layout while the Sidebar inside it was still showing a
+   rail -- a grab bar floating on top of the content, which is the affordance
+   we deliberately avoid everywhere else.
+
+   One definition, used by both, so they cannot drift again. */
 /* Warning: because we define a fallback
   media query, the media query can override the container
   if we stack a bunch of these in a row and aren't thoughtful about the order.