Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#180 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
css, sass
Ambito
frontend

Direzione di ricerca

Leggi assets/sass/components/_banner.scss e _spotlight.scss insieme a assets/sass/libs/_skel.scss:205 per tracciare le query portrait non qualificate, quindi esamina i blocchi compilati in assets/css/main.css. Esegui check-render.mjs alle dimensioni desktop e mobile documentate, oltre che alle dimensioni desktop o tablet in portrait. Il lavoro è completato quando il progetto ha una policy del viewport definita, CSS sorgente e ricostruito corrispondenti e layout verificati alle dimensioni interessate.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

design needs-william

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.

Lingua principale
HTML
Stelle
0
Fork
0
Merge medio
9h 52m
PR unite (30g)
59

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di laywill/laywill.github.io

Tutte le issue di laywill/laywill.github.io

Issue simili

Altre issue su Web Dev

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.