Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

On Sun, 13 May 2012 20:55:08 +0100, Bjartur Thorlacius  
<svartman95@gmail.com> wrote:

> The problem with that, though, is that then bandwidth constraints
> can't affect layout. Users should be able to configure UAs to use
> downsized images even given a large viewport, if only to save
> bandwidth and reserve a larger fraction of the viewport for text
> columns.

That wasn't my assumption.

For optimisation case expected images to vary only in compression strength  
or DPI (low-res JPEG or 2x image for Retina display), but never in their  
dimension in CSS pixels.


I think page should not be allowed to change layout based on bandwidth  
availability, because of browser caches. Imagine scenario:

1. User visits page on high-bandwidth connection and UA caches some high  
quality images.
2. Connection changes to slower one.
3. User visits the page again. HTML was non-cacheable, but images were  
cacheable.

Now the page may have mix of high-bandwidth and low-bandwidth content.  
It's entirely possible to have mixed quality with images if they have same  
CSS pixel size (and use of higher quality images whenever possible is  
desirable), but a page cannot contain mix of multiple different layouts at  
the same time.

If bandwidth was a media query, then entire page may have to be downgraded  
to low-bandwidth version even if UA had a lot of high-bandwidth content  
cached.

>> Adaptation of images to the layout is page-specific. Adaptation of  
>> images to bandwidth/screen is UA/device-specific.
>>
> Quite. But the latter just might affect the layout.

I think optimisation case should be forbidden from affecting the layout.

>> Author is in the best position to adapt image to page layout. User-agent
>> is in the best position to determine speed/quality trade-offs.
>>
> But low-res images usually don't look too good when upscaled. Thus few
> pixels should mean small image, UAs mustn't default to pixelation.

I don't understand why UA would "default to pixelation"?

The whole point of declaring available image versions is giving UA  
possibility to default to whatever it deems best.

When user is on GPRS or roaming connection then pixelation is a great  
outcome compared to not being able to download images at all due to  
prohibitive size/price.

When user is on broadband connection then UA can select high resolution  
images and avoid pixelation when network/hardware allows it.

And when image properties are specified declaratively, a smart UA can even  
do a mix of both, e.g. download pixelated images on mobile connections and  
give user option to selectively download higher-res images, or download  
low-res first for fast initial display and then download high-res in the  
background.

>> Media queries MUST be interpreted exactly as author specified them.
> Thus we mustn't force UAs to pretend to render to small viewports to
> find low-res images. That would have unwieldy side-effects.

Indeed!

>> User-agents need freedom to choose image resolution based on open set of
>> factors, many of which are details authors should not have to think  
>> about (presence in cache, cost of bandwidth, available memory, external
>> displays, etc.)
>>
> But the chosen image resolution might be a factor for choosing layout.

By resolution I mean pixel density (regular vs "Retina" display), so this  
doesn't affect layout.


I can imagine layout complexity being tied to bandwidth (an image-rich  
design vs minimalistic text-only design), but I'm not sure how that would  
work in practice given that cache has "infinite" bandwidth, and network  
speed can change any second on mobile connections.

It would be weird if page design changed when you moved between cell  
towers or left/entered a cafe that had public WiFi. And if bandwidth media  
query was defined to be fixed, then you'd sometimes end up stuck with  
wrong design that was chosen based on a temporary network state.

There is no such problem if only same-CSS-pixel-size images are swapped  
in-place.

-- 
regards, Kornel Lesiński

Received on Sunday, 13 May 2012 21:09:41 UTC