/* AB#825 - keep the app off a dual-screen device's hinge.
 *
 * THE DEFECT, measured on the TEST slot at the Surface Duo's spanned geometry
 * (1114x720 CSS px, a ~34px hinge at the centre): the sign-in card spans
 * x=317 to x=797 while the hinge occupies x=540 to x=574, so the seam runs
 * straight through the middle of it. The logo, the welcome line and both
 * sign-in buttons are each cut in half by the physical gap between the two
 * screens. Every app page centres a capped container, so every app page does
 * this.
 *
 * THE RULE KEYS ON SEGMENTS, NEVER ON WIDTH. This matters more than it looks.
 * At 1114px on an ordinary tablet, centring the content is the CORRECT
 * behaviour - a width-keyed rule would shove every tablet's layout into the
 * left third of the screen to fix a device the user does not have. Only a
 * browser that reports two horizontal viewport segments has a seam to avoid.
 * Browsers without the feature never match this query, which is exactly right:
 * no hinge, no change.
 *
 * Measured both directions on the live TEST sign-in page at 1114x720:
 *   two segments (panel width stood in at 540px) - the card moves from
 *     317-797 to 30-510, clearing the seam by 30px, and a scan of every
 *     visible element finds nothing still crossing it. Page overflow 0px.
 *   one segment (this rule, on a single-segment machine) - the stylesheet
 *     parses and the card stays at 317-797, byte-identical to before the rule
 *     existed. Phones, tablets and desktop are untouched.
 *
 * WHY margin-left:0 AND NOT max-width ALONE. The first attempt set only
 * max-width. The body duly became 540px wide - and stayed centred, because
 * its auto margins resolved to 287px a side, so it still straddled the seam.
 * Narrowing a box does not move it. The box has to be pinned to a panel.
 *
 * WHY NO overflow-x HERE. The first draft carried overflow-x:clip. A body
 * overflow value propagates to the viewport when html's is visible, which
 * would have quietly changed scrolling on every page. Measured without it:
 * page overflow 0px and no horizontal scroll introduced, so it was never
 * doing any work.
 *
 * ANDROID APP: THIS RULE CANNOT FIRE THERE (AB#827). Android WebView does not
 * expose the Viewport Segments API, so the query never matches inside the
 * installed app even though this stylesheet is loaded in it. Measured on a
 * half-opened foldable: Chrome matches and reports a 421px segment; the app's
 * WebView does not match and reports 0px. The app therefore still centres
 * across the seam. Fixing that needs native WindowManager work, not CSS.
 *
 * SCOPE. This moves FLOW content, which is what a centred container holds on
 * all 20 app pages. It deliberately does NOT move position:fixed chrome -
 * that is anchored to the viewport rather than to the body, so a body
 * max-width cannot reach it (today.html has 25 fixed rules, search.html 11,
 * profile.html 10). Those are handled separately; a full-screen scrim is
 * meant to cover both panels and is left alone on purpose, while a control
 * surface such as the action bar or a bottom sheet is not.
 */

@media (horizontal-viewport-segments: 2) {
  body {
    /* TWO ways a browser can get this wrong, and they need different guards.
       env() falls back to 100vw where the browser knows the query but not the
       value, so a partial implementation degrades to today's behaviour rather
       than to a zero-width body. That fallback only fires on an ABSENT value.
       The 320px floor covers the other case: a browser that MATCHES the query
       while reporting the segment width as 0. Measured on Android WebView
       (AB#827), env(viewport-segment-width 0 0) returns exactly that - the
       string "0px", not nothing - so the fallback above would never fire and
       the body would collapse to zero width, blanking the app. max() makes
       320px the narrowest the body can ever be. No real dual-screen panel is
       under 320px, so on a device that reports honestly the segment width
       always wins and this floor never changes the layout. */
    max-width: max(320px, env(viewport-segment-width 0 0, 100vw));
    margin-left: 0;
    margin-right: auto;
  }
}

/* AB#827 - THE ANDROID APP PATH, because the query above cannot fire there.
 *
 * Android WebView does not expose the Viewport Segments API, so inside the
 * installed app the media query never matches and env(viewport-segment-width
 * 0 0) reports 0px. MainActivity therefore observes the fold natively with
 * Jetpack WindowManager and, when a separating VERTICAL fold shows two
 * side-by-side panels, sets --np-segment-width (the left panel's width in CSS
 * px, converted from WindowManager's DEVICE px by the display density) and a
 * data-np-fold="2" marker on <html>; it clears both when there is no such
 * fold, and re-applies on every page load because the OTA bundle swap reloads
 * the WebView and wipes anything injected before it.
 *
 * This rule mirrors the web rule exactly, including the 320px floor, but keys
 * on that marker instead of the segment query. It is inert wherever the marker
 * is absent, which is everywhere except a half-opened foldable running the
 * native build: the web, Chrome, phones, tablets and a fully unfolded foldable
 * are byte-identical to before.
 *
 * Measured on a Pixel Fold emulator forced to HALF_OPENED: the observer reads
 * bounds.left 1104 device px at density 2.625 and computes 420.57 CSS px,
 * against the 421px Chrome reports for the same panel - a sub-pixel match, so
 * the density conversion is right. With this rule the body occupies x=0..421,
 * entirely inside the left panel with its right edge at the hinge; before it,
 * 520px centred at margin-left 160.571px, straddling the seam.
 *
 * The var() keeps a 100vw fallback for the same reason the web rule does: a
 * page the native side has not reached yet must degrade to today's behaviour,
 * never to a zero-width body. */
html[data-np-fold="2"] body {
  max-width: max(320px, var(--np-segment-width, 100vw));
  margin-left: 0;
  margin-right: auto;
}