/* ══ KB-1173 (2 Sep 2026): the Pesta Bina flash sale band, and the two buttons it carries ══
   ─────────────────────────────────────────────────────────────────────────────────────────────────
   WHY THIS FILE EXISTS AT ALL.
   The yellow countdown button and the maroon super flash button were born inside
   public/pesta-bina.html's own <style> block (KB-1121 and KB-1161). The home page now shows the same
   sale, and a second hand-drawn copy of those two buttons is precisely how three surfaces start
   disagreeing about what colour the sale is. So the SKINS live here, in one file, and any page that
   wants them links it. Nothing about the geometry is re-invented anywhere: both buttons carry
   .btn.lg from tokens.css, so their height, radius, font and spacing are the ones "Book tickets"
   uses beside them, and ONLY the colours are set below.

   🔴 THE COLOUR GRAMMAR IS ABSOLUTE. Never mix them, never blend them, never introduce a third.
       YELLOW  #ffd21e, black ink   the plain flash sale. Every ticket, all day, ends at midnight.
       MAROON  #7B1E28, white ink   the hourly super flash. A few tickets on the quietest slots,
                                    and it ends at the top of the hour, not at midnight.
   The maroon is what says "scarce, and only here". A build that used yellow for both was rejected
   for exactly that reason: it flattened two different offers into one. The two clocks genuinely
   count to different moments, which is the whole reason there are two buttons rather than one.
   #7B1E28 is the SAME maroon as the booking chips and the rates panel, deliberately, rather than a
   fourth near-miss of the same red.

   CONTRAST, measured rather than assumed. #1a1a1a on #ffd21e is 12.0:1 and #fff on #7B1E28 is
   10.20:1, both far past the 4.5:1 body text needs, and both re-measured on the rendered element
   for KB-1173 rather than trusted from the older file's comment.

   WHO LINKS THIS. public/home.html for its sale band, and public/pesta-bina.html for the festival
   hero. The festival page carried its own inline copy of these two skins for a day, scoped as
   `.phero .pfbtn` / `.phero .pfsbtn`, because a second ticket was live in that file during a running
   sale; the copy was deleted and replaced with a link to this file once the sale was safe to touch.
   THERE IS NO SECOND COPY ANY MORE, and there must never be one again. A new page that wants these
   buttons links this file. It does not paste the declarations, because the moment two files carry
   them, one of them gets a colour change and the two pages disagree on screen.

   ONE THING THAT CHANGED WHEN THE FESTIVAL PAGE ADOPTED THIS FILE, and it is a fix rather than a
   regression: its inline copy had no `gap:0` / `margin-left` pair, so it leaned on .btn's own flex
   `gap:7px`, which Safari 12 does not support. On the workshop iPad the sentence and the clock were
   touching. Every browser that supports gap renders the identical 7px either way, so nothing moved
   on a modern screen; the old iPad simply stopped being wrong. See the gap block further down.
   ───────────────────────────────────────────────────────────────────────────────────────────────── */

/* The shared reveal. Nothing on this band appears out of nowhere; it fades and settles down 6px.
   Copied verbatim from pesta-bina.html, which is also where .fshero gets it. */
@keyframes pfIn{from{opacity:0;transform:translateY(-6px)}to{opacity:1;transform:none}}

/* ── THE YELLOW BUTTON: the plain sale, every ticket, all day ───────────────────────────────────
   It is a real link to the booking page and never a decorative chip. A yellow element the exact
   shape of the primary button that does nothing when tapped is precisely the misleading-badge
   failure the landing-page rules exist to prevent, so the countdown carries the customer to the
   page it is asking them to hurry to.

   The [hidden] pair below is NOT optional. .btn already sets display:inline-flex in an author
   stylesheet, which outranks the browser's own [hidden]{display:none}, so without an explicit
   author rule the button would show through even while hidden, on every day of the year. */
.pfbtn{background:#ffd21e;color:#1a1a1a;border-color:#e0a800;font-weight:700;max-width:100%}
.pfbtn:hover{background:#ffdd4d;border-color:#e0a800;color:#1a1a1a;box-shadow:var(--e2);transform:translateY(-1px)}
.pfbtn[hidden]{display:none}
.pfbtn:not([hidden]){display:inline-flex;animation:pfIn var(--t-slow) var(--ease-snap) both}
.pfbtn .pfbtext{white-space:nowrap}
/* tabular-nums so a ticking second never changes the button's width and nudges its neighbour once a
   second. --disp matches the display face the rest of the sale uses for digits. */
.pfbtn .pfbclock{white-space:nowrap;font-family:var(--disp);font-weight:700;font-variant-numeric:tabular-nums;letter-spacing:.02em}

/* ── THE MAROON BUTTON: the hourly super flash ──────────────────────────────────────────────────
   Same shape, same size, same behaviour as the yellow one, and ONLY the colour differs, which is
   what makes the two read as a pair of offers rather than a button and a decoration. Also a real
   link, for the same reason. */
.pfsbtn{background:#7B1E28;color:#fff;border-color:#5e1620;font-weight:700;max-width:100%}
.pfsbtn:hover{background:#932430;border-color:#5e1620;color:#fff;box-shadow:var(--e2);transform:translateY(-1px)}
.pfsbtn[hidden]{display:none}
.pfsbtn:not([hidden]){display:inline-flex;animation:pfIn var(--t-slow) var(--ease-snap) both}
/* The words wrap and the digits never do: a clock that breaks across two lines stops being a clock. */
.pfsbtn .pfsbtext{min-width:0}
.pfsbtn .pfsbclock{white-space:nowrap;font-family:var(--disp);font-weight:700;font-variant-numeric:tabular-nums;letter-spacing:.02em}

/* The gap between the words and the clock, done with a margin rather than .btn's flex `gap`.
   Safari 12 does not support gap on a flex container, and the workshop iPad is stuck on Safari 12,
   so a gap-only spacing would leave the sentence and the digits touching on that device. Seven
   pixels either way, identical on every browser, and no @supports block needed. */
.pfbtn,.pfsbtn{gap:0}
.pfbtn .pfbclock,.pfsbtn .pfsbclock{margin-left:7px}

/* ══ THE HOME PAGE BAND ═════════════════════════════════════════════════════════════════════════
   A band, not a second hero. Stacking a full-height sale hero on top of the home page's own would
   push PESTA BINA! and its Book Tickets button below the fold during the exact hours the sale most
   needs them reachable.

   🔴 VISIBILITY IS NEVER THIS FILE'S DECISION AND IS NEVER A DATE. The band starts `hidden` and
   assets/pesta-flash.js reveals it on the server's own live `flash.active`. So it appears when the
   sale opens, leaves the moment the sale ends, comes back by itself the next time one runs, and a
   config fetch that fails leaves it hidden rather than advertising a discount nobody can buy.

   The [hidden] pair below is NOT optional and repeats the trap documented on .pfbtn above: a bare
   `.hfs{display:block}` has the same specificity as the UA sheet's `[hidden]{display:none}` and,
   being an author rule, wins it, so the `hidden` attribute would quietly stop hiding anything. */
.hfs{background:#1a1a1a;border-bottom:1px solid rgba(255,255,255,.10);overflow:hidden}
.hfs[hidden]{display:none}
/* NO LAYOUT SHIFT, and this is the whole reason the band grows instead of simply appearing.
   The home page is the highest-traffic surface here. A band that pops in at full height shoves the
   hero, and everything under it, down under a finger that is already reaching for Book Tickets.
   So the revealed band starts at zero height and EASES open over --t-slow, carrying the hero down
   with it rather than teleporting it. max-height rather than height because the band's real height
   depends on how the buttons wrap, which is not knowable from CSS; the script hands it back to
   `none` once the animation has finished, so a rotation or a font change reflows it normally
   instead of leaving it pinned to a ceiling.
   Readers with reduced motion get tokens.css's global transition:none, so it simply is open, which
   is the behaviour they asked for. */
.hfs:not([hidden]){display:block;max-height:0;opacity:0;transition:max-height var(--t-slow) var(--ease-snap),opacity var(--t-slow) var(--ease-snap)}
.hfs.is-on{max-height:520px;opacity:1}
/* ══ KB-1174: THE PHOTOGRAPH BEHIND THE BAND ═════════════════════════════════════════════════════
   A real Pesta Bina, so the strip announcing the festival looks like the festival instead of a black
   rectangle. assets/pesta/flash-sale-band.webp, 1600x1065, 50KB.

   🔴 IT HANGS OFF .is-on, AND THAT IS THE POINT, not tidiness.
   This is the busiest page we have, and the band only exists while a sale is actually running. A
   background-image on plain .hfs would be fetched by every visitor on every load, including everyone
   who arrives on a day with no sale and sees nothing at all. `is-on` is set by pesta-flash.js only
   after the server has confirmed a live sale, so on a no-sale day the rule never matches and the
   browser never asks for the file. Verified by watching the requests on the live page, not assumed.

   🔴 NOTHING MOVES, AND THERE IS NOTHING TO RESERVE. Only background-image is set here, so .hfs's
   own background:#1a1a1a stays underneath as the ground. The band's height has never depended on
   this image (the words and the way the buttons wrap decide it), so a slow photo, a 404, or images
   switched off all leave the band exactly as it looked before this ticket, and the arriving photo
   shifts nothing.

   THE CROP IS A DECISION, NOT A DEFAULT. On a desktop this band is about 3008x162, roughly 18:1, so
   it shows about an EIGHTH of the frame's height and which eighth is a choice. Six were rendered and
   looked at: 20% and 28% are bare timber and wall, 36% is the tops of people's heads, 44% slices
   everyone across the eyes. 52% is the one that carries a picture: the centre figure's glasses and
   full smile, the green KitaBina shirt beside her, a third face to the right, leaning timber behind.
   A percentage anchors that line at EVERY width, so a narrower desktop shows more of the same
   picture rather than a different one. On a phone the band is far taller because the buttons stack,
   and 1600x1065 against a box of nearly the same proportion means a phone gets very nearly the whole
   photograph. That is why this file is the full frame and not a pre-cut strip.

   THE SCRIM IS SIZED FROM THE PHOTO. White #fff needs whatever is under it at 0.183 relative
   luminance or below to hold 4.5:1, and the yellow #ffd21e needs 0.111, so THE YELLOW IS THE BINDING
   CONSTRAINT and measuring the white alone would have proved nothing. The brightest pixel anywhere
   in the photograph is rgb(220,230,228) at 0.774. Under 72% black the worst case anywhere in the
   whole frame is 7.19:1 for the yellow and 10.41:1 for the white; across the strip a desktop
   actually shows, 8.49:1 and 12.30:1. Both clear 4.5:1 with room left for the encoder.
   A gradient scrim would have looked nicer and is exactly wrong here: it makes contrast depend on
   where in the band a word happens to land at a width nobody measured. Flat is provable.

   NEVER TILES: cover and no-repeat, at every width, per the standing rule. */
.hfs.is-on{background-image:linear-gradient(rgba(0,0,0,.72),rgba(0,0,0,.72)),url('pesta/flash-sale-band.webp');background-position:center 52%;background-size:cover;background-repeat:no-repeat}
/* padding:0 is doing real work. .hfs is a <section>, and components.css gives every section on the
   site 60px of top and bottom padding (40px below 560px). Inherited here that stacked on top of the
   band's own padding and left a large empty black area under the buttons, which looked like a
   rendering fault rather than breathing room. This is a strip announcing a sale above a hero, not a
   page section, so it owns its own vertical rhythm. Spotted by looking at the rendered band at 375px. */
.hfs{padding:0}
.hfs .wrap{padding:28px 24px 30px;text-align:center}
/* Per the landing-page rules this carries the offer and nothing else: no eyebrow, no explanatory
   sentence under it, no notice bar, no decorative badges. The two buttons below are genuinely
   clickable, which is what makes them allowed here. */
.hfs-t{font-family:var(--disp);font-weight:800;color:#fff;margin:0 0 14px;font-size:27px;line-height:1.14;letter-spacing:-.01em}
.hfs-t b{color:#ffd21e;font-weight:800}
/* Plain px and a media query rather than clamp(): Safari 12 does not support clamp() and would drop
   the whole declaration, and this file has no room for a fallback dance. */
@media(max-width:640px){.hfs-t{font-size:20px}.hfs .wrap{padding:22px 16px 24px}}
/* Margins rather than flex `gap`, same Safari 12 reason as the buttons above. */
.hfs-b{display:flex;flex-wrap:wrap;justify-content:center;margin:0 -5px}
.hfs-b > *{margin:5px}
/* 🔴 THE BUTTONS MUST BE ALLOWED TO GROW, and this is not cosmetic.
   .btn.lg pins height:48px. The maroon button's sentence is "Super flash sale! Up to 90% off, this
   hour ends in" plus a clock, which is three lines at 320px. Inside a box pinned to 48px that text
   spills straight out of the button. So the pin becomes a floor here and the box grows to fit its
   own words. The two buttons keep identical rules, so they stay a matched pair; on a desktop both
   are a single line and sit at exactly the 48px .btn.lg gives them. */
.hfs .pfbtn,.hfs .pfsbtn{height:auto;min-height:48px;padding-top:9px;padding-bottom:9px;line-height:1.25;text-align:center;justify-content:center}
/* One button per line on a phone, so neither is squeezed narrower than its own words. components.css
   already makes .btn.lg full width below 560px; this keeps the pair honest in the band between. */
@media(max-width:620px){.hfs-b > *{flex:1 1 100%}}
/* 🔴 ON A PHONE THE CLOCK GOES ON ITS OWN LINE, and this is a readability fix rather than a taste.
   The button is a flex row of two children: the sentence, and the digits. Below about 500px the
   sentence no longer fits on one line, so it wraps INSIDE its own flex item while the digits stay
   pinned to the right of it, vertically centred. What that produced at 375 and at 320 was

       Super flash sale! Up to
       90% off, this hour ends     46:01
                 in

   with the word "in" orphaned on a line of its own and the clock floating away from the sentence it
   belongs to. Caught by looking at the rendered page at 320px, not by reading the CSS.
   Stacking the two items fixes it: the sentence wraps normally across the full width and the clock
   sits under it, centred. 520px rather than the 620px above because between the two the sentence
   still fits on one line and stacking there would look broken instead of fixing anything.
   THE YELLOW BUTTON IS DELIBERATELY LEFT ALONE. "Flash sale ends in 11:46:01" fits on one line all
   the way down to 320px, so stacking it would add a line, and a band that is taller than it needs to
   be on the smallest screen is the opposite of the fix. The two buttons were never the same height
   on a phone anyway: the maroon one has three times the words. */
@media(max-width:520px){
  .hfs .pfsbtn{flex-wrap:wrap}
  .hfs .pfsbtn .pfsbtext{flex:1 1 100%}
  .hfs .pfsbtn .pfsbclock{flex:1 1 100%;margin-left:0;margin-top:2px}
}