OK, I've re-worked my proposal a bit from the feedback I've received,
and I'll submit to w3.org public-html-comments. Here's my revised
proposal:
Seeking feedback for my (hopefully relatively painless in practice
compared to the alternatives - i.e. -webkit-image-set and html5
<image>) proposal to solve the problem of 2x-res (double-resolution)
images with our current HTML and CSS standards for devices with high-
resolution displays, such as 3rd Generation iPads and 4th generation
iPhones and newer.
We add the following elements:
1) The new 'meta' attribute 'image-scaling' with arguments listed in
the format {'scaling factor', 'scaling filename key'}, where the
filename key is the often-standardized string added to the filename
for 2x assets, i.e. '_2x' (it might even be possible to specify a
different filename extension for the 2x asset by detecting whether the
'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-
attributes to the 'image-scaling' attribute would include the optional
boolean (defaulted to 'true') attribute 'assume-present', and
potentially the optional attribute 'image-scaling-path' for cases
where sites store their various scaled image assets in different
directories than their 1x images.
2) A new series of optional attributes to the img tag named after the
scaling factor, i.e. '2x', '4x', etc., (possible values include
'true', 'false', a string for the double-res filename key, or 'url()'
to specify a completely different path for the asset corresponding to
that scaling factor)
3) A series of new optional CSS properties named after the scaling
factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-
image-2x' (possible values for these include 'true', 'false', a string
for the double-res filename key, or 'url()').
A simple example usage of these new capabilities would be the following:
<meta image-scaling="{2,'_2x'}" />
The effect of adding this single line to the page would be that a user
agent that wishes to display double-res images would then attempt to
access 'filename_2x.ext' whenever it encounters an img tag like '<img
url=("filename.ext") />', or a CSS property like '.class {background-
image: url("filename.ext");}', '.class {border-image:
url("filename.ext");}' or '.class {list-style-image:
url("filename.ext");}'. For all these, in the case that the
'filename_2x.ext' file does not exist, a second request is made for
'filename.ext'.
If the bulk of the 2x-resolution images are located in a different
directory than the 1x assets, the meta tag could be extended as such:
<meta image-scaling="{2,'_2x'}" image-scaling-path="{2,'2x_images/'}" />
Then, any 2x img or css-image assets would be requested from
'2x_images/filename_2x.ext' instead of 'images/filename.ext'.
If a particular 2x img tag asset or css-image asset has a '@2x' double-
resolution filename key instead of '_2x' for some reason (maybe you're
integrating with some 3rd party off-site content with a different 2x
naming convention), you could add a '2x' attribute to its img tag,
such as '<img 2x="@2x" />', or to its css properties, such as '.class
{background-image-2x: "@2x";}'.
If a particular 2x-resolution img tag asset or css-image asset is not
located in the same directory as the 1x asset, or if the filenames and/
or file formats are not identical to the 1x asset, a separate path
could be specified by doing this: '<img 2x=url("path/to/
filena...@2x.ext") />', or to its css properties by doing: '.class
{background-image-2x: url("path/to/filena...@2x.ext");}'.
In the case that a majority, but not all img and css-image assets are
available in 2x resolution, the img assets that lack a 2x version
would include the a tag such as, '<img 2x=false />, or a css property
such as '.class{background-image-2x: false;}'.
In the case that a majority, but not all img and css-image assets are
unavailable in 2x resolution, you would add the 'assume-
present="{2,false}' attribute to the meta 'image-scaling' attribute,
such as '<meta image-scaling="{2,'_2x'}" assume-present="{2,false}" /
>', and use the '2x' attribute to flag img assets with a double-
resolution asset available, such as '<img 2x=true />, and the css with
'.class {background-image-2x: true;}'.
In the case that no double-resolution image assets are available, the
meta 'image-scaling' attribute can be simply omitted.
By using this approach, we avoid the need to specify the same list of
filenames varying only by scaling factor filename key for every single
image asset, which is a bunch of busy work that just seems extremely
redundant and clumsy to me. We are also able to achieve the same level
of performance for those willing to put in the extra work to flag
assets that deviate from the default setting (to minimize requests),
and we allow the flexibility to be lazy or wrong, and have the user
agent make two requests in those cases. This solution is also
completely backwards-compatible with existing browsers. We can revisit
whether or not this was really the best approach once 4x displays are
out, but it's going to save millions of collective developer-hours in
the meantime; remind me to buy future me a beer to make up for it.
As a corollary to this, a similar approach could be used to add
support for different image formats without losing backwards-
compatibility, and again saving many precious developer-years. Imagine
<meta image-formats="{jpeg2000, '.jp2'}" assume-
present="{jpeg2000,boolean}" />
-Tom Penzer
On Apr 23, 2012, at 11:30 PM, Maciej Stachowiak wrote:
It would be more readable to use:
@media screen and (min-device-pixel-ratio: 2) { … }
The -webkit-image-set proposal explains why it is a useful shorthand
despite the existing device pixel ratio option.
Regards,
Maciej
On Apr 23, 2012, at 11:11 PM, Eric Seidel wrote:
Assuming I'm understanding Kalle correctly, it seems this could
already be accomplished with @media resolution?
http://www.w3.org/TR/css3-mediaqueries/#resolution
@media screen and (min-resolution: 264dpi) { … }
Which according to:
http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
Would match both the new iPad and the iPhone 4.
I don't know if webkit supports "resolution" in media queries yet?
On Mon, Apr 23, 2012 at 9:28 PM, Kalle Vahlman <kalle.vahl...@gmail.com
> wrote:
2012/4/24 Tom Penzer <tpen...@mailcan.com>:
Hi Everybody!
As a first-time poster, I am sorry ahead of time for any
lapses in
etiquette. I am seeking feedback for my (hopefully relatively
painless in
practice compared to the alternatives - i.e. -webkit-image-set
and html5
<image>) proposal to solve the problem of 2x-res (double-
resolution) images
with our current HTML and CSS standards for devices with high-
resolution
displays, such as 3rd Generation iPads and 4th generation iPhones
and newer.
This seems like a perfect use-case for the @media rule of CSS,
does it not?
It's obviously not up-to-date in its definition (eg. handheld
devices
are not "typically small screen, limited bandwidth" anymore), but on
the other hand it allows undefined types as well so nothing prevents
implementers to extend it beforehand (like is done with most CSS
properties anyway).
--
Kalle Vahlman, z...@iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
