contain-css-svelte 1.4.3 → 1.6.0

package/dist/Card.svelte

@@ -112,6 +112,38 @@ let hasFooter = $derived(Boolean(footer));
    we deliberately avoid everywhere else.
 
    One definition, used by both, so they cannot drift again. */
+/* The "small" size tier: a component whose container is this wide or less
+   is on a phone, or in a pane about that narrow, and sizes itself for it.
+
+   The convention, shared by every component that has a size worth changing
+   there (Card started it; Tile, GridLayout, Bar and Container follow):
+
+     --{component}-{property}-small
+
+   applies inside a small container. What wins there, in order:
+     1. the `-small` variable, if you set it;
+     2. otherwise the regular variable, if you set it -- a size you chose on
+        purpose is not overridden behind your back;
+     3. otherwise the component's own small default, which for most
+        properties is simply its regular default.
+
+   Container queries can't read a custom property, so the breakpoint itself
+   is fixed here rather than themeable. 600px matches Card and SplitPane,
+   which already switched there. (The Sidebar's rail-to-sheet switch,
+   above, is a separate, layout-chrome decision and keeps its own value.) */
+/* Styles for the small tier: the nearest container is narrow, OR the
+   viewport is.
+
+   The container query is the real answer -- a Tile in a 400px pane on a
+   desktop is small. But a container query only matches inside an ancestor
+   that *is* a container, and a component dropped straight into a page (no
+   Page, no Container around it) has none, so on a phone it would never
+   find out. The viewport query covers that: a narrow viewport means every
+   container in it is narrow too, so the two never disagree in the
+   direction that matters.
+
+   An element never queries itself, so on a component that is its own
+   container (Tile, Bar) this asks about the space it was given. */
 /* 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.
@@ -128,6 +160,15 @@ let hasFooter = $derived(Boolean(footer));
   overflow-x: hidden;
   container-type: inline-size;
   width: var(--w);
+  /* --card-width is the size a Card *wants*; it never gets to push past
+     its container. `stretch` is "whatever the parent leaves after my
+     margins", so a 250px card in a 200px pane just becomes a narrower
+     card -- whose own container queries then take it from there. The
+     prefixed lines cover browsers that only know the old keyword. */
+  max-width: 100%;
+  max-width: -moz-available;
+  max-width: -webkit-fill-available;
+  max-width: stretch;
   /* Was a single `margin` shorthand (--card-margin, 16px on every side).
      Split into block/inline -- same default on each axis, so nothing
      visually changes for existing callers -- but now a caller who wants
@@ -887,7 +928,16 @@ section {
 
 /* ── Container queries ──────────────────────────────────── */
 /* NOTE: .card targets the *parent* container; children target the card itself */
-/* Parent context: small — adjust card sizing vars */
+/* Parent context: small (the shared small tier, $small-max -- a small
+   container, or a small viewport when there is no container) — adjust
+   card sizing vars */
+@media (max-width: 600px) {
+  .card {
+    --w: var(--card-width-small);
+    --h: var(--card-height-small);
+    --sidebar-width: calc(var(--card-width-small) - var(--_padding) * 2);
+  }
+}
 @container (max-width: 600px) {
   .card {
     --w: var(--card-width-small);
@@ -898,7 +948,9 @@ section {
 /* Card itself: narrow (≤ --card-width-small: 250px) — tighten typography and spacing */
 @container (max-width: 300px) {
   .card section {
-    font-size: var(--card-font-size-small, calc(0.875 * var(--_font-size)));
+    /* Opt-in only: a narrow card is usually a phone, and text should not
+       shrink there. */
+    font-size: var(--card-font-size-small, var(--_font-size));
   }
   .card header,
   .card section {
@@ -915,7 +967,9 @@ section {
 /* Card itself: wide (≥ --card-width-large: 600px) — expand typography and spacing */
 @container (min-width: 500px) {
   .card section {
-    font-size: var(--card-font-size-large, calc(1.125 * var(--_font-size)));
+    /* Opt-in only: a card's width is a layout fact, not a reason for its
+       text to be a different size from the text beside it. */
+    font-size: var(--card-font-size-large, var(--_font-size));
   }
   .card header,
   .card section {

package/dist/controls/Button.svelte

@@ -107,6 +107,38 @@ const el = $derived(elementProps(restProps, "button", [
    we deliberately avoid everywhere else.
 
    One definition, used by both, so they cannot drift again. */
+/* The "small" size tier: a component whose container is this wide or less
+   is on a phone, or in a pane about that narrow, and sizes itself for it.
+
+   The convention, shared by every component that has a size worth changing
+   there (Card started it; Tile, GridLayout, Bar and Container follow):
+
+     --{component}-{property}-small
+
+   applies inside a small container. What wins there, in order:
+     1. the `-small` variable, if you set it;
+     2. otherwise the regular variable, if you set it -- a size you chose on
+        purpose is not overridden behind your back;
+     3. otherwise the component's own small default, which for most
+        properties is simply its regular default.
+
+   Container queries can't read a custom property, so the breakpoint itself
+   is fixed here rather than themeable. 600px matches Card and SplitPane,
+   which already switched there. (The Sidebar's rail-to-sheet switch,
+   above, is a separate, layout-chrome decision and keeps its own value.) */
+/* Styles for the small tier: the nearest container is narrow, OR the
+   viewport is.
+
+   The container query is the real answer -- a Tile in a 400px pane on a
+   desktop is small. But a container query only matches inside an ancestor
+   that *is* a container, and a component dropped straight into a page (no
+   Page, no Container around it) has none, so on a phone it would never
+   find out. The viewport query covers that: a narrow viewport means every
+   container in it is narrow too, so the two never disagree in the
+   direction that matters.
+
+   An element never queries itself, so on a component that is its own
+   container (Tile, Bar) this asks about the space it was given. */
 /* 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/controls/ButtonLink.svelte

@@ -109,6 +109,38 @@ const iconSlotted = $derived(Boolean(icon));
    we deliberately avoid everywhere else.
 
    One definition, used by both, so they cannot drift again. */
+/* The "small" size tier: a component whose container is this wide or less
+   is on a phone, or in a pane about that narrow, and sizes itself for it.
+
+   The convention, shared by every component that has a size worth changing
+   there (Card started it; Tile, GridLayout, Bar and Container follow):
+
+     --{component}-{property}-small
+
+   applies inside a small container. What wins there, in order:
+     1. the `-small` variable, if you set it;
+     2. otherwise the regular variable, if you set it -- a size you chose on
+        purpose is not overridden behind your back;
+     3. otherwise the component's own small default, which for most
+        properties is simply its regular default.
+
+   Container queries can't read a custom property, so the breakpoint itself
+   is fixed here rather than themeable. 600px matches Card and SplitPane,
+   which already switched there. (The Sidebar's rail-to-sheet switch,
+   above, is a separate, layout-chrome decision and keeps its own value.) */
+/* Styles for the small tier: the nearest container is narrow, OR the
+   viewport is.
+
+   The container query is the real answer -- a Tile in a 400px pane on a
+   desktop is small. But a container query only matches inside an ancestor
+   that *is* a container, and a component dropped straight into a page (no
+   Page, no Container around it) has none, so on a phone it would never
+   find out. The viewport query covers that: a narrow viewport means every
+   container in it is narrow too, so the two never disagree in the
+   direction that matters.
+
+   An element never queries itself, so on a component that is its own
+   container (Tile, Bar) this asks about the space it was given. */
 /* 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/controls/Checkbox.svelte

@@ -135,6 +135,38 @@ let ref = $state(null);
    we deliberately avoid everywhere else.
 
    One definition, used by both, so they cannot drift again. */
+/* The "small" size tier: a component whose container is this wide or less
+   is on a phone, or in a pane about that narrow, and sizes itself for it.
+
+   The convention, shared by every component that has a size worth changing
+   there (Card started it; Tile, GridLayout, Bar and Container follow):
+
+     --{component}-{property}-small
+
+   applies inside a small container. What wins there, in order:
+     1. the `-small` variable, if you set it;
+     2. otherwise the regular variable, if you set it -- a size you chose on
+        purpose is not overridden behind your back;
+     3. otherwise the component's own small default, which for most
+        properties is simply its regular default.
+
+   Container queries can't read a custom property, so the breakpoint itself
+   is fixed here rather than themeable. 600px matches Card and SplitPane,
+   which already switched there. (The Sidebar's rail-to-sheet switch,
+   above, is a separate, layout-chrome decision and keeps its own value.) */
+/* Styles for the small tier: the nearest container is narrow, OR the
+   viewport is.
+
+   The container query is the real answer -- a Tile in a 400px pane on a
+   desktop is small. But a container query only matches inside an ancestor
+   that *is* a container, and a component dropped straight into a page (no
+   Page, no Container around it) has none, so on a phone it would never
+   find out. The viewport query covers that: a narrow viewport means every
+   container in it is narrow too, so the two never disagree in the
+   direction that matters.
+
+   An element never queries itself, so on a component that is its own
+   container (Tile, Bar) this asks about the space it was given. */
 /* 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.
@@ -145,6 +177,10 @@ let ref = $state(null);
 .label-sizing-box {
   position: relative;
   display: inline-block;
+  /* An inline-block wraps as a whole first, so short labels in a row just
+     flow onto the next line; only a label longer than the whole row wraps
+     its own text (the invisible sizer and the real label wrap alike). */
+  max-width: 100%;
 }
 
 .label-sizing-box .checkbox-item {

package/dist/controls/CircleButton.svelte

@@ -100,6 +100,38 @@ const el = $derived(elementProps(restProps, "circle-button", [
    we deliberately avoid everywhere else.
 
    One definition, used by both, so they cannot drift again. */
+/* The "small" size tier: a component whose container is this wide or less
+   is on a phone, or in a pane about that narrow, and sizes itself for it.
+
+   The convention, shared by every component that has a size worth changing
+   there (Card started it; Tile, GridLayout, Bar and Container follow):
+
+     --{component}-{property}-small
+
+   applies inside a small container. What wins there, in order:
+     1. the `-small` variable, if you set it;
+     2. otherwise the regular variable, if you set it -- a size you chose on
+        purpose is not overridden behind your back;
+     3. otherwise the component's own small default, which for most
+        properties is simply its regular default.
+
+   Container queries can't read a custom property, so the breakpoint itself
+   is fixed here rather than themeable. 600px matches Card and SplitPane,
+   which already switched there. (The Sidebar's rail-to-sheet switch,
+   above, is a separate, layout-chrome decision and keeps its own value.) */
+/* Styles for the small tier: the nearest container is narrow, OR the
+   viewport is.
+
+   The container query is the real answer -- a Tile in a 400px pane on a
+   desktop is small. But a container query only matches inside an ancestor
+   that *is* a container, and a component dropped straight into a page (no
+   Page, no Container around it) has none, so on a phone it would never
+   find out. The viewport query covers that: a narrow viewport means every
+   container in it is narrow too, so the two never disagree in the
+   direction that matters.
+
+   An element never queries itself, so on a component that is its own
+   container (Tile, Bar) this asks about the space it was given. */
 /* 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.