/* ============ styles.tilaa.css — tilaa.html only ============
   Overrides for the booking form. Loaded after styles.css so these rules win on
   equal specificity; nothing here is a copy of a rule from that file, and no
   rule was moved out of it.

   Everything below came out of a measured walk of the real flow in Chromium at
   390x844, 820x1180 and 1440x900. What that walk found was NOT a layout
   problem: document.documentElement.scrollWidth equalled window.innerWidth at
   every width and every step, no in-flow element crossed the right edge, and
   nothing was clipped. The single defect was tap size — controls standing under
   the 44px floor, all of them in height.

   So this file only grows the box each control offers a thumb. No colour, no
   wording, no field, and nothing the booking request sends is touched.

   SHORTER THAN IT WAS: ordering moved to ruokalista.html, and the rules for the
   dish list, the basket, the category pills and the loading stand-ins went with
   it — see styles.order.css. What is left is the booking form's.
   ============================================================ */

/* ---- The printed menu's frame, around the booking form ----
   The booking form already drew its own white box with a brass border. Inside
   the frame that is the same border twice, 28px apart, so the inner one goes
   and the frame's padding is what the form sits in. */
#tilaa .menu-book .kl-form{background:none;border:0;padding:0}

/* 900px is where the tap floor comes in. This was written as "the breakpoint
   styles.css already uses", which is wrong and was worth measuring: that file's
   phone and tablet block opens at max-width:1010px. So 901-1010 takes the
   single-column layout without the 44px floor. Left as it is rather than
   widened blind — a mouse is the likely pointer at 1000px — but the two numbers
   are not the same number, and the next person should not assume they are. */
@media(max-width:900px){

  /* Measured before: #kl-slots 40px tall. The width was already over 44, so
     only the height floor is set; the pill radius and padding stay as they
     are. */
  #kl-slots button{
    min-height:44px;
    display:inline-flex;
    align-items:center;
    justify-content:center;
  }

  /* The one control on this page that is drawn by the phone, not by us.
     iOS Safari gives input[type=date] an intrinsic width from its own date
     format and will not shrink it to the 100% every other field takes, so the
     field stood outside the frame's right rule while name, phone and email sat
     inside it. It also centres the value; the rest of the form is flush left.
     appearance:none is what lets the width and the alignment be ours — the
     native picker still opens on tap, it is only the box that stops being the
     phone's. Chromium never showed this: it honours the 100%, which is why a
     desktop walk of this page found nothing. */
  .kl-field input[type="date"]{
    -webkit-appearance:none;
    appearance:none;
    min-width:0;
    max-width:100%;
  }
  .kl-field input[type="date"]::-webkit-date-and-time-value{
    text-align:left;
    margin:0;
  }
}

/* Measured at 393x852 against the production form: the 23 slots the API returns
   settle at 304px tall. If the opening hours change how many slots there are,
   re-measure it. */
@media(max-width:480px){

  /* The slots were a wrapping flex row and came out four to a line by
     coincidence of width, not by rule; the last line of a 23-slot day sat
     ragged against a tidy grid above it. Four equal columns is what it was
     already doing, said once. The message state ("valitse päivä") is a single
     line of text and must not be squeezed into a quarter of the row. */
  #kl-slots{display:grid;grid-template-columns:repeat(4,1fr);gap:8px}
  #kl-slots button{width:100%;padding:9px 4px}
  #kl-slots.kl-slots-msg{display:block}
  .kl-slots{min-height:304px}
}