On Sun, 13 May 2012 20:55:08 +0100, Bjartur Thorlacius
<svartma...@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
