contain-css-svelte 1.4.3 → 1.6.0

package/dist/controls/Input.svelte

@@ -86,6 +86,38 @@ const el = $derived(elementProps(restProps, "input", INPUT_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/controls/RadioButton.svelte

@@ -113,6 +113,38 @@ function handleChange() {
    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.
@@ -123,6 +155,10 @@ function handleChange() {
 .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 .radio-item {
@@ -176,7 +212,6 @@ label.radio-item {
   box-sizing: border-box;
   user-select: none;
   gap: var(--radio-button-space, var(--toggle-space, var(--space-md)));
-  white-space: nowrap;
   cursor: var(--radio-button-cursor, var(--clickable-cursor, var(--cursor, pointer)));
 }
 

package/dist/controls/Select.svelte

@@ -18,6 +18,9 @@ let observer;
 let resizeObserver;
 let targetWidth = $state("");
 let optionButtons = $state([]);
+// The subset of optionButtons the resize observer is currently watching, so
+// the $effect below can tell "nothing changed" from "rewire".
+let observedButtons = [];
 onMount(() => {
     tick().then(() => updateOptions());
     /*
@@ -40,14 +43,37 @@ onMount(() => {
             attributeFilter: ["data-html", "value", "label", "selected"],
         });
     }
-    // Observe size changes in option buttons
     resizeObserver = new ResizeObserver(() => updateTargetWidth());
-    optionButtons.forEach((button) => resizeObserver.observe(button));
     return () => {
         observer.disconnect();
         resizeObserver.disconnect();
     };
 });
+/*
+  optionButtons is populated by `bind:this` inside the {#each options}
+  block below, so it only ever reflects the CURRENT option list once Svelte
+  has reconciled the DOM -- which happens asynchronously relative to the
+  updateOptions() call that rebuilt `options`. Re-deriving the observed set
+  here, every time that binding changes, is what keeps the ResizeObserver
+  in sync in both directions: a button added once the list grows longer
+  gets observed, and one removed when the list shrinks is dropped instead
+  of lingering as a stale (and eventually null) target.
+
+  Guarded by reference comparison so an unrelated re-render that leaves the
+  same buttons in place doesn't thrash disconnect()/observe() every time.
+*/
+$effect(() => {
+    if (!resizeObserver)
+        return;
+    const current = optionButtons.filter((button) => Boolean(button));
+    const unchanged = current.length === observedButtons.length &&
+        current.every((button, i) => button === observedButtons[i]);
+    if (unchanged)
+        return;
+    resizeObserver.disconnect();
+    current.forEach((button) => resizeObserver.observe(button));
+    observedButtons = current;
+});
 let options = $state([]);
 let activeOption = $state(null);
 let updateQueued = false;
@@ -73,12 +99,29 @@ function updateOptions() {
             html: richHtml.trim(),
         });
     }
+    /*
+      optionButtons is bound by index from the {#each options} block below,
+      so when the option list shrinks, the array's tail is left holding
+      targets for <li>s that no longer render. (Svelte nulls each removed
+      binding's own slot as it tears the element down, but that happens once
+      the DOM catches up with this reassignment, not synchronously here --
+      so truncate now rather than leave the old length around in the
+      meantime.) Trimming it here, before the {#each} re-renders, keeps it
+      from ever describing more options than currently exist.
+    */
+    if (optionButtons.length > options.length) {
+        optionButtons.length = options.length;
+    }
     activeOption = options[selectElement.selectedIndex];
     updateTargetWidth();
 }
 function updateTargetWidth() {
     let maxWidth = 0;
     for (let button of optionButtons) {
+        // A stale or not-yet-bound slot (see updateOptions() above) -- skip it
+        // rather than crash on a null bind:this target.
+        if (!button)
+            continue;
         if (button.offsetWidth > maxWidth) {
             maxWidth = button.offsetWidth;
         }
@@ -212,6 +255,38 @@ $effect(() => {
    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.
@@ -318,6 +393,9 @@ select,
   background-color: var(--_background-color);
   color: var(--_color);
   width: var(--select-width, var(--target-width, var(--dropdown-menu-width, min(12em, 100vw))));
+  /* The measured width fits the longest option; the container may be
+     narrower than that. Truncate (below) rather than overflow. */
+  max-width: 100%;
   text-overflow: ellipsis;
   font-family: var(--select-font-family, var(--input-font-family, var(--ui-font-family, var(--font-family, unset))));
   text-transform: var(--select-text-transform, var(--input-text-transform, var(--ui-text-transform, var(--text-transform, unset))));

package/dist/controls/Slider.svelte

@@ -88,6 +88,38 @@ const el = $derived(elementProps(restProps, "slider", ["bg", "fg", "padding", "w
    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/TabItem.svelte

@@ -100,6 +100,38 @@ const el = $derived(elementProps(restProps, "tab", [
    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.
@@ -238,6 +270,10 @@ const el = $derived(elementProps(restProps, "tab", [
 .tab > :global(div > button) {
   border-radius: var(--tab-border-radius, var(--border-radius) var(--border-radius) 0 0);
   margin: 0;
+  /* In a TabBar that scrolls, a tab keeps its label on one line and its
+     full width; squeezing the labels is what made them wrap. */
+  flex-shrink: 0;
+  white-space: nowrap;
 }
 
 .tab.active > :global(button),

package/dist/controls/Toggle.svelte

@@ -117,6 +117,38 @@ const effectiveOnLabel = $derived(onLabel || children);
    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/dropdowns/DropdownMenu.svelte

@@ -255,7 +255,9 @@ let popoverDiv = $state();
     aria-expanded={isOpen ? "true" : "false"}
     aria-controls={id}
   >
-    {#if label}{@render label()}{:else}Menu{/if}
+    <span class="trigger-label"
+      >{#if label}{@render label()}{:else}Menu{/if}</span
+    >
   </button>
   <div
     {id}
@@ -358,6 +360,38 @@ let popoverDiv = $state();
    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.
@@ -497,6 +531,20 @@ button:focus-visible {
 
 button {
   position: relative;
+  /* In a crowded row (a toolbar, a phone-width header) the trigger gives
+     way before its neighbours do: never wider than the space it was given,
+     its label on one line and truncated with an ellipsis (below). */
+  max-width: 100%;
+}
+
+/* The clipping lives on this inner span, not the button: overflow other
+   than visible moves an inline-level box's baseline to its bottom edge,
+   which would drop the trigger out of line with text beside it. */
+.trigger-label {
+  display: block;
+  white-space: nowrap;
+  overflow: hidden;
+  text-overflow: ellipsis;
 }
 
 .dropdown-content :global(.menu) {
@@ -993,6 +1041,10 @@ button {
 
 nav {
   position: relative;
+  /* Lets a flex/grid parent shrink the menu below its label's width, so the
+     trigger's ellipsis can kick in instead of the row overflowing. */
+  min-width: 0;
+  max-width: 100%;
 }
 
 [popover] {

package/dist/index.d.ts

@@ -4,6 +4,9 @@ import Button from "./controls/Button.svelte";
 import ButtonLink from "./controls/ButtonLink.svelte";
 import Checkbox from "./controls/Checkbox.svelte";
 import CircleButton from "./controls/CircleButton.svelte";
+import GroupedToggle from "./controls/GroupedToggle.svelte";
+import GroupedToggleItem from "./controls/GroupedToggleItem.svelte";
+import GroupedRadioItem from "./controls/GroupedRadioItem.svelte";
 import Input from "./controls/Input.svelte";
 import MiniButton from "./controls/MiniButton.svelte";
 import RadioButton from "./controls/RadioButton.svelte";
@@ -51,6 +54,7 @@ export type { BaseStyleProps, MarginStyleProps, ContainerStyleProps, BarStylePro
 export { Tag };
 export { Hero };
 export { TabItem };
+export { GroupedToggle, GroupedToggleItem, GroupedRadioItem };
 export { Button, ButtonLink, CircleButton, Checkbox, Input, Slider, Toggle, RadioButton, MiniButton, Select, Option, };
 export { Bar, ColumnContainer, Container, GridLayout, GridRow, Inline, MenuList, Page, ResponsiveText, RowContainer, Stack, TabBar, };
 export { TextLayout, Code, Accordion };

package/dist/index.js

@@ -5,6 +5,9 @@ import Button from "./controls/Button.svelte";
 import ButtonLink from "./controls/ButtonLink.svelte";
 import Checkbox from "./controls/Checkbox.svelte";
 import CircleButton from "./controls/CircleButton.svelte";
+import GroupedToggle from "./controls/GroupedToggle.svelte";
+import GroupedToggleItem from "./controls/GroupedToggleItem.svelte";
+import GroupedRadioItem from "./controls/GroupedRadioItem.svelte";
 import Input from "./controls/Input.svelte";
 import MiniButton from "./controls/MiniButton.svelte";
 import RadioButton from "./controls/RadioButton.svelte";
@@ -51,6 +54,7 @@ import Text from "./typography/Text.svelte";
 export { Tag };
 export { Hero };
 export { TabItem };
+export { GroupedToggle, GroupedToggleItem, GroupedRadioItem };
 export { Button, ButtonLink, CircleButton, Checkbox, Input, Slider, Toggle, RadioButton, MiniButton, Select, Option, };
 export { Bar, ColumnContainer, Container, GridLayout, GridRow, Inline, MenuList, Page, ResponsiveText, RowContainer, Stack, TabBar, };
 export { TextLayout, Code, Accordion };

package/dist/layout/Accordion.svelte

@@ -124,6 +124,38 @@ function onAccordionClicked(e) {
    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/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.