.waitlist {
  max-width: 460px;
  margin: 0 auto;
  padding: 0 16px 48px;
}

.waitlist-hero {
  position: relative;
  /* Out past the column's 16px gutter and the site's 8px page frame, so the photo reaches the
     screen on both sides and at the top, which is where every phone mockup starts it.
     ?ver=b keeps it inside the frame instead. */
  margin: calc(-1 * var(--viewport-border)) calc(-16px - var(--viewport-border)) 24px;
}
.waitlist-hero--framed { margin: 0 -16px 24px; }
/* A soft light scrim at the top keeps the dark logo and close link legible over any photo. The
   mockups place them on sky or shadow; a seeded crop may not have that. */
.waitlist-hero::before {
  content: "";
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  height: 90px;
  background: linear-gradient(rgba(255, 255, 255, 0.75), rgba(255, 255, 255, 0));
  pointer-events: none;
}
.waitlist-hero__photo {
  display: block;
  width: 100%;
  /* 236 on a phone and 212 on a wider screen, which is what the mockups draw: all three phone
     screens stop the photo at 236 and both desktop screens at 212. */
  height: 236px;
  object-fit: cover;
}
/* A picture composed for phones is drawn at the shape it was uploaded, never cropped, because
   framing it is the reason it exists. The picture element is the photo's box. */
.waitlist-hero picture { display: block; }
@media (max-width: 767px) {
  .waitlist-hero--phone-photo .waitlist-hero__photo { height: auto; }
}
/* The logo links to the home page, as Arielle asked, so the link is what sits over the photo
   and the logo is simply inside it. Positioned on the image instead, the logo left the photo
   altogether once a link wrapped it. */
.waitlist-hero__home {
  position: absolute;
  top: 16px;
  left: 50%;
  transform: translateX(-50%);
  line-height: 0;
}
.waitlist-hero__logo {
  display: block;
  height: 30px;
  width: auto;
}
.waitlist-hero__close {
  position: absolute;
  top: 20px;
  right: 18px;
  color: #111;
  text-decoration: none;
  font-size: 14px;
}

.waitlist__heading {
  text-align: center;
  margin: 8px 0 12px;
}
.waitlist .waitlist__intro {
  text-align: center;
  max-width: 34ch;
  margin: 0 auto 28px;
}

/* The filled black call to action, shared by the quiz submit and the retake button. */
.waitlist__button {
  display: block;
  width: max-content;
  margin: 28px auto 0;
  background: #111;
  color: #fff;
  border: 1px solid #111;
  padding: 14px 44px;
  text-align: center;
  text-decoration: none;
}
/* The secondary, lower-emphasis action (for example "Back to home page"). */
.waitlist__button--secondary {
  background: #d9d2c7;
  color: #111;
  border-color: #d9d2c7;
}
/* base.html sets a:visited { color: inherit } inline, and that selector outranks a plain class,
   so a link button lost its own colour the moment it had been visited: black text on the black
   primary button, which only became readable on hover. Naming the link states here outranks it
   back. Buttons are not affected, only anchors, which is why this showed up on one screen at a
   time as each link was used. */
a.waitlist__button:link,
a.waitlist__button:visited {
  color: #fff;
}
a.waitlist__button--secondary:link,
a.waitlist__button--secondary:visited {
  color: #111;
}
/* The black primary button turns to black on white on hover, with a black edge so it does not
   vanish into a white page. base.css's own hover is black, which left it looking unchanged. A
   disabled button (busy while a step posts) keeps its look. The !important only outranks
   base.css's. Written after the :link and :visited colours above so it wins over them. */
a.waitlist__button:hover,
button.waitlist__button:not(:disabled):hover {
  background: #fff !important;
  color: #111;
  border-color: #111;
}
/* base.css turns every .btn black on hover, with !important, which suits the black primary
   button and left this one black on black, because it keeps its own #111 text. On hover it
   turns to black on white instead, with a black edge so it does not vanish into a white page.
   The !important is only there to outrank base.css's own. */
a.waitlist__button--secondary:hover,
button.waitlist__button--secondary:hover {
  background: #fff !important;
  color: #111;
  border-color: #111;
}
/* Two stacked buttons, centred and the same width, as the confirmation screens show. A grid as
   wide as its widest button, so the pair always match whatever their labels: a flex column
   centred each one at its own width, which is what Arielle saw as two sizes. */
.waitlist__buttons {
  display: grid;
  width: max-content;
  max-width: 100%;
  margin: 28px auto 0;
  gap: 12px;
}
/* No auto margins here: they centre a lone button, and in a grid they shrink each one back to
   its own label, which is the mismatch this is meant to end. */
.waitlist__buttons .waitlist__button {
  width: auto;
  margin: 0;
  min-width: 220px;
}

/* A button carries a top margin but no bottom one, which is right when it ends a screen and
   wrong when text follows: the support line on the opt-in completion page sat flush against it.
   Only pays the margin when something actually follows. */
.waitlist__button + .waitlist__intro,
.waitlist__buttons + .waitlist__intro {
  margin-top: 28px;
}

/* Shared form styles, used by the join and opt-in screens. */
.waitlist__section {
  text-align: left;
  margin: 32px 0 16px;
  font-weight: 400;
}
.waitlist-field {
  display: block;
  margin-bottom: 14px;
}
.waitlist-field input {
  display: block;
  width: 100%;
  box-sizing: border-box;
  border: 1px solid #111;
  padding: 16px;
  font-size: 16px;
  background: #fff;
}
/* The date of birth draws its own native control, which on an iPhone comes out a different
   height from the text fields and narrower than its column, with the date centred in it, as
   Arielle saw. Without the native appearance it is a box like the others, held to their 52px,
   and the date reads from the left as their text does. */
.waitlist-field input[type="date"] {
  -webkit-appearance: none;
  appearance: none;
  height: 52px;
  min-width: 100%;
  color: #111;
  text-align: left;
}
.waitlist-field input[type="date"]::-webkit-date-and-time-value { text-align: left; margin: 0; }
.waitlist-field input[type="date"]::-webkit-datetime-edit { padding: 0; }
.waitlist-field__help {
  font-size: 13px;
  color: #555;
  margin: -6px 0 20px;
}
.waitlist-field--checkbox,
.waitlist-field--radio {
  display: flex;
  align-items: flex-start;
  gap: 10px;
  margin: 14px 0;
  text-align: left;
}
.waitlist-field--checkbox input,
.waitlist-field--radio input {
  margin-top: 3px;
  flex: none;
}

/* The mobile mockup ends at the call to action with no footer; the footer is a desktop addition.
   The screens that end the flow keep it, centred as the home page's phone footer is, because
   their buttons are the only other way off the page. */
footer { display: none; }
body:has(.waitlist--footer) footer { display: block; text-align: center; padding-block: 0.5rem 2rem; }
.v2-footer-brand { margin-block-end: 1.25rem; text-align: center; }
.v2-footer-brand__mark { display: block; width: 133px; height: auto; margin-inline: auto; }
.v2-footer-brand__line { margin: 0.6rem 0 0; font-size: 1.0625rem; }
body:has(.waitlist--footer) footer nav { justify-content: center; }

/* The waitlist screens carry no top navigation, so the main does not need the nav's top inset, and
   the hero sits flush at the very top the way every waitlist mockup draws it. Full width, because
   the body centres main on its content and the hero is meant to run the whole way across. */
main { width: 100%; min-width: 0; padding-top: 0; }

/* Desktop (docs/v2/03-waitlist-flow.md, Questionnaire Page - Desktop). The focused column stays,
   but the hero runs full width across the top and the site footer returns below the screen. */
@media (min-width: 768px) {
  .waitlist { max-width: none; padding: 0; }
  /* The hero spans the whole width here rather than the phone's narrow column, and runs past
     the page's 8px frame to the edge of the window, which is how the mockup draws it: her photo
     spans 1 to 1362 of 1366. ?ver=b keeps it inside the frame instead, where the home page's
     film stops, so the two can be compared on the same screen. */
  .waitlist-hero { margin: calc(-1 * var(--viewport-border)) calc(-1 * var(--viewport-border)) 0; }
  .waitlist-hero--framed { margin: 0; }
  .waitlist-hero__photo { height: 212px; }
  .waitlist-hero__home { top: 22px; }
  .waitlist-hero__logo { height: 38px; }
  .waitlist-hero__close { top: 26px; right: 32px; font-size: 17px; }
  /* The copy and the bordered card of questions sit in a centred column the mockup draws at 685px;
     717 here leaves the card exactly 685 inside the column's 16px gutters. */
  .waitlist__body { max-width: 717px; margin: 0 auto; padding: 34px 16px 64px; }
  /* The design stands the heading clear of its intro: 38px between the two on a wide screen,
     where 12 left them reading as one block. */
  .waitlist__heading { margin-block-end: 29px; }
  /* The intro is the width of the card below it here, where the phone's 34ch holds it to a narrow
     column. The design sets it on two lines, which this width gives.

     How far it stands from what follows differs by screen, so that is set per screen: the
     questionnaire leaves 68px to its first question and the rejection 39 to its button. */
  .waitlist .waitlist__intro { max-width: 685px; margin-block-end: 38px; }
  /* The design's button is 36 tall on a wide screen, where 14px of padding above and below
     made ours 49. */
  .waitlist__button { padding-block: 7px; }

  /* The footer returns, matching the home page foot. The brand rules are repeated here because the
     home page's own stylesheet is not served on the waitlist screens. */
  footer,
  body:has(.waitlist--footer) footer { display: block; }
  footer:has(.v2-footer-brand),
  body:has(.waitlist--footer) footer { text-align: start; padding-block: 2rem; padding-inline: 75px 2rem; }
  .v2-footer-brand { margin-block-end: 1.25rem; text-align: start; }
  .v2-footer-brand__mark { display: block; width: 264px; height: auto; margin-inline: 0; }
  .v2-footer-brand__line { margin: 0.6rem 0 0; font-size: 1.0625rem; }
  footer:has(.v2-footer-brand) nav,
  body:has(.waitlist--footer) footer nav { justify-content: flex-start; }
}