laywill / laywill/laywill.github.io
Banner and spotlight stack to the mobile layout on any portrait viewport, however wide
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 0
- Forks
- 0
- Avg merge
- 8h 17m
- Merged PRs (30d)
- 58
Description
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:
- Leave it. Portrait-window desktop users are rare, the fallback layout is usable, and the vendor source stays clean.
- Add a width ceiling to the bare portrait rules. A mixin change in
_banner.scssand_spotlight.scss, one committedmain.cssrebuild. Changes live behaviour for tablets in portrait, which currently get the stacked layout by the same rule and arguably want it. - 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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read assets/sass/components/_banner.scss and _spotlight.scss alongside assets/sass/libs/_skel.scss:205 to trace the bare portrait queries, then inspect the compiled blocks in assets/css/main.css. Run check-render.mjs at the documented desktop and mobile sizes plus portrait desktop or tablet sizes. Done means the project has a decided viewport policy, matching source and rebuilt CSS, and verified layouts at the affected sizes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css, sass
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100