/* ── Platform-targeted landing ───────────────────────────────────────────
   ios.sociallite.app and android.sociallite.app serve this same site, and
   this is the only thing that differs on them: the store badge for the OTHER
   platform is not shown.

   One stylesheet rather than a second and third copy of the site. The landing
   page alone is ~60KB of markup with two badge pairs in it; three forks of
   that would drift apart by the second edit, and every future change would
   have to be made three times.

   html[data-platform] is set by the inline snippet in each page's <head> —
   inline and before the stylesheet, so a badge is never painted and then
   removed. See the note there for how the platform is decided.

   Nothing here touches the footer's Download links. Those are navigation, not
   the call to action: someone on the iOS subdomain who goes looking for the
   Android build should still find it. */

html[data-platform="ios"] .store-badge.google-play,
html[data-platform="android"] .store-badge.app-store { display: none; }

/* The hero lays its badges out as a fixed two-column grid, so one child in a
   two-column track would sit in the left column with a hole beside it. With a
   single badge the grid becomes one column and shrinks to it, which keeps the
   badge under the headline where the two-badge version sits. */
html[data-platform] .hero .store-buttons {
  grid-template-columns: minmax(0, 1fr);
  width: min(100%, 215px);
}
@media (max-width: 700px) {
  html[data-platform] .hero .store-buttons { width: min(100%, 168px); }
}

/* ── The Play rating laurel ──────────────────────────────────────────────
   The App Store laurel is a supplied image. There is no Play equivalent, so
   this one is composed: the two laurel SVGs the onboarding already uses,
   masked to currentColor so they take the page ink in either appearance,
   around live text.

   The figures are the real ones off the public listing, read 2026-09-23:
   ratingValue 4.4889 (Google's own aria-label rounds it to "4.5 stars") and
   8.11K reviews, which squares with the star histogram summing to 7,977.
   If they drift, change them here and in the aria-label on the anchor.

   Five solid stars beside a 4.5 is the convention the App Store laurel
   already uses for its 4.8 — the number is the claim, the stars are
   decoration. Kept the same so the two laurels read alike. */
/* Both of these have to out-specify style.css, which sets display:block on
   .proof .rating-laurel.supplied-rating — three classes. A bare
   html[data-platform="android"] .supplied-rating is (0,2,1) and loses, which
   showed as BOTH laurels on the Android page. Matching the .proof
   .rating-laurel prefix takes it to (0,4,1). */
.proof .rating-laurel.play-rating{display:none}
html[data-platform="android"] .proof .rating-laurel.play-rating{display:block}
html[data-platform="android"] .proof .rating-laurel.supplied-rating{display:none}

/* .rating-laurel's base rule is a fixed 158x90 grid sized for the supplied
   image. This one is composed and sizes to its own content, so both are
   released — left as-is it sat in a 90px-tall box it did not fill and left a
   hole above the download button. */
.proof .rating-laurel.play-rating{width:auto;height:auto}

.play-rating>a{
  display:flex;align-items:center;justify-content:center;gap:0;
  position:relative;text-decoration:none;color:inherit}
/* Big enough to cradle the text, like the supplied wreath does. The SVG is
   48x64 with the branch sitting inside about the middle half, so it carries
   its own generous padding — hence gap:0 above, which still leaves a visible
   space between leaf and text. */
.play-leaf{
  display:block;flex:none;width:42px;height:56px;background:currentColor;
  -webkit-mask:center/contain no-repeat;mask:center/contain no-repeat}
.play-leaf.lead{-webkit-mask-image:url('/start/assets/laurel_leading.svg');
  mask-image:url('/start/assets/laurel_leading.svg')}
.play-leaf.trail{-webkit-mask-image:url('/start/assets/laurel_trailing.svg?v=2');
  mask-image:url('/start/assets/laurel_trailing.svg?v=2')}
.play-mid{display:flex;flex-direction:column;align-items:center;gap:2px;line-height:1.15}
.play-mid b{font-size:19px;font-weight:650;letter-spacing:-.02em}
.play-score{display:flex;align-items:center;gap:5px;font-size:14px;font-weight:600}
.play-stars{font-style:normal;letter-spacing:1px;font-size:12px}
.play-rating .rating-count{
  position:absolute;left:0;right:0;bottom:-16px;text-align:center;
  font-size:12px;line-height:1.3;color:#9a9a9a}

@media(max-width:700px){
  .play-leaf{width:36px;height:48px}
  .play-mid b{font-size:17px}
  .play-score{font-size:13px}
  /* Matches the App Store laurel, which hides its count on phones. */
  .play-rating .rating-count{display:none}
}

/* ── The product phone's home screen ─────────────────────────────────────
   The middle phone in the landing page's three-phone reveal shows the app's
   home screen, and the two platforms do not have the same one — iOS shows
   the per-app detail screen, Android shows the constellation hub. On the
   Android page it was showing a screen that build does not have.

   The middle phone therefore carries FOUR images: an iOS pair and an Android
   pair, each with a dark and a light variant. These rules pick the platform
   pair; the theme rules in mobile.css then pick dark or light within it, so
   the two concerns stay separate and neither needs to know about the other.

   Specificity, because this is the third time this file has been bitten by
   it: mobile.css has html[data-theme=light] .device .shot-light{display:block}
   at (0,3,1), and platform.css loads FIRST, so a rule that merely ties on
   specificity loses on source order and the wrong image shows on light theme.
   Matching .device.product-phone instead of .device takes these to (0,4,1).

   Only .shot-android is duplicated per platform, so these are scoped to the
   product phone — the side phones and every other .device are untouched.

   The hidden images are not downloaded: they are loading="lazy" and
   display:none, which Chrome never brings into view, so an iOS visitor does
   not pay for the Android capture. That is the same trick the existing
   dark/light pairs already rely on. */
html:not([data-platform="android"]) .device.product-phone .shot-android{display:none}
html[data-platform="android"] .device.product-phone .shot-ios{display:none}

/* iOS phones never had the opposite-badge rule - that's how the hero
   ended up showing three buttons. Each platform sees only its store. */
html[data-platform="ios"] .store-badge.google-play { display: none; }