[whatwg] Implementation complexity with elements vs an attribute (responsive images)
kornel at geekhood.net
Sun May 13 14:08:58 PDT 2012
On Sun, 13 May 2012 20:55:08 +0100, Bjartur Thorlacius
<svartman95 at 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
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
2. Connection changes to slower one.
3. User visits the page again. HTML was non-cacheable, but images were
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
>> 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
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
>> 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.
>> 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
regards, Kornel Lesiński
More information about the whatwg