contain-css-svelte 1.4.2 → 1.5.0

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.

package/dist/sass/_responsive.scss

@@ -13,6 +13,49 @@
 $sidebar-compact-max: 512px;
 $sidebar-wide-min: 513px;
 
+/* 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.) */
+$small-max: 600px;
+
+/* 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. */
+@mixin when-small {
+  @media (max-width: #{$small-max}) {
+    @content;
+  }
+  @container (max-width: #{$small-max}) {
+    @content;
+  }
+}
+
 
 /* Warning: because we define a fallback
   media query, the media query can override the container

package/dist/typography/TextLayout.svelte

@@ -78,6 +78,38 @@ const el = $derived(elementProps(restProps, "text-layout", ["marginBlock", "marg
    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.
@@ -305,6 +337,10 @@ div {
   --_prose-margin-inline: var(--body-prose-margin-inline, var(--text-prose-margin-inline, var(--prose-margin-inline, auto)));
   --_heading-margin-inline: var(--body-heading-margin-inline, var(--text-heading-margin-inline, var(--heading-margin-inline, auto)));
   width: var(--text-width, var(--body-width, 100%));
+  /* width is 100% by default and padding-inline is added on top -- without
+     border-box a TextLayout is always 2 * padding wider than its parent,
+     which on a phone means a sideways scroll before anything else loads. */
+  box-sizing: border-box;
   /* Not margin-props() (_box.scss): that defaults both axes to 0, but a
      TextLayout has always centred itself horizontally by default. Same
      var-with-fallbacks() shape as everywhere else, just inline defaults to
@@ -357,6 +393,17 @@ div :global(code) {
   text-wrap: nowrap;
 }
 
+/* Inline code (a CSS variable name, a prop signature) reads best unbroken,
+   so it stays on one line -- until the column it sits in is too narrow for
+   that to be a choice. There a long token like --grid-layout-justify-content
+   is wider than the whole line, and refusing to break it pushes the layout
+   sideways; let it wrap, and mid-token if it has to. */
+@container (max-width: 30rem) {
+  div :global(:not(pre) > code) {
+    text-wrap: wrap;
+    overflow-wrap: anywhere;
+  }
+}
 /* Everywhere else, heading styling is consumed once, globally, by the
    :where()-scoped rule in vars/typography-context.css -- zero specificity, so
    any real selector easily overrides it. TextLayout is the one exception:

package/dist/vars/colors.css

@@ -12,9 +12,17 @@
   --inactive-bg: var(--material-color-grey-400);
   --inactive-fg: var(--material-color-grey-900);
 
-  /* Fallback colors - themes can override these */
-  --bg: #fcfcff;
-  --fg: #1b1d2e;
+  /* Fallback colors - themes can override these.
+
+     Neutral on purpose: this file is the base every theme (and every app
+     with no theme at all) inherits before anything else runs, so a tint
+     here reaches apps that never asked for it. A theme that wants a
+     particular cast -- indigo, warm, whatever -- sets --bg/--fg itself
+     (see themes/light.css); --border-color below already derives from
+     whatever --bg/--fg a theme (or an app) actually provides, so a themed
+     app gets a themed border for free without this file picking a hue. */
+  --bg: var(--material-color-grey-50);
+  --fg: var(--material-color-grey-900);
 
   --stripe-fg: var(--menu-fg, var(--fg));
   --stripe-bg: color-mix(
@@ -53,7 +61,12 @@
      affordances.css. The color-props(menu-item, menu, button, control) chain
      resolves it to --menu-bg / --bg at the element, keeping per-instance
      --menu-bg overrides working. */
-  --focus-color: var(--material-color-indigo-a200);
+  /* --focus-color intentionally not defaulted here either: both consumers
+     (_affordances.scss's outline rule, Tag's close-button outline) already
+     fall back to the browser's own focus ring / currentColor when it's
+     unset, which is exactly the neutral behavior an un-themed app should
+     get. A theme that wants a specific ring sets --focus-color itself
+     (see themes/light.css, themes/material.css, themes/purple.css). */
   --tooltip-border: none;
 }
 
@@ -64,7 +77,10 @@ body {
 
 a {
   background-color: var(--link-bg, transparent);
-  color: var(--link-fg, var(--material-color-indigo-700));
+  /* Same reasoning as --surface-link-fg above: derive from the theme's own
+     --primary-bg (always defined, even for an app with no theme at all)
+     rather than hard-coding a hue here too. */
+  color: var(--link-fg, var(--primary-bg));
 }
 
 /* Color definitions */

package/dist/vars/defaults.css

@@ -306,9 +306,17 @@
   --inactive-bg: var(--material-color-grey-400);
   --inactive-fg: var(--material-color-grey-900);
 
-  /* Fallback colors - themes can override these */
-  --bg: #fcfcff;
-  --fg: #1b1d2e;
+  /* Fallback colors - themes can override these.
+
+     Neutral on purpose: this file is the base every theme (and every app
+     with no theme at all) inherits before anything else runs, so a tint
+     here reaches apps that never asked for it. A theme that wants a
+     particular cast -- indigo, warm, whatever -- sets --bg/--fg itself
+     (see themes/light.css); --border-color below already derives from
+     whatever --bg/--fg a theme (or an app) actually provides, so a themed
+     app gets a themed border for free without this file picking a hue. */
+  --bg: var(--material-color-grey-50);
+  --fg: var(--material-color-grey-900);
 
   --stripe-fg: var(--menu-fg, var(--fg));
   --stripe-bg: color-mix(
@@ -347,7 +355,12 @@
      affordances.css. The color-props(menu-item, menu, button, control) chain
      resolves it to --menu-bg / --bg at the element, keeping per-instance
      --menu-bg overrides working. */
-  --focus-color: var(--material-color-indigo-a200);
+  /* --focus-color intentionally not defaulted here either: both consumers
+     (_affordances.scss's outline rule, Tag's close-button outline) already
+     fall back to the browser's own focus ring / currentColor when it's
+     unset, which is exactly the neutral behavior an un-themed app should
+     get. A theme that wants a specific ring sets --focus-color itself
+     (see themes/light.css, themes/material.css, themes/purple.css). */
   --tooltip-border: none;
 }
 body {
@@ -356,7 +369,10 @@ body {
 }
 a {
   background-color: var(--link-bg, transparent);
-  color: var(--link-fg, var(--material-color-indigo-700));
+  /* Same reasoning as --surface-link-fg above: derive from the theme's own
+     --primary-bg (always defined, even for an app with no theme at all)
+     rather than hard-coding a hue here too. */
+  color: var(--link-fg, var(--primary-bg));
 }
 /* Color definitions */
 :root {
@@ -873,7 +889,10 @@ body {
   --icon-size: 32px;
   /* Cards */
   --card-width: 420px;
-  --card-width-small: 250px;
+  /* In the small tier a Card fills the space it's given (Card's max-width
+     still keeps it inside its margins). Was 250px: a narrow card adrift in a
+     390px phone, small enough to trip Card's own narrow-card styles. */
+  --card-width-small: 100%;
   --card-width-large: 600px;
   --card-height: 300px;
   --card-height-small: 150px;

package/dist/vars/layout.css

@@ -47,7 +47,10 @@ body {
   --icon-size: 32px;
   /* Cards */
   --card-width: 420px;
-  --card-width-small: 250px;
+  /* In the small tier a Card fills the space it's given (Card's max-width
+     still keeps it inside its margins). Was 250px: a narrow card adrift in a
+     390px phone, small enough to trip Card's own narrow-card styles. */
+  --card-width-small: 100%;
   --card-width-large: 600px;
   --card-height: 300px;
   --card-height-small: 150px;

package/dist/vars/responsive-typography.css

@@ -1,6 +1,9 @@
+/* 16px is the floor, not 14: phones are where small text hurts most, and
+   iOS Safari zooms the page whenever an input under 16px takes focus. The
+   scale grows from there on bigger screens. */
 @media screen and (max-width: 800px) {
   :root {
-    --font-size: 14px;
+    --font-size: 16px;
     --text-size: var(--font-size);
     --ui-size: var(--font-size);
     font-size: var(--font-size);