contain-css-svelte 1.3.0 → 1.4.1

package/dist/layout/Fieldset.svelte

@@ -54,7 +54,33 @@ const el = $derived(elementProps({
   </fieldset>
 </FormProvider>
 
-<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