logan
57fbbdf0d2
Plan 016 B2, phase 1. Below 600px the grid drops its sidebar column, `bottom-nav` becomes the primary navigation, and the shell fits the viewport instead of scrolling sideways out of it. 600 rather than the sidebar's own 900, because 900 is a laptop and the answer there is a narrower sidebar, which is still a sidebar. Under 600 there is no room for one at all: 360px of viewport over a 200px nav is not a layout. **The tab bar is four destinations and a way to everything else.** Three to five is where touch targets stop being thumb-sized -- eleven over 360px is 32px each -- so the four are the ones plan 016's subset says a phone is for, and "More" opens the *existing* `app-sidebar` in a drawer rather than listing the destinations a second time. Two lists is two places to add the next view to. That reuse has a cost this found the hard way: a shared component brings its `data-testid`s with it, so rendering the drawer's sidebar unconditionally put a second `nav-home` (and ten siblings) in the DOM and **failed 30 existing specs** with "resolved to 2 elements" -- on a desktop viewport, where this element is `display: none` and the drawer can never open. It renders only while the drawer is open, and the component test asserts the absence, because the failure is invisible from inside the component and lands in files nobody touched. **What made the shell overflow was minimums, not padding.** Measured at 360px: the body was 652px wide, because a `min-width` in a flex row is a hard floor and a grid item's implicit minimum is its content. So `min-width: 0` on the boxes between the viewport and the content, and each component stands its own non-essential parts down in its *own* stylesheet -- search-bar's 200px floor, job-indicator's label (the visible one; the live region that announces it is untouched), audio-player's seek bar and volume. A media query inside a shadow root is answered by the viewport, so this is the component saying what it drops rather than the shell reaching in. Volume goes because the hardware keys own it on a phone, which is the same reason mediacontrols' Android handler implements no volume callback. Seeking goes because 4px is not a thumb target; it belongs to the full-screen now-playing view, which is the next phase. An existing spec therefore asserts the opposite of what it did: layout-overflow's 320px case used to require that the 464px behind `overflow: hidden` could be *scrolled to*, which was the remedy available while the shell had one layout. It reflows now -- 320px in a 320px viewport, exactly -- and reflow is what WCAG 1.4.10 asked for.
57 lines
2.1 KiB
HTML
57 lines
2.1 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
|
|
<head>
|
|
<meta charset="UTF-8" />
|
|
<meta content="width=device-width, initial-scale=1.0" name="viewport" />
|
|
<link href="./index.css" rel="stylesheet" />
|
|
<title>yellowjacket</title>
|
|
<script src="/index.ts" type="module"></script>
|
|
</head>
|
|
|
|
<body>
|
|
<!-- a11y.30. First focusable thing in the document, so a keyboard
|
|
user is not walked through the header, the library filter, the
|
|
search box and eleven nav items on every navigation. -->
|
|
<a class="skip-link" href="#main-content">Skip to content</a>
|
|
<header class="top-bar">
|
|
<hgroup>
|
|
<h1 class="title">YellowJacket</h1>
|
|
<!-- a11y.29: a heading level was being used for type size. -->
|
|
<p class="subtitle">Music how it was meant to bee.</p>
|
|
</hgroup>
|
|
<library-filter></library-filter>
|
|
<search-bar></search-bar>
|
|
<job-indicator></job-indicator>
|
|
</header>
|
|
<div class="sidebar">
|
|
<app-sidebar></app-sidebar>
|
|
</div>
|
|
<div class="content-area">
|
|
<main class="main-panel" data-active-view="tracks" data-testid="main-content" id="main-content"
|
|
tabindex="-1">
|
|
<track-list></track-list>
|
|
</main>
|
|
<queue-panel id="queue-panel"></queue-panel>
|
|
</div>
|
|
<footer class="bottom-bar">
|
|
<now-playing></now-playing>
|
|
<audio-player></audio-player>
|
|
<button aria-label="Toggle queue" id="queue-button">
|
|
<wa-icon name="list"></wa-icon>
|
|
</button>
|
|
</footer>
|
|
<!-- The phone's primary navigation, hidden above 600px by
|
|
index.css. Eager rather than a chunk, for the reason
|
|
notification-host is: it is the only way to move around the
|
|
app on a phone. After the footer, because that is where it
|
|
renders -- the tab bar sits below the transport, and DOM order
|
|
is what a screen reader and the tab sequence follow. -->
|
|
<bottom-nav></bottom-nav>
|
|
<first-run-wizard></first-run-wizard>
|
|
<notification-host></notification-host>
|
|
<shortcuts-overlay></shortcuts-overlay>
|
|
</body>
|
|
|
|
</html>
|