contain-css-svelte 1.4.3 → 1.6.0

package/dist/layout/Stack.svelte

@@ -103,6 +103,38 @@ const el = $derived(elementProps({ justify, align: resolvedAlign, gap, ...restPr
    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/layout/TabBar.svelte

@@ -2,7 +2,7 @@
 import TabItem from "../controls/TabItem.svelte";
 import { elementProps } from "../util";
 import { COLOR_VARS, TYPOGRAPHY_VARS, } from "../styleProps";
-let { sticky = false, active = $bindable(null), items = [], onchange, children, class: className, ...restProps } = $props();
+let { sticky = false, wrap = false, active = $bindable(null), items = [], onchange, children, actions, class: className, ...restProps } = $props();
 /* The shorthands this component's own CSS backs, one group per mixin
    it includes. The Props type is derived from this same array, so what
    the component accepts and what it emits cannot drift apart. */
@@ -14,7 +14,7 @@ const el = $derived(elementProps(restProps, "tab-bar", TAB_BAR_VARS));
 let lastActive = $state(active);
 </script>
 
-<div class={["tabs", className]} class:sticky {...el}>
+{#snippet strip()}
   <Bar
     padding="0"
     --button-height="var(--tab-bar-height, 3em)"
@@ -23,11 +23,15 @@ let lastActive = $state(active);
     --bar-fg="var(--tab-bar-fg, var(--bar-fg))"
     --bar-bg="var(--tab-bar-bg, var(--bar-bg))"
     --bar-align="var(--tab-bar-align, flex-end)"
-    --bar-overflow="hidden"
+    --bar-overflow="var(--tab-bar-overflow, auto hidden)"
+    --bar-wrap="var(--tab-bar-wrap, nowrap)"
     --bar-border-left="var(--tab-bar-border-left, none)"
     --bar-border-right="var(--tab-bar-border-right, none)"
     --bar-border-top="var(--tab-bar-border-top, none)"
-    --bar-border-bottom="var(--tab-bar-border-bottom, var(--border-width) var(--border-style) var(--border-color))"
+    --bar-border-bottom={actions
+      ? "none"
+      : "var(--tab-bar-border-bottom, var(--border-width) var(--border-style) var(--border-color))"}
+    --bar-margin-block={actions ? "0" : undefined}
   >
     {#each items as item}
       {@const value = typeof item === "string" ? item : item.value}
@@ -44,6 +48,23 @@ let lastActive = $state(active);
     {/each}
     {@render children?.()}
   </Bar>
+{/snippet}
+
+<div
+  class={["tabs", className]}
+  class:sticky
+  class:wrap-tabs={wrap}
+  class:has-actions={!!actions}
+  {...el}
+>
+  {#if actions}
+    <!-- The strip and the actions share the row; the underline moves to
+         the whole row so it runs under both. -->
+    <div class="tab-strip">{@render strip()}</div>
+    <div class="tab-actions">{@render actions()}</div>
+  {:else}
+    {@render strip()}
+  {/if}
 </div>
 
 <style>/* Per-level heading (h1-h6) box/typography properties, resolved to PRIVATE,
@@ -117,6 +138,38 @@ let lastActive = $state(active);
    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.
@@ -125,7 +178,7 @@ let lastActive = $state(active);
   */
 /* Convenience groupings */
 div > :global(.bar),
-div > :global(div > .bar) {
+div > :global(svelte-css-wrapper > .bar) {
   --link-bg: var(--tab-bar-link-bg, var(--bar-link-bg, var(--surface-link-bg, inherit)));
   --link-fg: var(--tab-bar-link-fg, var(--bar-link-fg, var(--surface-link-fg, inherit)));
   --_bg-mix-color: var(--tab-bar-bg-mix-color, var(--bar-bg-mix-color, var(--surface-bg-mix-color, var(--bg-mix-color, transparent))));
@@ -224,12 +277,78 @@ div > :global(div > .bar) {
   align-items: var(--tab-bar-align, var(--align, flex-end));
   border-bottom: var(--tab-bar-border-bottom, var(--border-width) var(--border-style) var(--border-color));
   border-left: var(--tab-bar-border-left, none);
-  border-right: var(--tab-bar-border-left, none);
-  border-top: var(--tab-bar-border-left, none);
+  border-right: var(--tab-bar-border-right, none);
+  border-top: var(--tab-bar-border-top, none);
   gap: var(--tab-bar-gap, var(--space-md));
-  overflow: hidden;
+  /* Tabs stay one strip. When they don't all fit -- four tabs on a phone --
+     the strip scrolls sideways rather than dropping the last tab onto a
+     second row, which reads as a broken tab set (the second row floats
+     under the active tab's baseline). `wrap` (or --tab-bar-wrap: wrap)
+     brings wrapping back. */
+  overflow-x: auto;
+  overflow-y: hidden;
+  scrollbar-width: thin;
+}
+
+/* The scroll also goes in through --bar-overflow on the Bar itself (x
+   scrolls, y clipped), so it holds even where a consumer's own CSS beats
+   the rule above. */
+.wrap-tabs {
+  --tab-bar-wrap: wrap;
+}
+
+.has-actions {
+  display: flex;
+  align-items: flex-end;
+  gap: var(--tab-bar-gap, var(--gap, var(--space-md, 8px)));
+  border-bottom: var(--tab-bar-border-bottom, var(--border-width) var(--border-style) var(--border-color));
+  margin-block: var(--tab-bar-margin-block, 0 1em);
+}
+
+/* The strip takes the room and gives way first: min-width 0 lets it
+   shrink below its tabs' width, at which point it scrolls (above). */
+.tab-strip {
+  flex: 1 1 auto;
+  min-width: 0;
+}
+
+/* The row carries the underline; the strip's own (from the rule above)
+   would double it and stop short of the actions. */
+.tab-strip > :global(svelte-css-wrapper > .bar),
+.tab-strip > :global(.bar) {
+  border-bottom: none;
+}
+
+.tab-actions {
+  flex: 0 1 auto;
+  display: flex;
+  flex-wrap: wrap;
+  justify-content: flex-end;
+  align-items: center;
+  gap: var(--tab-bar-actions-gap, var(--gap, var(--space-md, 8px)));
+  padding-block-end: var(--tab-bar-actions-padding, var(--padding, var(--space-sm, 4px)));
 }
 
+/* Small tier: actions get their own row, above the tabs, so the tabs stay
+   attached to the panel they switch. */
+@media (max-width: 600px) {
+  .has-actions {
+    flex-direction: column-reverse;
+    align-items: stretch;
+  }
+  .tab-actions {
+    justify-content: flex-start;
+  }
+}
+@container (max-width: 600px) {
+  .has-actions {
+    flex-direction: column-reverse;
+    align-items: stretch;
+  }
+  .tab-actions {
+    justify-content: flex-start;
+  }
+}
 .sticky {
   position: sticky;
   top: calc(-1 * var(--surface-padding, var(--block-padding, var(--padding, 8px))));

package/dist/layout/TabBar.svelte.d.ts

@@ -3,6 +3,14 @@ import type { ContainProps } from "../types";
 import { type StyleProps } from "../styleProps";
 declare const TabBar: import("svelte").Component<ContainProps<HTMLAttributes<HTMLDivElement>, {
     sticky?: boolean;
+    /**
+     * Let tabs that don't fit wrap onto another row. By default the tab
+     * strip stays one row and scrolls sideways when it runs out of room,
+     * which keeps the active tab attached to its panel; wrapping suits a
+     * long set of short, filter-like tabs where seeing them all at once
+     * matters more. Same as setting --tab-bar-wrap: wrap.
+     */
+    wrap?: boolean;
     active?: string | {
         label: string;
         value: string;
@@ -16,6 +24,14 @@ declare const TabBar: import("svelte").Component<ContainProps<HTMLAttributes<HTM
         value: string;
     } | null) => void;
     children?: import("svelte").Snippet;
+    /**
+     * Controls that belong to the tab row but aren't tabs -- a Refresh
+     * button, a "New..." action. They sit at the end of the row when there
+     * is room, and on their own row above the tabs in the small tier (see
+     * the -small variables), so they never squeeze the tabs or stack into
+     * a tall column beside them on a phone.
+     */
+    actions?: import("svelte").Snippet;
 }, StyleProps<readonly ["bg", "fg", "fontFamily", "fontSize", "fontWeight", "lineHeight", "letterSpacing", "textAlign", "textTransform", "textDecoration", "fontVariant"]>>, {}, "active">;
 type TabBar = ReturnType<typeof TabBar>;
 export default TabBar;

package/dist/layout/Table.svelte

@@ -308,15 +308,22 @@ function observeColumns() {
     </div>
   {/if}
 {:else}
-  <table>
-    {#if thead}
-      {@render thead?.()}
-    {/if}
-    {#if tbody}
-      {@render tbody?.()}
-    {/if}
-    {@render children?.()}
-  </table>
+  <!-- A table can't shrink below its content, so on a narrow screen it is
+       wider than its container. It scrolls sideways in its own strip rather
+       than widening (or, under an overflow-clipping ancestor, being cut off
+       by) everything around it. Not done for the sticky variants: a scroll
+       box would become the sticky header's scroll container. -->
+  <div class="table-scroll">
+    <table>
+      {#if thead}
+        {@render thead?.()}
+      {/if}
+      {#if tbody}
+        {@render tbody?.()}
+      {/if}
+      {@render children?.()}
+    </table>
+  </div>
 {/if}
 
 <style>/* Per-level heading (h1-h6) box/typography properties, resolved to PRIVATE,
@@ -390,6 +397,38 @@ function observeColumns() {
    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.
@@ -836,6 +875,18 @@ table :global(tr > th:first-child:has(~ td)) {
   border-right: var(--table-first-row-bottom-border, var(--table-thick-border, 3px) solid var(--table-first-row-border-color, var(--secondary-bg))) !important;
 }
 
+.table-scroll {
+  max-width: 100%;
+  overflow-x: auto;
+  /* Room for the table's own box-shadow, which the scroll box would
+     otherwise clip. */
+  padding: var(--table-scroll-padding, 0 0 4px);
+  /* A visible scrollbar, not the hover-revealed one the other scroll areas
+     use: a phone has no hover, and the bar is the only sign that the table
+     goes on past the edge. */
+  scrollbar-width: thin;
+}
+
 .table-container {
   position: sticky;
   top: 0;

package/dist/layout/Tile.svelte

@@ -142,6 +142,38 @@ const className = $derived(props.class);
    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.
@@ -451,15 +483,22 @@ const className = $derived(props.class);
   --_box-shadow:
     var(--tile-shadow-distance, var(--surface-shadow-distance, var(--shadow-distance, var(--space)))) var(--tile-shadow-distance, var(--surface-shadow-distance, var(--shadow-distance, var(--space)))) var(--tile-shadow-blur, var(--surface-shadow-blur, var(--shadow-blur, var(--space)))) var(--tile-shadow-color, var(--surface-shadow-color, var(--shadow-color, rgba(127, 127, 127, 0.4))));
   box-shadow: var(--_box-shadow);
-  width: var(--tile-width, calc(var(--space-lg) * 24));
-  /* Override typography max-width */
-  max-width: var(--tile-width, calc(var(--space-lg) * 24));
+  /* --_tile-width is resolved in the sizing block below. max-width also
+     overrides the typography mixin's prose measure. */
+  width: var(--_tile-width);
+  max-width: var(--_tile-width);
   display: inline-flex;
   vertical-align: top;
   flex-direction: column;
   justify-content: var(--tile-justify, var(--justify, flex-start));
   align-items: var(--tile-align, var(--align, center));
   container-type: inline-size;
+  /* A Tile is a fixed-size object. Inline-size containment makes its
+     min-content width zero, so as a flex item in any row that runs out of
+     room (a RowContainer lane, a nowrap Inline) it would be squeezed to a
+     sliver with its text spilling out. Hold the size; let the row wrap or
+     scroll instead. */
+  flex-shrink: 0;
 }
 
 button.tile,
@@ -610,12 +649,56 @@ label.tile:has(:global(input:focus-visible)) {
   box-shadow: var(--focus-ring-box-shadow, 0 0 0 3px var(--focus-shadow-color, rgba(100, 150, 250, 0.5)));
 }
 
-/* Sizing code */
+/* Sizing.
+
+   One width, declared once. There used to be two -- `--space-lg * 24`
+   (192px) above and `200px` here -- and the narrower max-width quietly won,
+   so tiles rendered 192px wide but 267px tall (200 * 4/3).
+
+   The 3:4 shape is a *minimum* height rather than a fixed one, so a tile
+   with more content than its shape holds grows to fit instead of spilling
+   out. Set --tile-height to pin it (it sets the minimum too, or the shape
+   would win over a shorter pinned height); --tile-aspect-ratio to change
+   the shape.
+
+   Not the `aspect-ratio` property: a percentage --tile-width (a tile
+   filling a ColumnContainer rail) would then be 4/3 of the rail tall. As a
+   calc, a percentage height against an auto-height parent resolves to
+   nothing and the tile is as tall as its content, which is what those
+   layouts have always relied on. */
 .tile {
-  width: var(--tile-width, 200px);
-  height: var(--tile-height, calc(var(--tile-width, 200px) * 1.333));
+  --_tile-width: var(--tile-width, calc(var(--space-lg, 8px) * 24));
+  --_tile-min-height: var(
+    --tile-height,
+    calc(var(--_tile-width) / (var(--tile-aspect-ratio, 3 / 4)))
+  );
+  height: var(--tile-height, auto);
+  min-height: var(--_tile-min-height);
 }
 
+/* Small tier (see $small-max): two tiles side by side on a phone instead of
+   one 192px tile alone in a 360px row. 160px * 2 + a gap fits a 328px
+   content box, i.e. a 360px phone with 16px gutters. */
+@media (max-width: 600px) {
+  .tile {
+    --_tile-width: var(
+      --tile-width-small,
+      var(--tile-width, calc(var(--space-lg, 8px) * 20))
+    );
+    height: var(--tile-height-small, var(--tile-height, auto));
+    min-height: var(--tile-height-small, var(--_tile-min-height));
+  }
+}
+@container (max-width: 600px) {
+  .tile {
+    --_tile-width: var(
+      --tile-width-small,
+      var(--tile-width, calc(var(--space-lg, 8px) * 20))
+    );
+    height: var(--tile-height-small, var(--tile-height, auto));
+    min-height: var(--tile-height-small, var(--_tile-min-height));
+  }
+}
 /* Checkbox code */
 .tile {
   position: relative;

package/dist/misc/CodeInner.svelte

@@ -87,6 +87,38 @@ let highlightedCode = $derived.by(() => {
    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/misc/Progress.svelte

@@ -134,6 +134,38 @@ let halfFull = $derived(fillFraction > 0.5);
    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/misc/Tag.svelte

@@ -101,6 +101,38 @@ const el = $derived(elementProps(restProps, "tag", TAG_VARS));
    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/overlays/Dialog.svelte

@@ -148,6 +148,38 @@ let ref;
    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/overlays/Tooltip.svelte

@@ -368,6 +368,38 @@ async function showPopover() {
    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.