/* ========================================================================== metaeden-v4-game.css -- what the v4 play surface adds (TASK-1113[Q]). Loaded ONLY by sites/v4-game.html, after metaeden.css (the cartridges' own presentation) and metaeden-v4.css (the chrome and all four themes). Every rule is scoped under .v4-game-page, which is a class on that page's own , so nothing here can reach the site root, the section shell or the arcade floor. THE COLOUR RULE THIS FILE KEEPS: it declares no text colour of its own. Anything the surface says inherits the body colour on the body background, which is one of four pairs metaeden-v4.css already ships -- 9.4:1 to 11.1:1 once the CRT wash is composited at the shipped combo/35, measured the same headless way metaeden_net_scanline_contrast.test.js measures. Reaching for h2 .sub would have been the natural thing and is exactly what not to do: that pair is 4.40:1 in the gold theme and 4.23:1 unthemed, two of the 33 already under the floor and owned by TASK-1107[Q]. A new surface does not get to add a 34th. Differentiation here is size, weight, spacing and a rule -- never a dimmer ink. server/metaeden_net_v4_game_surface.test.js measures the four pairs and also greps this file for a text-colour declaration, so the rule cannot lapse by somebody adding one. THE BORDER COLOURS ARE BORROWED, NOT INVENTED. Each theme already owns a divider colour in metaeden-v4.css -- h2's bottom rule in three of them, and in grey the #888 that hr, th, .side, .docbody and .ring all draw with. The boxes below use that colour, and in grey they use grey's own idiom too: a top-and-bottom rule instead of a full box, exactly like .side and .docbody. Borders are decoration; the 4.5:1 floor is about ink. ========================================================================== */ /* [hidden] has to beat the display values below, or an element the adapter left hidden would be laid out anyway. */ .v4-game-page [hidden] { display: none !important; } /* THE TAB ROW'S SHORT FORMS ARE OFF HERE (TASK-1186[Q]). Two of the six links carry both a long word and a short one in the markup (v4-game.html's own note says why it is markup and not a rule); this file is the surface's ALWAYS sheet, so it declares the desktop answer -- the long word -- and mobile-e-game.css, which no desktop fetches, swaps them at phone widths. Stated in this direction on purpose: a phone that somehow never gets the mobile sheet reads "documents" and "guestbook" and is merely wide, while the other way round it would read both words of each pair. */ .v4-game-page .tabnarrow { display: none; } /* THE PLAY COLUMN IS CAPPED, and the site root's is not, on purpose. The shell is min(100% - 48px, 1760px), which is right for a table of eight rows and wrong for one cabinet: metaeden.css caps its cartridge internals between 520px and 760px, so an un-capped column leaves a 640px-wide game adrift in 1700px of frame. 820px clears the widest cartridge in that file plus this surface's own padding and border, so the eight still to come fit without this number moving. AND IT IS CENTRED IN THAT FRAME, user's word: everything in this section reads centred except the site's own top banner, which lives in

, outside .gplay, and is untouched by anything in this file. */ .v4-game-page .gplay { max-width: 820px; margin: 0 auto; } /* THE HEADING LINE -- title plus blurb -- centred with the column it sits in. It was one

with the blurb as a span inside it until TASK-1186[Q]; it is now an

and a
side by side in .ghead, so that a phone can move the blurb out from under the title and put it below the game (the user's ask; mobile-e-game.css does the moving, and v4-game.html's own note carries the reasoning). A CENTRED FLEX ROW, aligned on the baseline, reproduces what the inline pair drew: measured against the shipped page at 1280, the title and the blurb land on the same line with a 9px gap between them, so 9px is what the gap says. It wraps rather than squeezing, which is what the inline version did too. AND THE HEADING RULE IS ON THIS BOX, NOT ON THE

. metaeden-v4.css gives every h2 `margin: 28px 0 10px; padding-bottom: 6px; border-bottom: 1px solid` and a colour per theme, and while the blurb lived inside the h2 that rule spanned the whole heading. A flex item is sized to its content, so left on the h2 the divider would now stop at the end of the title. Moved out here it spans exactly what it always spanned. The four colours are BORROWED, not invented -- they are metaeden-v4.css's own h2 border colours, the same borrowing (and the same reason) as .gstage/.gmiss below; grey draws no divider under an h2 and draws none here either. / .v4-game-page .ghead { display: flex; flex-wrap: wrap; align-items: baseline; justify-content: center; column-gap: 9px; margin: 28px 0 10px; padding-bottom: 6px; border-bottom: 1px solid #cee3f8; text-align: center; } / border-color rather than border-bottom-color, which is the .gstage rules' idiom two blocks down and is not cosmetic: the guard suite reads "the text before `color:`" to tell a border colour from an ink, so the longhand reads to it as an unmeasured text colour and turns section F red. Three of the four sides have no width here, so setting all four says the same thing. / .v4-game-page.dark .ghead { border-color: #333333; } .v4-game-page.neon .ghead { border-color: #f2c200; } .v4-game-page.dxhr .ghead { border-color: #3a3020; } .v4-game-page.grey .ghead { border-bottom: 0; } / ...and the h2 gives up the box it no longer owns. min-width:0 so a long title wraps inside its own item instead of forcing the row wider than the column. / .v4-game-page .ghead > h2 { margin: 0; padding-bottom: 0; border-bottom: 0; min-width: 0; } / IT IS NOT A LINK AND MUST STOP DRESSING AS ONE (TASK-1189[Q]). The user: "Make the game title not blue and highlighted (otherwise it looks like a link, and it's not)." The source is body.grey h2 in metaeden-v4.css -- `color:#0000ee` plus `text-decoration:underline` -- and it is RIGHT where it lives: on the site root every h2 heads a section you can click through to, and the grey theme is the one that dresses like a 1996 document. Here the h2 is the name of the cartridge already on the screen, so the same paint is a promise the page cannot keep. Overridden HERE rather than fixed there, deliberately: metaeden-v4.css is shared with the site root, and this is the game surface disagreeing about one heading, not the theme being wrong. `inherit` rather than a literal so it takes whatever ink the theme gives its body -- no fifth colour pair for anyone to measure. / .v4-game-page.grey .ghead > h2 { color: inherit; text-decoration: none; } / The blurb under the heading. Sized and spaced like h2 .sub, inked like the body, for the reason in the header above. / .v4-game-page .gsub { font: 400 18px Michroma, Verdana, sans-serif; letter-spacing: 0; color: inherit; } .v4-game-page .ghead > .gsub { margin: 0; min-width: 0; } .v4-game-page.grey .gsub { font-family: "Times New Roman", Times, serif; font-style: italic; } / The frame around the cartridge. / .v4-game-page .gstage, .v4-game-page .gmiss { margin: 16px 0 0; padding: 10px; border: 2px solid #cee3f8; } .v4-game-page.dark .gstage, .v4-game-page.dark .gmiss { border-color: #333333; } .v4-game-page.neon .gstage, .v4-game-page.neon .gmiss { border-color: #f2c200; } .v4-game-page.dxhr .gstage, .v4-game-page.dxhr .gmiss { border-color: #3a3020; } .v4-game-page.grey .gstage, .v4-game-page.grey .gmiss { padding: 12px 0; border: 0; border-top: 1px solid #888888; border-bottom: 1px solid #888888; } / The cartridge sets its own top margin for the old surface's stacked shelf; inside a frame of its own it does not need one. / .v4-game-page .gstage > { margin-top: 0; } .v4-game-page .gnote { margin: 14px 0 0; font-size: 17px; color: inherit; text-align: center; } .v4-game-page .gmiss { text-align: center; } .v4-game-page .gmiss p { margin: 0 0 8px; } .v4-game-page .gmiss p:last-child { margin-bottom: 0; } .v4-game-page .gback { display: flex; flex-wrap: wrap; justify-content: center; gap: 8px; margin: 24px 0 0; } /* -------------------------------------------------------------------------- WHY THERE IS STILL NO @media (max-width: ...) BLOCK HERE, which is the first thing anybody adding a cartridge will reach for. TASK-1136[Q] changed the REASON without changing the answer, so read this before deciding the note went stale. THE ORIGINAL REASON, which holds wherever METScape is still served. browser-frame.css:2 pins `body.browser-framed { min-width: 1920px }` and gives the frame itself a flat `width: 1920px`. METScape is a picture of a 1996 desktop, not a responsive shell. So .shell resolves to its 1760px cap and .gplay to 820px, while a media query keys off the VIEWPORT rather than off that box: at 375px it would match while the container was still 820px wide, collapsing a cartridge that has plenty of room. MEASURED, on the rig, at 375px. WHAT CHANGED. browser-frame.css/js are no longer served to this page at every width. They are gated to 769px and up, and below that mobile-e-game.css runs in their place; the swap comment in sites/v4-game.html is the whole story. So under 768px the premise above is simply gone -- the column really is as narrow as the viewport, and a width rule really would mean what it says. It just does not belong HERE. The narrow-width rules for this surface live in mobile-e-game.css, which is served ONLY at those widths, so they have one home rather than two halves that can disagree about which of them is in force. AND ONE MORE HOME SINCE TASK-1143[Q], for one idea neither file can hold: metaeden-v4-game-fit.css carries how the FULLSCREEN MODE sits on a phone (both orientations -- its media gate has a max-height half, because a phone turned sideways is 844px wide and mobile-e-game.css's width gate cannot see it). That file is about the mode's fixed frame, which lives in VIEWPORT space, so a viewport query is honest there in exactly the way this comment says it is not for the in-page rules this file owns. The division of labour: this file = the mode at desktop, mobile-e-game.css = the PAGE at phone widths, the fit file = the MODE at phone viewports. AND A MECHANICAL REASON, worth knowing before you spend an afternoon rediscovering it. metaeden_net_v4_game_surface.test.js asserts that every selector in this file is scoped to .v4-game-page (H45, plus the mutation harness that proves the check itself works). That parser reads the text before each `{` as a selector, so an at-rule's prelude reads as an unscoped one: a media block here turns the suite red on arrival, whatever is inside it. TASK-1114..1121: if your cartridge is wider than the column, do NOT reach for a width query. It scrolls inside its own box, below. If METScape ever becomes responsive above the breakpoint, the honest tool is a container query on .gplay, not a viewport one. -------------------------------------------------------------------------- / / Wide content scrolls inside its own frame rather than pushing the page -- the house rule from CLAUDE.md's "fixed-size panels, scroll for overflow". auto, not scroll: metaeden.css caps its cartridge internals at 760px and none of them needs this today, so no bar is drawn until one does. / .v4-game-page .gstage { overflow-x: auto; } / ========================================================================== 16:9 IN THE ORDINARY VIEW TOO (TASK-1158[Q]). THE ASK, in the user's words: "try to keep all games at their 1920x1080 aspect ratio at all times no matter which mode they're in." The lock below the fold has held that shape since TASK-1124[Q], but only under .gfs -- the big view. Out of it the frame was whatever height the cartridge inside happened to want, so the same game was a 16:9 screen in one mode and an arbitrary rectangle in the other. These declarations make the frame the same shape in both, so the mode changes how BIG the screen is and never what shape it is. IT IS THE SAME IDEA AS THE BIG VIEW, MEASURED AGAINST A DIFFERENT BOX. Down there the frame is the largest 16:9 rectangle that fits the VIEWPORT. Here it is the largest one that fits the COLUMN -- .gplay, capped at 820px just above -- so `aspect-ratio` alone says the whole of it: the width is already the column's, and the height follows from the ratio. No min() arithmetic, because there is no second axis competing for the space. NOTHING IS EVER CROPPED TO ACHIEVE IT, which was the user's other standing instruction on this ticket ("please prefer letterboxing over cut off content"). A cartridge SHORTER than the box is centred in it and the spare height reads as letterbox. A cartridge TALLER than the box scrolls INSIDE the stage -- the house rule this file already keeps two rules up -- rather than being clipped by the frame or pushing the page. There is no `overflow: hidden` anywhere in this block on purpose: that is the one way the shape could be bought with the player's content, and it is the exact bug this ticket was opened to fix on the arcade page. AND THE CARTRIDGES ARE SCALED INTO IT, which is the half that makes the shape worth having. Locking the frame ALONE was tried first and measured, and that is why this paragraph exists: at 820x461 the stage is 397px, and eleven of the thirteen cabinets are taller than that (xyz by 391px, snakecycle by 305, solitaire by 213), so every one of them drew a scrollbar and showed about two thirds of itself through a 16:9 window. That is the user's own "cut off content" wearing a different hat, and it is worse than the unlocked view it replaced. The ask was "the largest 16:9 box that fits, centred, scaled not stretched", and SCALED is the load-bearing word. SO THE SIZING RULES BELOW THE FOLD ARE SHARED BY BOTH MODES rather than copied into this one. Everything that fits a cartridge to its frame -- the canvas height, minesweeper's and solitaire's published scale knobs, the layout hand-backs for the raycade floor and xyz, the two screens that centre themselves -- hangs off `--gfs-h`, which means "the height of the frame", and each mode declares its own value for it. One set of rules, two frames: a cartridge cannot come out right in one mode and wrong in the other, because there is only one description of how it is fitted. (Rules that are about the MODE rather than the fit -- the fixed position, the letterbox bars, the control strip's themed background -- stay .gfs-only, as they were.) WHY --gfs-h CAN BE A CONSTANT HERE while the big view computes it from the viewport: down there the frame IS the viewport, so it has to be min() arithmetic over 100vw and 100vh. Here the frame is the COLUMN, and the column does not vary anywhere this lock is in force. .gplay is capped at 820px above, and METScape pins body.browser-framed{min-width:1920px} from 769px up, so the page is 1920 wide, .shell resolves to its 1760 cap and .gplay to 820 at every desktop width there is. Below 769px METScape is not served at all and metaeden-v4-game-fit.css releases this whole lock (the column really is as narrow as the glass down there, and a 370x208 letterbox is the wrong spend of a phone). So the one case where 820 would be a lie is the one case this rule is not in force for. box-sizing, MEASURED: .gstage is content-box and carries 10px of padding plus a 2px border, so a flex child at `flex: 1` came out 24px taller than the frame had and drew a scrollbar the moment the lock went on. AND IT IS A FLOOR, NOT A CEILING, which is the last thing this block learned and the thing to read before "correcting" it to `aspect-ratio: 16 / 9`. A hard lock was written first and measured, cabinet by cabinet. With the fit rules below doing their work it still left nine of the thirteen taller than the box, by 7px to 188px -- and the residue is not the playfield, which these rules scale, but each cartridge's own CHROME: golf's console, lex trace's found-word list, solitaire's bottom row. Those are fixed-height and nothing here can shrink them. Dropping the canvas budget to half its size barely moved the total (822px to 345px) and made the games tiny for it. What a hard lock actually shipped was the screenshot that killed it: mini golf in a tidy 16:9 screen with its POWER METER AND BUTTONS below the fold, so putting meant scrolling first. The user gave the tiebreaker for exactly this in the same ticket -- "please prefer letterboxing over cut off content" -- so where the two asks collide, the shape yields. A cartridge that fits gets a real 16:9 screen with the spare height as letterbox, which is the ask and is what most of them get; a cartridge that does not fit makes the box taller instead of hiding its own controls behind a scrollbar. Nothing is ever cropped either way. If a later round wants the hard lock back, it is this one declaration (min-height -> aspect-ratio) plus per-cartridge chrome fits for the nine -- the same work the arcade floor already does for its own eight, further down metaeden.css. / .v4-game-page #gframe { display: flex; flex-direction: column; min-width: 0; min-height: calc(820px 9 / 16); margin-right: auto; margin-left: auto; --gfs-h: calc(820px * 9 / 16); } .v4-game-page #gframe .gfsbar { flex: 0 0 auto; } /* THE STAGE IS LEFT IN NORMAL FLOW, and that is a decision that cost a round to learn. `display: grid` with `align-content: center` was the obvious way to turn spare height into a letterbox instead of a gap under the game, and it is wrong here: a centred grid row is sized to its CONTENT, so a cartridge that asks for `height: 100%` (the raycade floor and xyz both do, to stop their stages deriving a height from their width) resolves that percentage against a track that is itself waiting on the content, gets `auto`, and goes back to being as tall as it is wide. Measured: it put xyz 177px over the frame in the BIG view, which had been exact before the centring was added. A cartridge cannot be handed a definite height and centred against its own content at the same time; the definite height is the one that matters, so the stage stays a plain block and the cartridges centre themselves. overflow stays auto rather than hidden: with the fit rules below nothing should reach it, and if something ever does the house rule is that it scrolls rather than being cropped. AND THE SCROLL CHAINS OUT OF IT AGAIN OUTSIDE THE MODE (TASK-1186[Q]). `overscroll-behavior: contain` sat on this rule unconditionally and is the whole of the user's second report: "it's also hard to scroll while in this view if the game is taking up the whole screen." MEASURED at 375x812 on fishing, which is the cabinet they were holding. The stage is `overflow: auto`, so it is a scroll container whether or not it has anything to scroll -- and there it has nothing: scrollHeight 456 against clientHeight 456, a range of zero. `contain` then means what it says. A drag started anywhere in the game moved window.scrollY from 0 to 0; the same drag on the heading 118px higher moved it 0 to 128, the document's whole range. The game covered y=288..746 of an 812px screen, so 56% of the glass was dead to a finger and the visitor's only purchase on the page was the header strip above it. Releasing the containment here moved that same drag to 128. THE CONTAINMENT IS NOT WRONG, IT WAS JUST TOO WIDE. What it guards is a cartridge whose own board really does pan inside the stage (minesweeper's two big boards) taking the page with it when it reaches an edge, and that is worth guarding IN THE MODE, where the frame is the viewport and there is no page to go to. So it moves to .gfs and the ordinary in-page view -- the one a visitor is actually on when they tap a game -- gets its scroll back. Out there the page behind the stage is the thing they are reaching for. / .v4-game-page #gframe .gstage { box-sizing: border-box; flex: 1; min-height: 0; overflow: auto; } .v4-game-page.gfs #gframe .gstage, .v4-game-page.gbare #gframe .gstage { overscroll-behavior: contain; } / ========================================================================== THE FULLSCREEN MODE'S FRAME (TASK-1124[Q], one control since TASK-1143[Q]). Born as WIDESCREEN: "full viewport but still constrained by aspect ratio, not literal full screen, the user can still opt to do that manually via the browser full screen." TASK-1134[Q] then added a second control that layered the real Fullscreen API on top, and TASK-1143[Q] merged the two at the user's direction -- one button, the fill always, the monitor as well where the browser allows. Everything in this block is the FILL half and is exactly what widescreen was: the class is still .gfs, the arithmetic is untouched, and the API half lives entirely in metaeden-v4-game.js (this stylesheet's only contact with it is the :fullscreen block further down). 1920x1080 IS AN ASPECT, NOT A RESOLUTION. Nothing here renders at a fixed 1920 pixels. The frame is the largest 16:9 box that fits the viewport, and what the viewport has left over goes black: side bars on an ultrawide, top and bottom bars on a phone, and on a 16:9 panel no bars at all. (At PHONE viewports the trade reverses and the letterbox is the wrong spend of the glass -- metaeden-v4-game-fit.css releases the lock there, inside the mode only. See the media-query note above for why that lives in its own file.) THE FILL NEVER ASKS THE API. These declarations are min() arithmetic over 100vw and 100vh, so the frame fills whatever viewport it is handed without being told -- an F11 pressed by the visitor, or the real element fullscreen the adapter now requests alongside, both just change what those units resolve against. Where the API is refused or absent (an iPhone, a pane whose policy forbids it), this block IS the whole mode, which is why it must stay deliverable on its own. ONE CONTROL ON THE SURFACE, INHERITED BY ALL THE CABINETS. Nothing below names a cartridge except the lines that say why they have to, and no engine file was touched. A new cabinet added by the recipe in metaeden-v4-game.js gets this for free the day it lands. THE FRAME IS THE ELEMENT THAT ALREADY EXISTS. #gframe wraps the control and #gstage in the markup and goes position:fixed here; the cartridge's own DOM is never moved, rebuilt or reparented, which is the whole of why a round in progress survives entering and leaving. A move would probably survive too (browser-frame.js moves every mounted cartridge into .browser-viewport on every page in the ring, and the games work), but not moving is free. position:fixed RESOLVES AGAINST THE VIEWPORT HERE, and that is checked, not assumed: a transform, filter, will-change or contain on any ancestor would make it resolve against that ancestor instead, and browser-frame.css declares none of the four. It matters because METScape pins body.browser-framed{min-width:1920px} and .browser-frame{width:1920px; height:1080px;overflow:hidden} -- the frame escapes all of that, including the overflow clip, because ancestor overflow does not clip a fixed descendant. (METScape's own picture is 1920x1080, which is the same shape this mode asks for. A coincidence, but a happy one.) ========================================================================== / / Out of the mode: a plain row above the stage, centred with the rest of the section rather than pinned to either edge. The control is the site's own .bbtn, which is the one control metaeden_net_v4_game_surface.test.js already measures in all four themes -- a new control would have been a new pair to measure for no gain. (One button on this strip since TASK-1143[Q]; the row layout never cared how many it held.) / .v4-game-page .gfsbar { display: flex; justify-content: center; gap: 8px; margin: 16px 0 0; } / THE TURN-YOUR-PHONE LINE IS OFF EVERYWHERE THIS FILE REACHES (TASK-1172[Q]). The in the control's bar exists for exactly one state -- the MOBILE fullscreen mode, upright, on a cartridge whose row declares `wide` -- and that state is the fit file's to paint (its .gfsm rules; this file carries no @media, see the long note above, so the orientation half could never live here). Hidden by default so a desktop, a screen reader on a desktop, and every out-of-mode phone view never meet it. No colour declared: where the fit file reveals it, it inherits the body ink on the bar's own borrowed plate, which is a pair the suite already measures. / .v4-game-page .grotate { display: none; } / THE WAY HOME IS OFF EVERYWHERE EXCEPT THE MODE (TASK-1212[Q]). Same shape as the line above, and for the same kind of reason. Out of the mode this page already carries seven links off it -- the mark, five nav tabs, "back to games" -- and every one of them is reachable; inside the mode #gframe goes fixed at z-index 300 over all seven and none of them is (measured, both devices, see the markup's own note). So the door exists exactly where the page would otherwise have none, and adding an eighth control to the row the phone has been fighting to keep short would be chrome for nothing. NO COLOUR DECLARED, which is this file's standing rule and here it costs nothing: the link is a .bbtn sitting on .gfsbar's own themed plate, so it wears the pair the suite already measures in all four themes. Only the phone needs a pair of its own, because over there it floats off the plate and over game art, and that pair lives in metaeden-v4-game-fit.css beside the close box and the rotate chip that already made the same trade. / .v4-game-page #ghome { display: none; } .v4-game-page.gfs #ghome { display: flex; } / IT IS NOT SHOWN IN BARE MODE, AND THAT IS THE CORRECTION (TASK-1488[Q]). TASK-1487[Q] lit it here because the bar was the only exit a popped-out window had. The user's answer to seeing it: "the pop out still has this grey bar that is no good, get rid of the grey bar when popped out." So the whole bar goes in that mode (see the rule further down) and the exit lives in a control row instead -- the cartridge's own where it declares one, the host's own where it does not. This link is still the paint that row's button borrows, which is why it stays in the markup rather than being deleted: metaeden-v4-game.js reads its computed ink when there is no cartridge button to read. A display:none element still computes a colour. / / TASK-1366[Q]: and pop out on the same gate, because this bar belongs to the FRAME. Outside the mode there is no frame to escape and the bar is a zero-height strip with nothing in it; a control here would have added 30px above the stage on every game page, in a mode nobody asked to leave. / .v4-game-page #gpopbtn { display: none; } .v4-game-page.gfs #gpopbtn { display: flex; } / THE PAGE'S OWN SCROLLBARS GO AWAY FOR THE DURATION, and this is load-bearing arithmetic rather than tidiness. vw and vh are defined against the initial containing block with scrollbars ASSUMED NOT TO EXIST, while a fixed element is laid out in the real viewport rect, which does not include them. METScape pins body.browser-framed{min-width:1920px}, so every viewport narrower than about 1935px has a horizontal scrollbar -- the normal case here, not an edge one -- and the frame was measured 15px taller than the space it had, centred, losing 7px off the top and the bottom. With no scrollbar the two agree exactly and the lock below is exact. It also stops a wheel at the end of the stage from scrolling a page nobody can see. / .v4-game-page.gfs { overflow: hidden; } / In widescreen. THE ASPECT LOCK IS THESE THREE DECLARATIONS. width and height each take the smaller of what the viewport allows and what the other axis implies, so the box is the largest 16:9 rectangle that fits and is centred by inset+margin. aspect-ratio says the same thing declaratively; it is what a reader sees first and what a browser without min()/calc() in this position would still honour. The suite computes the ratio these declarations produce at four viewports rather than trusting the words. / / TASK-1364[Q]: FULLSCREEN COVERS THE FAKE BROWSER, z-index 1006. The user: "when i full screen the minigame the browser frame still displays over it." It did, and the two halves had been disagreeing since this rule was written: it is position:fixed inset:0 at 100vw by 100vh, which means to cover EVERYTHING -- while browser-frame.css paints the METScape chrome at 1001 through 1005, and 300 loses to all five. So the top of every cartridge sat behind the toolbar and the location bar; it is barely visible on a canvas game whose art starts lower and unmissable on one with a toolbar at its own top edge, which is how it finally surfaced. 1006 IS CHOSEN, NOT PICKED. It clears the chrome by one and stays under every deliberate full-screen takeover on this site, all of which SHOULD still cover a game in fullscreen: the door at 1000002, the arcade cabinet and its backdrop at 1000000 and 1000001, and the boss key cover at 2147483647 -- the one thing entitled to sit above everything. It is scoped to .gfs, so leaving fullscreen hands the chrome back with no second rule to remember. The original note below is unchanged and still true; it just now describes something that happens. / / THE AUTOMATIC MINIMUM SIZE IS TURNED OFF BELOW, and it is the one pair of declarations in this block that a reader will take for redundant. It is not. The bug it answers is invisible on a monitor and was measured on a 360x800 phone (TASK-1136[Q]). A box with a preferred aspect-ratio and `overflow: visible` is given an automatic minimum size in the ratio-DEPENDENT axis: a browser will not make it smaller than its own min-content, so that honouring the ratio can never clip what is inside. Here the height is the definite one, so WIDTH is the dependent axis, and the frame's min-content is whatever the widest row of the mounted cartridge happens to be. Golf's 18-hole strip measures 403px. Above roughly 700px of viewport that minimum is never reached and the lock is exact, which is why this sat unseen for as long as METScape kept every visitor's page 1920px wide. At 360 it won outright: the frame came out 403x203, a ratio of 1.99 rather than 1.78, hanging 43px off the right of the screen with the control strip and the game following it out. Zero says "the ratio is the whole of the shape", which is what the three declarations under it already claim. Content that does not fit still scrolls inside #gstage, which is exactly what that rule's own overflow is for; the frame never needed to grow to hold it. THE HEADLESS PIN CANNOT SEE THIS, which is worth knowing before trusting it. frameBoxAt() in metaeden_net_v4_game_surface.test.js evaluates the width and height declarations at four viewports, 375x812 among them, and models the arithmetic only. An automatic minimum applied by the layout engine is not in the declarations, so that pin stayed green throughout. This shape is claimed in a parser and only ever true in a browser. / / TASK-1366[Q]: POPPED OUT -- the game and nothing else. Set on by an inline script that runs the moment the tag opens, rather than by anything that waits for load, so the furniture is never painted and then taken away. What is hidden here is the chrome ABOUT the game: the site header and nav, the marquee, the way back, and the bar carrying the control that opened this window, which in a window opened to escape the frame would be a door back into the room you just left. THE COLUMN IS FLATTENED, NOT JUST THE FRAME. This page is a centred 820px reading column inside a shell with margins of its own, and sizing only #gframe to the viewport gave a 2040px box starting at the column's left edge and running off the right of the screen -- the right size, in the wrong place, with the page scrolling to make room for it. Every ancestor between the game and the viewport gives up its width, margin and padding here. overflow:hidden is the other half of that: with the chrome gone the game is exactly one viewport tall, and a page that can still scroll a few pixels slides the game under the edge of the window on a trackpad. / .v4-game-page.gbare { margin: 0; background: #000000; overflow: hidden; } .v4-game-page.gbare .hd, .v4-game-page.gbare .ghead, .v4-game-page.gbare .gmarquee, .v4-game-page.gbare .gback, .v4-game-page.gbare .gnote, .v4-game-page.gbare footer { display: none; } / THE BAR GOES. ALL OF IT, AND WITHOUT WAITING FOR ANYTHING (TASK-1488[Q], round two). The user, with a screenshot of a popped-out Spam Clicker: "the pop out still has this grey bar that is no good, get rid of the grey bar when popped out." WHAT THEY WERE LOOKING AT, and why the first cut left it there. The bar used to go only once the exit had landed in the cartridge's own control row, and the host found that row by a marker two cartridges declared. Spam Clicker declares a control row -- SOUND / WIPE SAVE, the exact "same level as the Fullscreen, Sound : On buttons" the ask names -- and had never been given the marker, so the gate did what it was written to do and kept the bar. Nineteen other cabinets were in the same position. The gate was right and its reach was not. SO THE GUARANTEE MOVED INSTEAD OF WIDENING. It used to be a CSS gate: hide the bar only where .gexit says a replacement exists. It is now a property of metaeden-v4-game.js's syncExit, which in bare mode ALWAYS leaves a reachable exit -- in the cartridge's own row where one is declared and on screen, and in a host row of its own where none is. There is still no state with neither; what changed is that the fallback is one control on the game's own frame rather than a strip of page chrome carrying three. AND IT IS CSS RATHER THAN A CLASS THE ADAPTER ADDS, deliberately. This stylesheet is render-blocking and metaeden-v4-game.js is deferred, so a rule waiting on a class the adapter sets is a rule that paints the grey bar first and takes it away afterwards -- in front of whoever just opened the window, which is the failure the inline gbare script at the top of v4-game.html exists to avoid for the header and the marquee. The same reasoning, the same answer. POP OUT WENT WITH IT. Its own rule hid it here (it opens this same surface, so in this mode it reloads the window you are already in); with the bar gone there is nothing left for that rule to say. / .v4-game-page.gbare .gfsbar { display: none; } / THE HOST'S OWN ROW (TASK-1488[Q]) IS THE GAME MENU'S SYSTEM ROW NOW (TASK-1634[Q]). metaeden-v4-game.js builds .gexitrow in bare mode for the two controls this page owns -- Share Game Link w/Friend and Return To MetaEden.Net -- and it used to stand in the tray band, wearing one plate per theme borrowed from the fullscreen bar. It stands inside the game menu panel now, under the SYSTEM heading, and is dressed by the panel rules further down (search for "THE TITLE-SCREEN SYSTEM LAYER"). It has no plate of its own any more: the panel is the plate, in every theme, which is what lets a bare window drop the tray without dropping the way out. Its old layout rule and the four theme plates are gone rather than left matching nothing (recover from 24d6c217b). / / THE RESERVED ROW ALONG THE BOTTOM, AND WHY IT IS ONE ROW (TASK-1544[Q]). The user, with a screenshot of a popped-out Spam Clicker: "on pop-outs if we still have IMs, can we at least put them on a reserved row at the bottom so that it's not blocking/overlapping the content? move the content up a few pixels above the reserved row for IMs, make it look like a taskbar/tray." WHAT WAS OVERLAPPING. met-windows.js paints three taskbar controls at the corners of the real viewport at bottom:0 -- the minimized-chat chips on the left, METAMP and the "(N) Buddies Online | ME|T|List" button on the right. That placement is correct on metaeden.net and has its own paragraph over there: they are the DESK'S taskbar, and the desk is what the fake browser sits on. A popped-out game has no browser and no desk, so those three plates were simply standing on the game's own bottom row. IT TAKES ITS HEIGHT; IT DOES NOT COVER. #gframe is a flex column and #gstage is flex:1, so a band appended after the stage shortens the stage by exactly its own height and the browser does the arithmetic. That is the same in-flow answer .gexitrow gave the exit one ticket ago, applied to the rest of the furniture -- and it is why nothing here is positioned. A fixed band would be the bug wearing a plate. THE RETURN TAB WAS IN IT, AND IS NOT ANY MORE (TASK-1634[Q]). From TASK-1544[Q] to TASK-1632[Q] the band's right-hand end carried the host's own controls and the cartridge's relocated bank, so that the bottom of the window was one strip and not two. The user then asked for the bare page to read as a standalone title screen, which means NO strip at all by default: the tray is hidden until the visitor switches it on from the game menu, and every control that used to live in it lives in that menu instead (the panel rules further down). What the band carries when it is on is exactly the two met-windows.js ends -- chips and status controls -- plus the game's own tagline in the leftover space. ITS HEIGHT IS FIXED, not content-driven. A band that grew when a chip arrived would reflow the stage under a round already in progress, which is the fixed-frame rule this codebase states for every panel. 44px, sized to the tallest thing that docks into it, which is a met-windows.js chip (13px Tahoma in a bevelled plate, 30 tall), with the period taskbar's own breathing room around it. The exit used to be the tallest occupant (.bbtn came out at 40) and set this number; it left for the menu and the number stayed, because a 44px tray is the tray the user already signed off on and reflowing it for 10px is not a favour to anyone. met_popout_exit_contrast_rig.test.js measures the chip against this box. (Written without quoting the declaration: F6 in the sibling suite scans this file for type sizes and reads the prose as well as the rules, which is exactly the trap CLAUDE.md names.) THE PLATE IS THE FULLSCREEN BAR'S. Four lines and not one, the same H35 discipline, borrowed from the same twins -- so a theme recoloured over there moves both together and this file still invents no paint. The bevel is a box-shadow rather than a fifth set of theme colours: a raised top edge and a shaded bottom in translucent white and black read as a 1996 tray on all four plates at once, which is what met-windows.js's own chips already do for their shadow. OFF BY DEFAULT, AND DECIDED BEFORE ANYTHING PAINTS (TASK-1634[Q]). The band exists in every bare state (metaeden-v4-game.js still reserves it, so met-windows.js still finds its two ends and docks into them) but it is display:none unless carries .gtrayon. That class is put there by the inline script at the top of v4-game.html, which reads the per-browser preference (localStorage "met.bare.taskbar", "1" = shown) in the same breath as it reads ?bare=1 -- so a window that remembers the tray ON paints it on its first frame, and a window that does not never paints it at all. The same reasoning as the .gfsbar rule above: this sheet is render-blocking and the adapter is deferred, so a rule waiting on the adapter is a rule that flashes. The game menu's "Show taskbar" switch toggles the class and writes the preference; the tray then comes back IN FLOW under the stage, the stage shrinks by exactly the band's height, and nothing floats over the game. ...AND EVERY SURFACE THAT BELONGS TO THE TRAY GOES WITH IT. met-windows.js parents its chips into the band's ends, so those hide with the band. Its OPEN windows (#mwaway: the IMs, the buddy list, METAMP) and its tooltip are fixed to the viewport, and the friends door (.sgf-win) is a fixed window of its own, so each is named here and hidden on the same class. Switching the tray on shows all of them again exactly where they were. / .v4-game-page.gbare .gtray { flex: 0 0 auto; box-sizing: border-box; display: flex; align-items: center; gap: 6px; height: 44px; margin: 0; padding: 0 6px; box-shadow: inset 0 2px 0 rgba(255, 255, 255, 0.32), inset 0 -2px 0 rgba(0, 0, 0, 0.45); } .v4-game-page.gbare.grey .gtray { background: #cbcbcb; } .v4-game-page.gbare.dark .gtray { background: #000000; } .v4-game-page.gbare.neon .gtray { background: #0c0b07; } .v4-game-page.gbare.dxhr .gtray { background: #0d0b08; } .v4-game-page.gbare:not(.gtrayon) .gtray, .v4-game-page.gbare:not(.gtrayon) #mwaway, .v4-game-page.gbare:not(.gtrayon) #mwtip, .v4-game-page.gbare:not(.gtrayon) .sgf-win { display: none; } / THE TWO ENDS (TASK-1544[Q]). A tray has task buttons at one end and status controls at the other, and met-windows.js needs to be told which is which -- so the band carries two marked slots and that file addresses them by the marker rather than by knowing anything about this page. So the band is two flex children: [ tasks (chips + the game's tagline) ][ sys (METAMP + buddies + friends) ] THERE WAS A THIRD ZONE from TASK-1545[Q] to TASK-1632[Q]: the cartridge's relocated SOUND / WIPE bank, or the host's own exit row, at the right-hand end, flex:0 0 auto so the way out could never be squeezed. TASK-1634[Q] moved all of that into the game menu panel, and the zone went with it; there is no [data-met-controls] element in the band any more and no rule here for one. THE PRIORITY IS MEASURED, NOT GUESSED (TASK-1545[Q]). At common pop-out widths (640..1280) both ends fit; below that the chip end shrinks first (flex:1, its own ellipsis clips a long chat row) and the status end shrinks next (flex:0 1, the buddies label truncates -- met-windows.js carries the ellipsis rule for its own in-tray label). With nothing rigid left in the row it cannot overflow the glass at any width down to a phone's, which is what the fit sheet's 375px promise now rests on. Nothing wraps and nothing scrolls, so the band stays one fixed-height strip. / .v4-game-page.gbare .gtray-tasks { flex: 1 1 auto; min-width: 0; display: flex; align-items: center; overflow: hidden; } .v4-game-page.gbare .gtray-sys { / was flex:0 0 auto; it shrinks now so its label truncates before the controls end has to give up a pixel (TASK-1545[Q]). / flex: 0 1 auto; min-width: 0; display: flex; align-items: center; gap: 4px; overflow: hidden; } / THE GAME'S OWN TAGLINE, MOVED INTO THE TRAY'S LEFT (TASK-1547[Q]). metaeden-v4-game.js's relocateCaption drops the marked caption -- each cartridge's one-line help/tagline, e.g. .meta-vanish-boom-3d-help -- into the tasks zone, which is the dead LEFT space the user's arrow pointed at (the flex:1 grower that stands empty on a solo pop-out). This dresses it as period STATUS-BAR TEXT and gives it the LOWEST layout priority. LOWEST PRIORITY, MEASURED: flex:1 1 0 means the caption takes only the leftover space and contributes NOTHING to the tasks zone's natural width, so the band-level three-zone solve (TASK-1545[Q]) does not move and the controls zone still never shrinks. On overflow the basis-0 caption collapses to its ellipsis FIRST, before the interactive chips give up a pixel -- passive text yields to the chips, never overlaps them. min-width:0 + nowrap + ellipsis is the single-line truncation the taskbar idiom wants. ITS OWN GREY STATUS PLATE, NOT A BUTTON. The .gtray plate is grey only in the grey theme (near-black in the other three), so #000 ink read straight on it would vanish in dark/neon/dxhr. The caption therefore carries the same grey #c0c0c0 backing the buddies chip and the relocated controls wear -- so its #000 Tahoma is readable in ALL FOUR themes (about 11.5:1 on #c0c0c0) and the whole bar reads as one 1996 taskbar. It is a SUNKEN status field (an inset bevel), not a raised beveled button, which is what keeps it "status text" and not a chip. `background` shorthand, not `background-color`, and the only ink is #000 -- both accounted for in the surface suite's colour allowlist. SCOPED TO .gbare .gtray, so a FRAMED page (no tray) matches none of this and the caption stays a stage row styled by the cartridge's own .meta--help rule, byte-for-byte. WHY HERE AND NOT met-windows.js: that file injects its stylesheet only when it has a chip to show, and a solo pop-out has none -- this sheet is always loaded on v4-game.html (the TASK-1546[Q] trap). NOTE THAT THE TRAY IS OFF BY DEFAULT SINCE TASK-1634[Q], so the tagline is only on screen once a visitor switches the taskbar on. It still relocates on every bare pass, because the band it lands in is built on every bare pass; it is simply not painted until the band is. / .v4-game-page.gbare .gtray [data-met-cap] { flex: 1 1 0; min-width: 0; align-self: center; overflow: hidden; white-space: nowrap; text-overflow: ellipsis; margin: 0; padding: 3px 8px; background: #c0c0c0; color: #000; font: 12px Tahoma, Verdana, sans-serif; letter-spacing: normal; text-align: left; text-transform: none; box-shadow: inset 1px 1px 0 rgba(0, 0, 0, 0.4), inset -1px -1px 0 rgba(255, 255, 255, 0.55); } / THE TRAY USED TO DRESS A RELOCATED CONTROL BANK AS ITS OWN GREY CHIP (TASK-1546[Q]). No control docks in the band any more (TASK-1634[Q] moved the cartridge bank and the host's two controls into the game menu), so those rules are gone rather than left matching nothing (recover from 24d6c217b; living_docs/CODE-DELETIONS.md has the row); the panel rules further down are what a relocated control wears now. / / ...AND THE INK IT WEARS IS THE ROW'S, WHICH TOOK A SPECIFICITY FIGHT TO SAY (TASK-1488[Q]). The exit copies the class off the button beside it, and that was enough for everything EXCEPT the colour: the exit is an and its neighbours are