/* ========================================================================== 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; } / 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 .gfsbar, .v4-game-page.gbare .gback, .v4-game-page.gbare .gnote, .v4-game-page.gbare footer { display: none; } .v4-game-page.gbare .shell, .v4-game-page.gbare .page.gplay { width: 100%; max-width: none; margin: 0; padding: 0; } .v4-game-page.gbare #gframe { width: 100vw; height: 100vh; height: 100dvh; max-width: none; aspect-ratio: auto; margin: 0; / What every cartridge sizes its canvas against. Left at the inline default a popped-out window is a full-viewport frame with a 461px game sitting in the corner of it. / --gfs-h: 100vh; --gfs-h: 100dvh; } .v4-game-page.gbare [data-metaeden-wud], .v4-game-page.gbare [data-metaeden-wud] #wudRoot { height: 100%; } .v4-game-page.gfs #gframe { position: fixed; inset: 0; z-index: 1006; display: flex; flex-direction: column; width: min(100vw, calc(100vh 16 / 9)); height: min(100vh, calc(100vw * 9 / 16)); aspect-ratio: 16 / 9; min-width: 0; min-height: 0; margin: auto; background: #000000; --gfs-h: min(100vh, calc(100vw * 9 / 16)); } /* WHERE THE MONITOR HALF USED TO BE (TASK-1134[Q], removed by TASK-1158[Q]). Two rules stood here, `#gframe:fullscreen` and its `::backdrop`, and they existed for one reason: the adapter used to ask the browser to make #gframe a real fullscreen element, and the user-agent stylesheet hands such an element `width:100%;height:100%`, which would have stretched the frame to the SCREEN's aspect and lost the 16:9 this mode is about. They repeated the lock at a selector that outranked it. THE USER TOOK THE API BACK OUT, and these went with it: "I don't want to use the browser's real full screen mode, I want to leave it up to the user to trigger that from their own/actual browser software." Nothing on this page calls requestFullscreen any more, so #gframe can never match :fullscreen, and a rule that can never match is a rule that sends its next reader looking for the code that would trigger it. Deleted rather than left as a comment with braces. WHAT COVERS THE CASE ANYWAY, and why nothing was lost: F11 (or the browser's own menu) fullscreens the DOCUMENT, not an element, so no :fullscreen selector was ever involved in that path. All the mode is made of is min() arithmetic over 100vw and 100vh, and those simply resolve against whatever viewport the browser hands the page -- so a visitor who reaches for their own browser's fullscreen gets the mode at the new size for free, which is exactly the arrangement the user asked for. metaeden-v4-game-fit.css lost its own matching :fullscreen release for the same reason on the same ticket. / / THE LETTERBOX BARS. One pseudo-element, fixed over the whole viewport, painted behind the frame inside the frame's own stacking context -- so it covers the page, the METScape chrome and the CRT wash (body::after, z-index 200 in metaeden-v4.css) while the frame itself stays on top of it. THE WASH DOES NOT PAINT INSIDE WIDESCREEN, and that is a decision rather than a side effect. It is a CRT effect over the SITE's chrome, and this is the moment the site's chrome goes away; it also drops a dark lattice over a game's own pixels, which is the one place on this surface where nobody has measured anything. It is covered rather than switched off, which is why it comes back the instant the mode does: nothing about the visitor's own CRT setting is touched, and the frame simply sits on top of it. / .v4-game-page.gfs #gframe::before { content: ""; position: fixed; inset: 0; z-index: -1; background: #000000; } / THE CONTROL RIDES THE MARQUEE (TASK-1163[Q]). The user: "remove the 'leave full screen' bar and build it into the 'Now playing' bar instead (preferably on the right side of the screen)." So the strip that stood here is gone as a ROW: the control goes out of flow and sits in a gap the banner reserves for it down its right edge, and the ~46px the row was spending goes to the game. READ THE PARAGRAPH THIS REPLACED BEFORE MOVING IT AGAIN, because it warned against exactly this shape and it was right about the thing it measured. Floating the control at top:10;right:10 put it over the STAGE, where it landed on .meta-golf-top -- golf right-aligns its live readout there, so the mode cost the player the hole, the par, the strokes and the total, and minesweeper and solitaire put counters in the same corner. The conclusion drawn from that was "there is no corner of a nine-cabinet surface that is reliably empty", and it still holds: no corner of the STAGE is. What changed is that there is now something else to sit on. The marquee is CHROME, not a cartridge -- this file owns its padding, no engine draws in it, and it is blank down the right by construction -- so a control parked there cannot cover a readout in any cabinet, present or future. The old warning is about the stage; it is not a warning about the banner. THIS IS THE ARCADE PAGE'S OWN ARRANGEMENT, not a new one. Over there .meta-arcade-modal-close is a sibling of .meta-arcade-play-marquee, absolutely positioned at top:12px;right:12px over the 112px the banner's own padding holds open for it (metaeden.css). .gfsbar has been that sibling all along, so the whole change here is to reserve the gap this page had been zeroing out and put the control in it. The inset below is the arcade's, to the pixel. THE RESERVATION IS WIDER THAN THE ARCADE'S because the label is: "Close" fits 112px and "leave fullscreen" measures 156px at .bbtn's 24px type, 180px with the plate's own padding and 192px with the inset. 200px clears it without crowding the title, which keeps its minmax(0, 1fr) column and simply gets less of the row. IT STAYS A SIBLING, AND THAT IS THE ACCESSIBILITY POINT. The banner is aria-hidden -- it is a second RENDERING of the page's own
, so a screen reader should meet the title once -- and a focusable control inside an aria-hidden subtree is a control a keyboard can reach and a screen reader cannot name. Positioning it over the banner puts it in the same place on the glass while leaving it outside that subtree entirely, so it stays a real, focusable, announced