/* 40-sequences.css — see 00-contract.css for the rules this file obeys.
   Every rule below is inside a max-width or pointer:coarse media query.

   The sequence viewer (sequences/detail.html + sequences.css + a matching
   pass over sequences.js) is a Benchling-style base-by-base editor: a
   hero header, the viewer itself (ruler + bases + annotation bars +
   translation rows, all sharing one 1ch-per-base grid), and a right-hand
   slide-over (.panel--seq) with five tabs. Jeremy's ask named it twice —
   "borders have to go to use the already narrow full width" and "menubars
   with too many items have to render using submenus" — and this file is
   the width/padding/tap half of answering that. The other half, letting
   the viewer actually fit a different number of bases per line at a
   narrow width, needed no new mechanism: sequences.js's
   computeLineLength() already measures the real rendered base width and
   re-fits on every render and on window "resize" (which every engine this
   app targets already fires on a phone's orientation change, though an
   "orientationchange" listener was added alongside it anyway — see that
   file). What was missing is just given back here: the padding this file
   removes was, at 375px, most of what computeLineLength() had to work
   with. A later presentation pass dropped the viewer's own left gutter
   entirely (sequences.js/sequences.css), which only made this section's
   job easier — one less surface competing for the same narrow width. */

@media (max-width: 900px) {
  /* -- A. reclaim the horizontal space --------------------------------
     .sheet--seq already runs full width (padding: 0, sequences.css) —
     what was still spending most of a 375px screen on border and padding
     was every *surface inside* that: the hero and the body gutter. One
     number (--gutter-compact, 00-contract.css) replaces both, so the left
     edge lines up the same way every other mobile surface in the app
     does, and — the actual point of this section — the viewer gets back
     the ~70px of desktop padding (.seq-body's own, sequences.css) that
     computeLineLength() would otherwise have divided among however many
     fewer bases fit on a line. (.seq-panel itself carries no padding to
     compact any more — the presentation pass that removed the viewer's
     card chrome took it down to a bare flex wrapper at every width, this
     one included.) */
  .seq-hero { padding: var(--gutter-compact) var(--gutter-compact) 0.9rem; }
  .seq-body { padding: 0.9rem var(--gutter-compact) 1.6rem; }
  .seq-viewer { padding: 0.8rem 0.6rem 0.9rem; }

  /* The hero's title/meta column and its button row already wrap
     (.seq-hero__row: flex-wrap: wrap, sequences.css) — the row of icon
     buttons just never had permission to wrap *itself* onto more than one
     line, which mattered once Save (a text button, not an icon) is in the
     mix beside Archive/Duplicate/the panel toggle on a 375px row. */
  .seq-hero .btn-row { flex-wrap: wrap; row-gap: 0.5rem; }

  /* -- C. the panel's own tab strip, five items wide ------------------
     .seq-tabs__btn is `flex: 1` on desktop — five equal-width tabs
     dividing .panel--seq's own width. That width is `min(640px, 95vw)`
     (sequences.css), so on a 375px phone the panel itself is ~356px, and
     five flexed labels ("ANNOTATIONS" is 11 uppercase, letter-spaced
     characters) have nowhere to go but wrap into a second line, at which
     point every tab is a different height depending on how its own label
     happened to break — "menubars with too many items have to render
     using submenus" is exactly this. A horizontally-scrolling strip of
     fixed-width, single-line labels reads better on a touch device than
     either wrapping or truncating: nothing to misread, and "there's more,
     swipe" is a gesture a phone user already has. Same treatment for the
     Tools tab-panel's own nested digest/primers/translate/align strip —
     four items is less dire, but the panel is the same ~356px there too. */
  .seq-tabs__nav,
  .seq-tabs__nav--top {
    overflow-x: auto;
    -webkit-overflow-scrolling: touch;
  }
  .seq-tabs__btn {
    flex: none;
    white-space: nowrap;
  }

  /* The selection bar's own copy/copy-revcomp/save-primer/annotate/clear
     row can hold five icon buttons at desktop width without wrapping;
     give it the same permission the hero row just got rather than let it
     force the (position: fixed, viewport-clamped) bar wider than its own
     max-width allows. */
  .seq-selection-bar .btn-row { flex-wrap: wrap; }
}

@media (max-width: 600px) {
  /* -- A, continued: edge to edge on a phone --------------------------
     "consider dropping the .seq-panel border/radius entirely so the
     tracks run edge to edge" — at 600px and below, every remaining pixel
     the viewer's own frame spends on itself is a pixel not spent on a
     base. .seq-body still keeps a sliver of --gutter-compact (now 0.7rem,
     00-contract.css) so the ruler/legend text doesn't start flush against
     the device bezel, but .seq-viewer's own frame — the only bordered box
     left here since .seq-panel stopped drawing one — now runs to the
     gutter's edge instead of floating inside it like a card. */
  .seq-viewer {
    padding-inline: 0.4rem;
    border-left: 0;
    border-right: 0;
    border-radius: 0;
  }
}

@media (pointer: coarse) {
  /* -- D. touch -------------------------------------------------------
     Hit-area only, never layout (00-contract.css) — an iPad in landscape
     matches this query too but keeps the full desktop grid, so nothing
     here may resize a column or restyle anything's visible dimensions,
     only grow what a finger has to land on. Scoped to this page's own
     controls (every other page's tap-target story lives in whichever
     file owns it — see mobile/10-shell.css's own note on why its
     `.topbar .icon-btn` rule doesn't reach here). The legend's own
     <summary> joined this list once it became a real, always-tappable
     control at every width rather than something only a mobile-only
     rule ever revealed (sequences.css) — the same reasoning as every
     other row here, just arriving with that change instead of this
     file's original pass. #seq-search-toggle and #seq-search-bar's own
     icon buttons (prev/next/annotate/close match, search) joined for the
     same reason the selection bar's did: new controls in the main track,
     not the hero/tabs/selection-bar rules already here. */
  .seq-tabs__btn,
  .seq-circular-toggle,
  .seq-hero .icon-btn,
  .seq-hero .btn,
  .seq-legend-details > summary,
  #seq-selection-bar .icon-btn,
  .seq-tab-actions .icon-btn,
  #seq-search-toggle,
  #seq-search-bar .icon-btn {
    min-height: var(--tap);
  }
  .seq-circular-toggle,
  .seq-hero .icon-btn,
  #seq-selection-bar .icon-btn,
  .seq-tab-actions .icon-btn,
  #seq-search-toggle,
  #seq-search-bar .icon-btn {
    min-width: var(--tap);
  }

  /* The map's own drag handles (sequences.css: `.seq-map-feature:hover
     .seq-map-handle { opacity: 1; }`) are only ever revealed by :hover —
     which a touch screen cannot trigger, so an owner resizing a feature
     on an iPad had no visual cue the handle was even there to grab (it
     was still functionally reachable — opacity doesn't disable a
     pointerdown target — just invisible). Showing them unconditionally
     under pointer:coarse costs nothing on a mouse (this query never
     matches one) and nothing in a dense map's legibility budget on a
     touch device either: a molecule map only has a handful of features
     on screen at once, unlike the base track's per-letter density. */
  .seq-map-feature .seq-map-handle { opacity: 1; }

  /* Drag-to-select across bases (sequences.js's pointerdown/pointermove
     handlers on #seq-viewer) fights the browser's own touch-scroll
     gesture unless told not to: the first touchmove of *any* drag
     otherwise gets claimed for panning before that JS's
     preventDefault() runs, which is what "check whether drag-to-select
     fights the browser's native touch scrolling" (mobile brief, item D)
     was about. `touch-action: none` here is the same lever
     sequences.css already pulls, unconditionally, for the map's own drag
     (`.seq-map { touch-action: none }`) — gated to pointer:coarse here
     only because a mouse never needed it in the first place, not because
     it would do anything different on one. The trade this makes: a touch
     drag that starts on a base now always means "select", never "scroll
     the page" — the same trade Benchling's own base track makes, and the
     only way a multi-line selection drag (which has to be free to move
     vertically between wrapped lines without the browser reinterpreting
     that as a page scroll) can work at all on a touch screen. Scrolling
     the page past the viewer is still one touch away, just not from a
     touch that starts on a base — exactly as it already couldn't start a
     text selection from inside the viewer on a mouse without dragging
     instead of scrolling by wheel. */
  .seq-row__bases,
  .seq-anno-bar,
  .seq-anno-intron,
  .seq-anno-cut,
  .seq-cut-line,
  .seq-cut-path {
    touch-action: none;
  }
}