/* ===========================================================================
   LaaoDo on a desktop screen.

   Everything in this file sits inside one media query. Below 1024px nothing
   here applies at all, so phones, tablets in portrait and the Android app are
   byte-for-byte what they were.

   The rule followed throughout, taken from the homepage: a list stays one
   column that scrolls. Cards get wider and lay their contents along that width.
   Nothing is tiled into a grid of small boxes, because scanning one column is
   easier than scanning three, and because a wide row can show more per item
   rather than less.

   Pages are told apart by data-page on <body>. Each page sets its own width,
   because a form and a list want very different ones: a 1200px text input is
   worse than a 600px one, while a 1200px order list is better.
   =========================================================================== */

@media (min-width: 1024px) {

  /* ---- Nothing paints outside its column ------------------------------
     .btn is width:100%. Put one in a flex row with flex:none and it keeps that
     full width and spills past the edge, which is how a Cancel button ended up
     over the order list. These are the two safety nets: a control can never be
     wider than what holds it, and a grid or flex child can always shrink.

     Both are floors, not layout. Anything sized deliberately is unaffected. */
  #root, #ordersPane, .col-main, .col-side, .page-cols > * { min-width: 0; }

  /* ---- The shared frame ---------------------------------------------- */

  /* The homepage sets its own three-column frame inline and is left alone. */
  body:not([data-page="home"]) .wrap {
    max-width: 1180px;
    padding: 26px 30px 120px;
  }

  /* The nav bar is handled outside this block, because where it goes depends on
     how much room the header has. See the two queries at the end of the file. */



  /* Nothing sits at the bottom any more, so pages do not need to leave room. */
  .wrap { padding-bottom: 60px; }

  /* The header keeps its content aligned with the page beneath it. */
  header.bar .wrap-bar { max-width: 1180px; }

  /* ---- Forms ----------------------------------------------------------
     A form is read top to bottom and its fields are short. Stretching them to
     the full width of a monitor makes every one of them harder to read, so
     these pages stay in a narrow column. */

  body[data-page="inquiry-status"] .wrap,
  body[data-page="reset"] .wrap { max-width: 760px; }

  /* ---- Two columns, not one stretched one ----------------------------
     A page whose content is a single column should not grow to fill a monitor;
     the line just gets harder to read. Instead the column keeps a sensible
     width and a rail sits beside it carrying the things people actually ask
     about on that screen.

     The rail is desktop only. On a phone it is display:none, so those pages are
     exactly what they were and nothing extra has to be scrolled past. */

  .page-cols {
    display: grid;
    grid-template-columns: minmax(0, 1fr) 304px;
    gap: 26px;
    align-items: start;
    max-width: 1180px;
    margin: 0 auto;
  }
  .page-cols > .wrap { max-width: none; margin: 0; padding-left: 0; padding-right: 0; }

  .side-rail { position: sticky; top: 76px; padding: 26px 0 40px; }
  .sr-card {
    background: var(--field);
    border: 1px solid var(--line);
    border-radius: 14px;
    padding: 15px 17px;
  }
  .sr-card + .sr-card { margin-top: 14px; }
  .sr-card h3 { margin: 0 0 6px; font-size: .95rem; font-weight: 800; letter-spacing: -.01em; }
  .sr-card p { margin: 0; font-size: .87rem; line-height: 1.55; color: var(--ink-soft); }

  /* Reading widths for the column beside the rail. */
  body[data-page="register"] .page-cols,
  body[data-page="account"] .page-cols,
  body[data-page="inquiry"] .page-cols { max-width: 1060px; grid-template-columns: minmax(0, 700px) 304px; justify-content: center; }
  body[data-page="order"] .page-cols { max-width: 1060px; grid-template-columns: minmax(0, 700px) 304px; justify-content: center; }
  body[data-page="rider"] .page-cols { max-width: 1120px; }

  /* Prose. Long lines are tiring to read, so these stay narrower still. The
     blog already sets its own container, which this leaves alone. */
  body[data-page="legal"] .wrap { max-width: 720px; }
  body[data-page="blog"] .wrap { max-width: 760px; }

  /* ---- Lists of orders -------------------------------------------------
     One column, wider cards, contents laid along the row instead of stacked. */

  body[data-page="orders"] .order-card { padding: 18px 20px; }
  body[data-page="orders"] .order-card .oc-name { font-size: 1.08rem; }
  body[data-page="orders"] .oc-del { top: 14px; right: 14px; }

  /* A single order, read while waiting for it. Narrow, like a receipt. */

  /* ---- Outlet dashboard ------------------------------------------------ */

  body[data-page="dashboard"] .wrap { max-width: 1320px; }

  /* The dashboard is two columns: whichever screen is open on the left, the
     order queue on the right. The queue is a sibling of #root, not a child, so
     the seventeen screens that rewrite #root cannot destroy it.

     Both columns are placed explicitly, so nothing else appearing or
     disappearing above them, the alerts banner included, changes the frame. */
  body[data-page="dashboard"] .wrap {
    display: grid;
    grid-template-columns: minmax(0, 1fr) minmax(0, 1.15fr);
    gap: 20px;
    align-items: start;
  }
  /* ---- Rows, not just columns --------------------------------------------

     Three boxes: the screen, the queue, the tables. Placed by column alone the
     grid gave each a row of its own, so the queue shared row one with the
     screen and the tables were pushed into row two.

     Row one is then as tall as the taller of the two. Open an order and the
     queue becomes very tall, so the tables were shoved down past the bottom of
     it and a screen's worth of blank space opened up under the shop controls.

     So the rows are stated as well. The screen takes row one and the tables row
     two, both on the left; the queue spans both on the right and its height
     stops deciding where anything on the left begins. */
  body[data-page="dashboard"] #root { grid-column: 1; grid-row: 1; min-width: 0; }
  body[data-page="dashboard"] #tablesPane { grid-column: 1; grid-row: 2; min-width: 0; }
  body[data-page="dashboard"] #ordersPane {
    grid-column: 2; grid-row: 1 / span 2; min-width: 0;
  }

  /* The tables go under the shop's own controls, because that is where the
     outlet is already looking.

     On a phone none of this applies: the wrap is not a grid there, the boxes
     stack in markup order, and the tables stay exactly where they were. */
  body[data-page="dashboard"] #tablesPane[hidden] { display: none; }

  /* The queue follows you down the page and scrolls on its own, so a long list
     never pushes the left side out of reach. */
  body[data-page="dashboard"] #ordersPane {
    position: sticky;
    top: 76px;
    overflow-y: auto;
    padding-right: 4px;
    /* Exactly what is left of the screen under the header, so the page itself
       never grows taller than the viewport. The queue scrolls inside its own
       box, and the page does not scroll into empty space below a short left
       column.
       76px header, 26px above the wrap, 24px below it. */
    max-height: calc(100vh - 126px);
    /* The sticky offset already accounts for the header, so the box may only
       be as tall as what remains beneath it. */
    top: 76px;
  }

  /* 120px of bottom padding was there to clear the bar that used to sit at the
     foot of the screen. It moved into the header at this width, so the space
     under the content is just emptiness to scroll through. */
  body[data-page="dashboard"] .wrap { padding-bottom: 24px; }

  /* The left column is narrower than the page was, so the status cards drop to
     one per row rather than being squeezed. */
  body[data-page="dashboard"] #root .statusgrid { grid-template-columns: repeat(auto-fit, minmax(230px, 1fr)); }

  /* auto-fit rather than a fixed four. The number of cards here changes with
     what the outlet has switched on, and a fixed count leaves whatever is
     missing as a hole in the row. auto-fit lets however many there are share
     the width evenly. */
  body[data-page="dashboard"] .statusgrid,
  body[data-page="dashboard"] .dash-shortcuts { grid-template-columns: repeat(auto-fit, minmax(260px, 1fr)); }

  /* Full width gives a dish row room to put its name, price and status on one
     line, with the buttons and the switch at the end. min-width:0 is what keeps
     the name able to shrink instead of forcing the row wider than the card. */
  body[data-page="dashboard"] .menu-row { align-items: center; }
  body[data-page="dashboard"] .menu-info { flex: 1 1 auto; min-width: 0; flex-direction: row; align-items: baseline; gap: 14px; flex-wrap: wrap; }
  body[data-page="dashboard"] .menu-name { min-width: 0; overflow-wrap: anywhere; }
  body[data-page="dashboard"] .menu-acts { flex: none; flex-direction: row; align-items: center; gap: 16px; }

  /* The menu stays one list, exactly as it is on a phone.
     It was briefly folded into two columns. That was wrong: a dish row is a
     flex row of a name, a price, two buttons and a switch, and the buttons do
     not shrink, so halving the width left the name a single character wide and
     stacked down the card. A list reads better here anyway. */

  body[data-page="dashboard"] .menu-tabs,
  body[data-page="dashboard"] .mb-searchwrap { max-width: 620px; }

  /* The delivery tier rows and the table cards already flow; they just need the
     room, which the wider wrap gives them. */
  /* Three across here too. The dashboard used to widen the minimum to 280px,
     which on a desktop left column still resolved to one column. */
  body[data-page="dashboard"] .tbl-grid { grid-template-columns: repeat(3, minmax(0, 1fr)); }

  /* ---- Kitchen screen --------------------------------------------------
     This one usually runs on a fixed display that nobody is holding, so it gets
     the whole width and larger type. */

  /* The kitchen screen uses .kwrap, not .wrap. */
  body[data-page="kitchen"] .kwrap { max-width: 1400px; font-size: 1.06rem; }
  /* Order tickets side by side, so a cook can see the whole queue without
     touching anything. This is the one screen where a grid beats a list,
     because nobody is holding it and nobody is scrolling it. */
  body[data-page="kitchen"] #kList { display: grid; grid-template-columns: repeat(auto-fill, minmax(340px, 1fr)); gap: 14px; align-items: start; }
  body[data-page="kitchen"] #kList .kcard { margin-bottom: 0; }
  body[data-page="kitchen"] #kList .kempty { grid-column: 1 / -1; }

  /* ---- Delivery partner ------------------------------------------------ */


  /* ---- Staff panels ---------------------------------------------------- */

  body[data-page="panel"] .wrap { max-width: 1120px; }
  body[data-page="panel"] .kv th { width: 30%; }

  /* ---- Outlet page, the customer ordering screen -----------------------
     A menu is a list that is read down, so it stays one column and simply gets
     the room. The dish rows lay their name, price and add button along the row
     instead of stacking them. */

  body[data-page="shop"] .wrap { max-width: 900px; }

}

/* Very wide screens. Past this the eye has to travel too far from the start of
   a row to its end, so the frame stops growing and centres instead. */
@media (min-width: 1700px) {
  body[data-page="dashboard"] .wrap { max-width: 1320px; }
  body[data-page="kitchen"] .kwrap { max-width: 1560px; }
}

/* The rails are a desktop addition. Below the breakpoint they are not rendered
   at all, so every page is exactly what it was on a phone. */
@media (max-width: 1023.98px) {
  .side-rail { display: none; }
}

/* ===========================================================================
   Overflow guards. Outside the media query on purpose: a control spilling past
   its container is wrong at every width, and it was wrong on a phone before
   there were any columns.
   =========================================================================== */

/* Nothing is ever wider than what holds it. */
.btn, button, input, select, textarea { max-width: 100%; }

/* A .btn is width:100%. Marked flex:none in a row it keeps that full width and
   cannot shrink, so two of them come to twice the row and the second lands
   outside. Where the markup has already said "do not flex", it wants the button
   sized to its label, so width follows. Buttons that set their own width, and
   buttons that are allowed to flex, are both untouched. */
.btn[style*="flex:none"]:not([style*="width"]),
.btn[style*="flex: none"]:not([style*="width"]) { width: auto; }

/* ===========================================================================
   Where Home, Delivery Partner, Orders and Profile live.

   A bar pinned to the bottom of a monitor is a phone pattern, so on a desktop
   they belong in the header. They only fit there once the header is wide enough
   for the logo, the nav and the header's own buttons to sit side by side without
   meeting. Below that they stay at the bottom, as a centred dock rather than a
   full-width strip.

   Moved by CSS rather than markup because header.js renders this bar itself.
   The class is doubled throughout because header.js injects its own .botnav
   rules at runtime, which land after this file and would win any tie.
   =========================================================================== */

@media (min-width: 1280px) {
  /* header.js reserves 74px at the foot of every page for the bar that used to
     sit there. The bar lives in the header at this width, so that reservation
     is empty space the page scrolls into and nothing more.

     html body outranks the plain body rule header.js injects at runtime, which
     would otherwise win on source order. */
  html body { padding-bottom: 0; }

  /* The same reservation, in the variable form. --botnav-h is what everything
     that sits above the bottom bar measures itself against, and header.js sets
     it to 74px for the bar it creates. At this width the bar is in the header
     and there is nothing at the foot of the screen, so anything still holding
     74px clear is holding it clear of nothing.

     The storefront's Place Order footer is the visible case: it floated 74px up
     the page with menu rows showing underneath it, instead of sitting on the
     bottom edge where a checkout bar belongs. Below 1280px this stays at 74px,
     because there the green bar really is down there.

     html:root, not :root, for the same reason the padding rule above uses
     html body. header.js injects its own :root rule into the document at
     runtime, so it arrives after this stylesheet and wins any tie on source
     order. The extra element selector outranks it without touching header.js. */
  html:root { --botnav-h: 0px; }

  /* Now a child of the header, centred within it. Absolute rather than fixed,
     so it belongs to the header and travels with it when anything appears
     above, instead of hanging in the viewport on its own. */
  header.bar .wrap-bar { position: relative; }
  .botnav.botnav {
    position: absolute;
    top: 50%; bottom: auto;
    left: 50%; right: auto; transform: translate(-50%, -50%);
    width: auto; height: auto;
    display: flex; align-items: center;
    background: none; box-shadow: none; border-radius: 0;
    padding: 0; z-index: 2;
  }
  .botnav.botnav .botnav-inner { max-width: none; width: auto; }
  /* Icon beside label rather than above it, so the row fits the header. */
  .botnav.botnav .bn-item {
    flex: 0 0 auto; min-width: 0;
    flex-direction: row; gap: 8px;
    margin: 0 2px; padding: 8px 14px;
    font-size: .82rem; white-space: nowrap;
  }
  .botnav.botnav .bn-item svg { width: 19px; height: 19px; }

  /* The account menu now hangs off the Profile button. Right-aligned to it, and
     nudged clear of the header so it does not sit on the green. */
  .botnav.botnav .bn-item .acct-menu {
    top: calc(100% + 14px);
    right: 0;
    left: auto;
    text-align: left;
  }

  /* The nav is centred on the viewport, so the header's own content has to be
     pushed out to the edges rather than pulled toward the middle. */
  header.bar .wrap-bar { max-width: 1500px; padding: 0 4px; }

  /* Nothing sits at the bottom any more. */
  .wrap { padding-bottom: 60px; }
}

@media (min-width: 1024px) and (max-width: 1279px) {
  /* Not enough header for three things across, so the bar stays at the bottom,
     centred and sized to its content instead of spanning the screen. */
  .botnav.botnav {
    left: 50%; right: auto; transform: translateX(-50%);
    bottom: 18px; width: auto; border-radius: 18px; padding-bottom: 0;
    box-shadow: 0 10px 30px rgba(18, 90, 52, .3);
  }
  .botnav.botnav .botnav-inner { max-width: none; width: auto; }
  .botnav.botnav .bn-item { flex: 0 0 auto; min-width: 108px; }
}