4 ms·
Random thought—would it perhaps make sense to do this server side? You could pre-calculate the optimal width at a bunch of different viewports, and send that to
by Wowfunhappy 5y ago
Random thought—would it perhaps make sense to do this server side? You could pre-calculate the optimal width at a bunch of different viewports, and send that to the client.
You could generate a stylesheet with a stupid amount of generated breakpoints, or you could assume the user isn't going to resize the browser after loading the page. (Most won't, and if they do, the only consequence is non-ideal text wrapping).
- somebodythere 5y agoDoes the server get the viewport size as part of the request? The second problem is solvable though I think, by loading the JS text balancer asynchronously.
- Wowfunhappy 5y ago> Does the server get the viewport size as part of the request? ...oh, uh, no, that was dumb of me. I do still wonder though if auto-generating a css file with lots of media queries would be feasible.
- somebodythere 5y agoSure, you only need tens of breakpoints setting one style rule each. Gzipped I bet it would weigh about as much as the JS text-wrapper implementation.
- Wowfunhappy 5y agoIt should be lighter on CPU though, and avoid a FOUC.
- d2wa 5y ago> Does the server get the viewport size as part of the request? It can, yes. The response header `Accept-CH: Viewport-Width` suggest to the client that future request should transmit a `Viewport-Width: 320` header. Chrome only as the other browsers consider it harmful. It doesn’t solve the problem, though. Font availability and subpixel rendering varies from OS to OS and browser to browser.