Part of #734, found by measuring the layout restructure (#774) against Jahia/jahia.com's footer.
DEFAULT_BREAKPOINTS starts at 320. A slot smaller than that gets no candidate near its size, and the sizes-derived ladder cannot help: its floor comes from the string, but the list it filters has nothing below 320.
Measured on the two footer logos (max-height: 4rem and 7rem, width following the aspect ratio), intrinsic 1800x600 for a 3:1 wordmark:
| slot |
before |
served |
after |
served |
| 4rem, 3:1 wordmark |
[64,128] |
0.33x |
[64,128,256,512,1024,1536,1800] |
1.33x |
| 7rem, 3:1 wordmark |
[112,224] |
0.33x |
[64,128,256,512,1024,1536,1800] |
1.52x |
| 4rem, square logo |
[64,128] |
1.00x |
[64,128,256,512,1024] |
1.00x |
The restructure fixed the under-serving (0.33x meant the browser was upscaling a too-small file) by turning it into over-downloading. Both are wrong, and the site only reaches a sane ladder at all because it now passes an explicit breakpoints={[64,128,256,512,1024,1536]} — which is a per-call-site workaround for a platform default.
Two things to decide:
Related: the sizes-to-ladder parser shipped with the restructure has a narrowing path that neither adoption exercises — every explicit sizes in luxe and jahia.com contains a near-100vw entry, so every one resolves to the whole ladder. The narrowing is unit-tested but has no real-world call site yet, so its value is unproven.
Part of #734, found by measuring the layout restructure (#774) against Jahia/jahia.com's footer.
DEFAULT_BREAKPOINTSstarts at 320. A slot smaller than that gets no candidate near its size, and thesizes-derived ladder cannot help: its floor comes from the string, but the list it filters has nothing below 320.Measured on the two footer logos (
max-height: 4remand7rem, width following the aspect ratio), intrinsic 1800x600 for a 3:1 wordmark:[64,128][64,128,256,512,1024,1536,1800][112,224][64,128,256,512,1024,1536,1800][64,128][64,128,256,512,1024]The restructure fixed the under-serving (0.33x meant the browser was upscaling a too-small file) by turning it into over-downloading. Both are wrong, and the site only reaches a sane ladder at all because it now passes an explicit
breakpoints={[64,128,256,512,1024,1536]}— which is a per-call-site workaround for a platform default.Two things to decide:
DEFAULT_BREAKPOINTSdownward, or derive extra candidates below the first breakpoint when thesizesfloor is well under it. A logo, an avatar and an icon are common enough that every project should not have to discoverbreakpoints.sizes="auto"whose ceiling is the widest breakpoint, while the real slot is bounded by height. The guide currently sends a height-constrained slot tosizes="auto"with a caveat about precision, and does not warn that the ladder will reach for the largest file. At minimum say so; better, let the caller state a maximum without also claiming aslotWidth.Related: the
sizes-to-ladder parser shipped with the restructure has a narrowing path that neither adoption exercises — every explicitsizesin luxe and jahia.com contains a near-100vw entry, so every one resolves to the whole ladder. The narrowing is unit-tested but has no real-world call site yet, so its value is unproven.