/**
 * EmulatorJS canvas sizing.
 *
 * Its own path, not an edit inside frontend.css: LiteSpeed derives a minified
 * sheet's hashed URL from the source *path*, and that URL is served
 * max-age=1yr, so an edit to frontend.css can take a year to reach a returning
 * visitor. See the header of embed-fit-20260824.css.
 *
 * The bug: frontend.css forces `width:auto !important; height:auto !important`
 * on `#game canvas` (a rule written for the js-dos / javatari players, which
 * size their own canvas). EmulatorJS does the opposite - it ships
 * `.ejs_canvas{width:100%;height:100%}` and then sets the drawing buffer from
 * the canvas's *client* size. With width:auto that client size is the intrinsic
 * 300x150 default, so the buffer is set to 300x150, which keeps the client size
 * at 300x150: the loop never grows. Every EmulatorJS game therefore rendered in
 * a 300x150 postage stamp in the middle of an 818x610 player - every console
 * except MSX (WebMSX) and DOS (js-dos), whose canvases are not .ejs_canvas.
 *
 * Scoped to `canvas.ejs_canvas` so those two keep the intrinsic sizing they need.
 */
#game canvas.ejs_canvas,
.rg-player-body canvas.ejs_canvas,
.ejs_canvas_parent canvas.ejs_canvas {
    width: 100% !important;
    height: 100% !important;
    max-width: 100% !important;
    max-height: 100% !important;
    object-fit: contain !important;
    display: block !important;
    margin: 0 !important;
}