A cookie set in the head of a document would be ready in time for the parsing of the document’s body, and included along with image requests. We eventually settled on setting the screen size in a cookie. The server needs to know the client’s screen size before our images are displayed. Here’s where we run up against a major challenge: we need to communicate this size to the server in time to defer the request for the image’s original src, if necessary. Fortunately, there’s a relatively simple way to determine a device’s screen size through JavaScript by way of a property in the browsers’ window object:, though even that isn’t entirely reliable. To do that we need to know the size of the user’s screen. Now that we have both sources in our markup, we need a way to conditionally load the appropriate source. We store the path to the larger image in a data attribute for easy access via JS: With that as our basis, we’re ensuring that we default to a mobile-sized image. We started with, perhaps unsurprisingly, an image tag: There are three key components to our responsive images script: the markup, the JavaScript, and a server-side redirect rule. With a mobile-first approach, if any part of the process should break down the user should still receive a representative image-even if it’s a bit smaller-and avoid an unnecessarily large request on a device that may have limited bandwidth. We began with the core philosophy that the technique should err on the side of mobile. Scott Jehl brilliantly masterminded Filament Group’s “responsive images” technique. Before I describe it here, I should really warn you up front: it broke. While we were working on the new Boston Globe website, we devised a technique to mitigate the size of requests for users that may have limited bandwidth. What we can determine with some reliability is the size of a device’s screen-and while we can’t necessarily use screen size to make assumptions about bandwidth, it does directly correlate to what we’re trying to accomplish: while a browser’s window size may change, we’ll never need an image larger than the user’s screen. Testing would likely mean introducing a significant download to measure against, which is a lot like setting something on fire to see exactly how flammable it is. Unfortunately, we can’t test bandwidth in any reliable way-not yet, at least. A handful of full-bleed images designed for a 13” display could bring a mobile device on an Edge connection to its knees. At worst, the mobile browser stuffs its hands in its pockets and goes to sulk in the corner, leaving the page partially rendered. To use this effectively, though, the image must be large enough to scale up to whatever size we can reasonably expect on the largest possible display. It’s easy enough to style images so that they scale to fit within a parent container by adding img to one’s stylesheet. 3 days of design, code, and content for web & UX designers & devs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |