contain-css-svelte 1.4.3 → 1.6.0

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/defaults.css

@@ -889,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);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "contain-css-svelte",
-  "version": "1.4.3",
+  "version": "1.6.0",
   "license": "MIT",
   "scripts": {
     "capture:review": "node scripts/capture-review.mjs",