contain-css-svelte 1.4.3 → 1.5.0

package/dist/layout/Bar.svelte

@@ -119,6 +119,38 @@ const el = $derived(elementProps({ ...restProps, marginTop, marginBottom }, "bar
    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.
@@ -256,6 +288,24 @@ const el = $derived(elementProps({ ...restProps, marginTop, marginBottom }, "bar
   --_heading-margin-inline: var-with-fallbacks(--heading-margin-inline, bar, 0);
 }
 
+/* Small tier (see $small-max): --bar-padding-small, --bar-gap-small and
+   --bar-min-height-small, each falling back to the regular value. A bar
+   that should be slimmer on a phone says so once, here, instead of every
+   consumer writing its own query. */
+@media (max-width: 600px) {
+  .bar {
+    padding: var(--bar-padding-small, var(--bar-padding, var(--padding, 8px)));
+    gap: var(--bar-gap-small, var(--bar-gap, var(--gap, 8px)));
+    min-height: var(--bar-min-height-small, var(--bar-min-height, var(--bar-height, 3em)));
+  }
+}
+@container (max-width: 600px) {
+  .bar {
+    padding: var(--bar-padding-small, var(--bar-padding, var(--padding, 8px)));
+    gap: var(--bar-gap-small, var(--bar-gap, var(--gap, 8px)));
+    min-height: var(--bar-min-height-small, var(--bar-min-height, var(--bar-height, 3em)));
+  }
+}
 .bar :global(h1),
 .bar :global(h2),
 .bar :global(h3),

package/dist/layout/ColumnContainer.svelte

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

@@ -78,6 +78,38 @@ const el = $derived(elementProps(restProps, "columns", ["gap"]));
    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/Container.svelte

@@ -96,6 +96,38 @@ const el = $derived(elementProps(restProps, "container", [
    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.
@@ -417,9 +449,11 @@ section {
      of fighting a single shared value for both. */
   margin-inline: var(--container-margin-inline, var(--surface-margin-inline, var(--block-margin-inline, var(--margin-inline, auto))));
   margin-block: var(--container-margin-block, var(--surface-margin-block, var(--block-margin-block, var(--margin-block, var(--gap)))));
-  /* Why is this suddenly causing a scroll? */
   container-type: inline-size;
-  overflow-x: hidden;
+  /* Scroll, never clip: content wider than the container (a table, a
+     wide grid, a long unbroken string) must stay reachable on a narrow
+     screen. `hidden` here made it unreachable on phones. */
+  overflow-x: auto;
   height: var(--container-height, 100%);
   overflow-y: auto;
   overflow-y: auto;
@@ -460,6 +494,18 @@ section {
   width: var(--container-width, 100%);
 }
 
+/* Small tier (see $small-max): --container-padding-small, falling back to
+   the regular padding. */
+@media (max-width: 600px) {
+  section {
+    padding: var(--container-padding-small, var(--container-padding, var(--surface-padding, var(--block-padding, var(--padding, 8px)))));
+  }
+}
+@container (max-width: 600px) {
+  section {
+    padding: var(--container-padding-small, var(--container-padding, var(--surface-padding, var(--block-padding, var(--padding, 8px)))));
+  }
+}
 .border {
   border: var(--container-border, var(--surface-border, var(--border, var(--border-width) var(--border-style) var(--border-color))));
 }</style>

package/dist/layout/DataList.svelte

@@ -1,6 +1,6 @@
 <script lang="ts">import { elementProps } from "../util";
 import { COLOR_VARS, PADDING_VARS, RADIUS_VARS, TYPOGRAPHY_VARS, } from "../styleProps";
-let { children, stackable = false, class: className, ...restProps } = $props();
+let { children, stackable = true, class: className, ...restProps } = $props();
 /* The shorthands data-list'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. */
@@ -115,6 +115,38 @@ const el = $derived(elementProps(restProps, "data-list", [
    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/DataList.svelte.d.ts

@@ -4,6 +4,13 @@ import type { BaseStyleProps, ContainProps } from "../types";
 import { type StyleProps } from "../styleProps";
 declare const DataList: import("svelte").Component<ContainProps<HTMLAttributes<HTMLUListElement>, {
     children?: Snippet;
+    /**
+     * In the small tier (a container or viewport 600px or narrower), move
+     * each row's `end` region -- tags, buttons -- onto its own line under
+     * the main content instead of squeezing the main column to a sliver.
+     * On by default; pass `stackable={false}` for rows whose end region is
+     * small enough to stay beside the content on a phone.
+     */
     stackable?: boolean;
 }, BaseStyleProps & {
     marginInline?: string | null;

package/dist/layout/DataListItem.svelte

@@ -193,6 +193,38 @@ function handleKeydown(event) {
    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.
@@ -646,9 +678,31 @@ function handleKeydown(event) {
   border-top-width: 0;
 }
 
-@container (max-width: 640px) {
+/* The shared small tier ($small-max). Text keeps its size here -- a phone
+   is the last place to make it smaller; --data-list-item-font-size-small
+   is there for anyone who wants it anyway. */
+@media (max-width: 600px) {
+  .data-list-item {
+    font-size: var(--data-list-item-font-size-small, var(--_font-size));
+  }
+  :global(.data-list.stackable) .data-list-item.hasStart.hasEnd {
+    grid-template-columns: var(--data-list-item-icon-width, var(--data-list-icon-width, var(--icon-width, var(--data-list-item-icon-size, var(--data-list-icon-size, var(--icon-size, 2.5rem)))))) minmax(0, 1fr);
+    grid-template-areas: "start main" "end end";
+  }
+  :global(.data-list.stackable) .data-list-item.hasStart.hasEnd .end {
+    flex-direction: var(--data-list-item-action-compact-flex-direction, var(--data-list-action-compact-flex-direction, var(--action-compact-flex-direction, row)));
+    flex-wrap: var(--data-list-item-action-compact-wrap, var(--data-list-action-compact-wrap, var(--action-compact-wrap, wrap)));
+    justify-content: var(--data-list-item-action-mobile-justify, var(--data-list-action-mobile-justify, var(--action-mobile-justify, flex-start)));
+    padding-inline-start: calc(var(--data-list-item-icon-width, var(--data-list-icon-width, var(--icon-width, var(--data-list-item-icon-size, var(--data-list-icon-size, var(--icon-size, 2.5rem)))))) + var(--data-list-item-gap, var(--data-list-gap, var(--gap, var(--space)))));
+  }
+  :global(.data-list.stackable) .data-list-item:not(.hasStart).hasEnd {
+    grid-template-columns: minmax(0, 1fr);
+    grid-template-areas: "main" "end";
+  }
+}
+@container (max-width: 600px) {
   .data-list-item {
-    font-size: var(--data-list-item-font-size-small, calc(0.9 * var(--_font-size)));
+    font-size: var(--data-list-item-font-size-small, var(--_font-size));
   }
   :global(.data-list.stackable) .data-list-item.hasStart.hasEnd {
     grid-template-columns: var(--data-list-item-icon-width, var(--data-list-icon-width, var(--icon-width, var(--data-list-item-icon-size, var(--data-list-icon-size, var(--icon-size, 2.5rem)))))) minmax(0, 1fr);

package/dist/layout/Fieldset.svelte

@@ -125,6 +125,38 @@ const el = $derived(elementProps({
    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/Form.svelte

@@ -123,6 +123,38 @@ const el = $derived(elementProps({
    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/FormItem.svelte

@@ -112,6 +112,38 @@ const effectiveLayout = $derived(above ? "above" : below ? "below" : effectiveLa
    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.
@@ -206,15 +238,29 @@ label {
   display: contents;
 }
 
+/* Label and input widths are what they'd like, not what they insist on:
+   a 12em label above its input in a 15em-wide collapsed item, or a fixed
+   input width beside a label in a narrow column, gives way to the item. */
 .label {
   box-sizing: border-box;
   width: var(--form-label-width, 12em);
+  max-width: 100%;
   text-align: var(--form-label-text-align, right);
 }
 
 .input {
   box-sizing: border-box;
   width: var(--form-input-fixed-width, var(--form-input-width));
+  max-width: 100%;
+  min-width: 0;
+}
+
+/* A native input's intrinsic width (~20 characters) is a default, not a
+   requirement -- in a narrow item it fits the space it has. */
+.input :global(input),
+.input :global(select),
+.input :global(textarea) {
+  max-width: 100%;
 }
 
 /* In grid layouts, make the input area stretch fully */

package/dist/layout/GridLayout.svelte

@@ -93,6 +93,38 @@ const el = $derived(elementProps(restProps, "grid-layout", GRID_LAYOUT_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.
@@ -224,4 +256,31 @@ const el = $derived(elementProps(restProps, "grid-layout", GRID_LAYOUT_VARS));
      narrower than the track it was handed -- a `--tile-width` set smaller than
      the grid's item width, say. */
   --justify-items: center;
+}
+
+/* Small tier (see $small-max). Tile tracks follow the tile's own small
+   width -- same precedence, same default -- or a phone gets 160px tiles in
+   192px tracks, one to a row. (Card tracks are already capped at 100% of
+   the grid by the `min()` above.) */
+@media (max-width: 600px) {
+  .tile-grid {
+    --item-width: var(
+      --tile-width-small,
+      var(--tile-width, calc(var(--space-lg, 8px) * 20))
+    );
+  }
+  .grid-layout {
+    gap: var(--grid-layout-gap-small, var(--grid-layout-gap, var(--gap, 8px)));
+  }
+}
+@container (max-width: 600px) {
+  .tile-grid {
+    --item-width: var(
+      --tile-width-small,
+      var(--tile-width, calc(var(--space-lg, 8px) * 20))
+    );
+  }
+  .grid-layout {
+    gap: var(--grid-layout-gap-small, var(--grid-layout-gap, var(--gap, 8px)));
+  }
 }</style>

package/dist/layout/Hero.svelte

@@ -97,6 +97,38 @@ const el = $derived(elementProps(restProps, "hero", [
    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.
@@ -393,6 +425,16 @@ const el = $derived(elementProps(restProps, "hero", [
   width: var(--hero-width, 100%);
   max-width: var(--hero-width, 100%);
   height: var(--hero-height, 100vh);
+  /* Small-viewport units where supported: on a phone, 100vh is the height
+     with the browser's toolbars *hidden*, so a full-height hero's content
+     sits partly under them on first load. */
+  height: var(--hero-height, 100svh);
+  /* Without inline padding, centred hero text runs right to the screen's
+     edges the moment the viewport is narrower than its longest line. */
+  padding-inline: var(--hero-padding-inline, var(--padding, 1rem));
+  /* Lets hero content size itself to the hero (cqi units, @container)
+     rather than to the viewport. */
+  container-type: inline-size;
   /* font-size: var(--hero-font-size, 2rem); */
   box-sizing: border-box;
 }