contain-css-svelte 1.2.3 → 1.4.0

package/dist/layout/Accordion.svelte

@@ -53,7 +53,33 @@ function onAccordionClicked(e) {
   {@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
@@ -61,6 +87,18 @@ function onAccordionClicked(e) {
    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/Bar.svelte

@@ -48,7 +48,33 @@ const el = $derived(elementProps({ ...restProps, marginTop, marginBottom }, "bar
   {@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
@@ -56,6 +82,18 @@ const el = $derived(elementProps({ ...restProps, marginTop, marginBottom }, "bar
    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.
@@ -181,6 +219,16 @@ const el = $derived(elementProps({ ...restProps, marginTop, marginBottom }, "bar
   overflow: var(--bar-overflow, visible);
   /* Reset form label width in horizontal context */
   --form-label-width: auto;
+  /* A Bar lays its content out in a flex row, so a heading dropped inside
+     it must not inherit an ancestor Container's (or any other typography
+     container's) prose-measure margins -- auto inline margins in a flex
+     row eat the row's free space and drag the heading toward the middle,
+     fighting `justify-content: space-between`. This is a plain custom
+     property override, not a selector reset: it wins for anything inside
+     `.bar` purely by being the nearest ancestor to declare it, regardless
+     of stylesheet order, so it doesn't need `!important` or a doubled
+     class the way an outside consumer's workaround for this used to. */
+  --_heading-margin-inline: var-with-fallbacks(--heading-margin-inline, bar, 0);
 }
 
 .bar :global(h1),

package/dist/layout/ColumnContainer.svelte

@@ -21,7 +21,33 @@ const el = $derived(elementProps(restProps, "column-container", COLUMN_CONTAINER
   {@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, "column-container", COLUMN_CONTAINER
    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/Columns.svelte

@@ -7,7 +7,33 @@ const el = $derived(elementProps(restProps, "columns", ["gap"]));
   {@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
@@ -15,6 +41,18 @@ const el = $derived(elementProps(restProps, "columns", ["gap"]));
    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.