Banner and spotlight stack to the mobile layout on any portrait viewport, however wide

Lee assets/sass/components/_banner.scss y _spotlight.scss junto con assets/sass/libs/_skel.scss:205 para rastrear las consultas de portrait sin calificar; después, inspecciona los bloques compilados en assets/css/main.css. Ejecuta check-render.mjs con los tamaños de desktop y mobile documentados, además de los tamaños de desktop o tablet en portrait. Se considera terminado cuando el proyecto tiene una política de viewport decidida, CSS fuente y recompilado coherentes, y layouts verificados en los tamaños afectados.

Found while documenting the headless-screenshot traps for #175. That issue is about the capture tooling lying; this one is about the CSS underneath it, which turns out to be reachable from a real browser window.

What happens

.banner and .spotlight switch to the stacked mobile layout (flex-direction: column-reverse, centred text, image at 45vh) on any portrait viewport, with no width condition at all. Twelve of the fourteen compiled portrait blocks in assets/css/main.css are bare:

@media screen and (orientation: portrait) { ... }

They come from @include orientation(portrait) at the .banner / .spotlight top level in assets/sass/components/_banner.scss and _spotlight.scss, i.e. outside any breakpoint() block. Only the two nested inside breakpoint(small) compile with a width condition (main.css:4034, main.css:4058).

skel's mixin (assets/sass/libs/_skel.scss:205) emits the orientation query and nothing else, so "portrait" here means height exceeds width, full stop.

It is reachable without a phone

Rendered index.html in headless Chrome, scripts stripped and opacity forced, at two desktop-class sizes:

• 1440x900: the intended side-by-side banner, text left, portrait photo right.
• 1280x1440: the stacked layout. Photo on top, centred text below, most of the width unused.

1280x1440 is not contrived. It is a half-width window on a 2560x1440 monitor, and a portrait-rotated 1440p display is 1440x2560. Both get the phone layout on a screen with plenty of horizontal room.

Not a rendering fault

The stacked layout isn't broken or distorted, it just isn't the desktop design. check-render.mjs pins 1440x900 and 375x812, so CI never sees it and has nothing to fail on. The behaviour is HTML5 UP's original Story template, unmodified since the template import, so changing it means deliberately diverging from vendor source.

Decision needed

Whether to keep vendor behaviour or gate the bare portrait rules on width, e.g. adding and (max-width: 980px) so orientation only matters on viewports that are actually small. Options:

1. Leave it. Portrait-window desktop users are rare, the fallback layout is usable, and the vendor source stays clean.
2. Add a width ceiling to the bare portrait rules. A mixin change in _banner.scss and _spotlight.scss, one committed main.css rebuild. Changes live behaviour for tablets in portrait, which currently get the stacked layout by the same rule and arguably want it.
3. Add a width ceiling and pick the breakpoint by testing what tablet sizes should keep stacking.

Option 2 or 3 needs a call on which viewports should stack. Tagging needs-william for that.