@aiquants/daily-report 0.51.0 → 0.51.1

package/CHANGELOG.md

@@ -4,6 +4,29 @@ All notable changes to `@aiquants/daily-report` are documented here.
 
 ## Unreleased
 
+### Fixed
+
+- **低い窓でもビューが 0 に潰れない (WCAG 1.4.10)**: 0.51.0 で操作列の帯がどのポインターでも 56px (折り返せば 112px)、検索の行の帯が 56〜112px になったため、
+  400 % の拡大 (320 × 256 CSS px、マウス) ではホストの見出し 148px と 2 つの帯 224px が列を使い切り、List と DetailList のビューの高さが 0 になって行に届かなかった。
+  ビューの根要素は最小の高さとして List の行の枠の高さ 1 つ分 P (`VIEW_MIN_BLOCK_SIZE_CLASS_NAME` = 4⌈(52px + 2rem + max(4.75rem, 44px)) / 4⌉。根 16px で 160。
+  `round()` を持たない描画エンジンは切り上げる前の和) を持ち、ページの箱からビューの根要素までの箱 (ページの枠・内容の列・ビューのタブ・タブの中身。
+  `PAGE_FILL_COLUMN_CLASS_NAME`) は中身の最小 (帯とビューの最小の高さ) より小さくならない。帯とビューの最小の高さが収まらない窓では、ページの箱がホストの列から
+  はみ出し、ホストの列 (かその祖先) の縦のスクロールがページ (見出し・帯・ビュー) を動かす。ホストはその列を `overflow-y: auto` にする (はみ出しを切る列ではビューが
+  隠れる。README の「Host scroll for short windows」)。ふつうの高さの窓では何も変わらない (ビューは列の残りを埋め、ページはスクロールしない)。
+- **側面ペインの記事のスクロールの箱が潰れない (WCAG 1.4.10)**: 同じ 400 % の拡大で List のカードから開くモバイルのオーバーレイ (ダイアログ 256px) では、ペインの帯
+  (見出しの列とタブの並び) の下で記事のスクロールの箱が 12px まで潰れ、スクロールで見せたスターと既読のボタン (44px) の中心が箱の外に落ちて押せなかった。
+  記事と相関のタブの中身は最小の高さとして的の行 1 行 (`SIDE_PANE_SCROLL_PANEL_MIN_BLOCK_SIZE_CLASS_NAME` = `--spacing(2)` + T + 4px。根 16px で 56px) を持ち、
+  帯 (`SIDE_PANE_HEADER_BOX_CLASS_NAME`) は縮まず、タブの根は中身に基づく最小の高さを保つ。ペインが帯と的の行 1 行を入れきれない高さでは、見出しの列とタブの根を
+  包む中身の箱 (`SIDE_PANE_CONTENT_BOX_CLASS_NAME`) が縦にスクロールする (見出し・タブ・記事が一緒に動く。デスクトップでは細いバーにビューのスクロールバーの組の色、
+  オーバーレイでは面の縦のスクロール領域 `SWIPE_OVERLAY_SCROLL_AREA_STYLE` で、閉じるボタンは箱の下に残る)。ふつうの高さでは何も変わらない (スクロールの範囲が
+  無い)。オーバーレイの中身の箱はスクロール領域なので、見出しとタブの並びで始まった縦の 1 本指の動きも記事の上と同じくブラウザーのスクロールへ渡る (横の動きは
+  今まで通りスワイプ)。
+- **オーバーレイの知らせの置き場が空のとき場所を取らない**: 置き場には知らせの提供者の警告の領域 (見えない `role="alert"`) が常に入るので `:empty` で隠れず、
+  高さ 0 の項目として列の間隔 16px を 2 つ並べていた (320 × 256 では日報の箱から 16px を奪った)。置き場は見える知らせを持つ間だけ flex の箱になり、それ以外は
+  箱を作らない (`display: contents`。警告の領域は読み上げの木に残る)。どの高さでもオーバーレイの日報の箱が 16px 高くなる (閉じるボタンの位置は変わらない)。
+
+## 0.51.0 (2026-10-25)
+
 ### Breaking
 
 - **的の大きさと配置がどのポインターでも同じ (マウス・トラックパッド・ペンでも 44 × 44 CSS px。WCAG 2.5.5)**: 0.50.0 で粗いポインター

package/README.md

@@ -2786,9 +2786,16 @@ view, and no script computes or writes a height.
   (`display: flex; flex-direction: column`) whose height is bounded — a definite height, or the growing item of a column with a minimum height, such
   as a `min-height: 100dvh` shell whose footer follows the content. The header that `renderHeader` returns and the page box are items of that
   container, and the page box takes the rest of it. Nothing is bound and no host variable is read.
-  Outside such a container the view has no height to fill: its size is contained (below), so its content cannot size it, and it is 0 px tall.
+  Outside such a container the view has only its minimum (below): its size is contained, so its content cannot size it.
+- **Host scroll for short windows**: a view never gets shorter than one List row slot P (**The view's minimum** below). When the container is shorter
+  than the toolbar band plus that minimum (a 400 % zoom, a short window), the page box grows past the container instead of the view collapsing, so the
+  container or one of its ancestors must scroll in the block axis (`overflow-y: auto`, not `hidden` or `clip`): the page scrolls (the host's header,
+  the bands and the view) and every row stays reachable (WCAG 1.4.10). A container that clips its overflow hides the view. At ordinary window sizes the
+  minimum is below the space left, the page box just fills the container and nothing scrolls.
 - **The fill chain**: every box from the page box down to a view's root — the page box, its centred width-capped wrapper, the view-mode tabs and the
-  active tab panel — fills the rest of its parent column (`flex: 1 1 0%; min-height: 0`) and declares no height. The wrapper's padding is the block
+  active tab panel — fills the rest of its parent column (`flex: 1 1 0%`), never gets smaller than its content's minimum (`min-height: auto`: the band
+  and the view's minimum) and declares no height. The view's root fills the tab panel at `flex: 1 1 0%` with the view's minimum as its
+  `min-height`. The wrapper's padding is the block
   quantum q of the device-pixel lattice at the top and the sides (4 px, 8 px at the odd multiples of 1/8; **Row slots on the lattice**) and none at
   the bottom, so the view's box ends exactly at the page's bottom edge.
   Between the wrapper's top and the active tab panel sits the band of the view-mode toolbar (the search row too, when configured), which does not
@@ -2797,9 +2804,28 @@ view, and no script computes or writes a height.
   box (the fill rule and the page surface, slate-50 / dark slate-950) and its centred column (the fill rule, at most `max-w-6xl`, q from the frame's
   top and side edges, starting on the lattice; the column carries q itself). So the page keeps its colour in both schemes while loading ends (a dark
   page never shows the light surface first) and the content does not move sideways between the screens.
+- **The view's minimum**: one List row slot P = 4 · ⌈(52 px + 2 rem + max(4.75 rem, 44 px)) / 4⌉ (**List slot P**; 160 px at a 16 px root), the
+  smallest whole row the views draw, as the root's `min-height` in the slot's own expression (an engine without `round()` takes the unrounded sum,
+  less than 4 px below P). A view of that height shows at least one whole List card; a DetailList row, taller than P, scrolls inside the view.
+- **The side pane's minimum and its own scroll**: the side pane (the desktop frame beside the List and the mobile overlay's pane box) stacks two
+  bands, the header column (business date and author) and the tab list, above its tab panel, a scroll box. The bands never shrink, and the tab panel
+  never gets shorter than one whole target row inside its own block padding: `--spacing(2)` (its top padding) + T (44 px) + 4 px (the focus-ring
+  reach at its bottom), 56 px (14 lattice units) at a 16 px root, so a 44 px control scrolled into view lies inside the box with its focus ring
+  (4 + 44 + 4 = 52 within the scroll padding). The tabs root keeps its content's minimum (the tab list plus that row). When the pane cannot hold the
+  bands plus that row (a 400 % zoom, a short window), the pane's content box (around the header column and the tabs, its clipping edges 4 px
+  outside its content) overflows and scrolls in the block axis, so the header, the tabs and the article move together. On the desktop its thin bar
+  wears the views' scroll-bar colours; in the overlay it is a vertical scroll area of the swipe overlay's panel (`touch-action: pan-y pinch-zoom`
+  and `overscroll-behavior-y: contain`) and the close button stays below it. It never scrolls sideways, so a horizontal move on the overlay's pane
+  is still the swipe.
+  At ordinary heights the content fits, there is no scroll range and nothing moves. The pane scrolls inside the view's box, so the host needs
+  nothing for it.
+- **The overlay's notice slot takes room only for the notice**: the slot of the error notice in the overlay, between the pane box and the close
+  button, always holds the provider's alert region (a visually hidden `role="alert"` element), so it is never empty. It generates no box
+  (`display: contents`) unless it holds the visible notice, so the column keeps one 16 px gap between the pane box and the close button; the alert
+  region, absolutely positioned, stays in the accessibility tree.
 - **The view's root contains its size** (the fill rule, `contain: size` and `overflow: clip`, its children in block flow): its box is sized as if it
   were empty, so what the view renders — a `VirtualScroll` given the measured height — never feeds back into the root's size, into the intrinsic size
-  of an ancestor (a host column with a minimum height does not grow) or into the document's scroll height. The clip keeps rows drawn for the previous
+  of an ancestor (a host column with a minimum height does not grow) or into the document's scroll height; only the view's minimum does. The clip keeps rows drawn for the previous
   height from painting outside the box during the one frame before the view renders the new height.
   The root's layout and paint are not contained: either would make the root the containing block of the mobile overlay, a fixed-position descendant,
   and as a flex item of its column the root could not be a relayout boundary anyway (Chromium makes no flex or grid item one, contained or not).