Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
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
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Hi there,
On Tue, Apr 24, 2012 at 11:48 PM, Edward O'Connor eocon...@apple.com wrote:
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.
As far as the resolution media query is concerned, the resolution of the
new iPad and the iPhone 4 (and anything else with a device-pixel-ratio
of 2) is exactly 192dpi.
This is because the CSS 'dpi' unit is defined to mean dots device pixels
per *CSS inch*, and CSS inches are hardcoded to be 96 CSS pixels.
This means that—without real physical units—the resolution media query
is always redundnant with device-pixel-ratio, which a) we already
implement, and b) is easier to explain to authors than explaining why
both the new iPad and the iPhone 4 are 192 dpi.
So the original iPhone has a dpi of 163, but it reported a CSS dpi of
96? meaning that in screen width it had around 3,3 CSS inches where as
the physical inches are more close to 1.96.
Why is this? Because the original iPhone reported an unchanged dpi of
96 even though it was in reality 163 and now everyone are depending on
that?
Kenneth
--
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone +45 4093 0598 / E-mail kenneth at webkit.org
http://codeposts.blogspot.com ﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On Wed, Apr 25, 2012 at 3:22 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: So the original iPhone has a dpi of 163, but it reported a CSS dpi of 96? meaning that in screen width it had around 3,3 CSS inches where as the physical inches are more close to 1.96. Why is this? Because the original iPhone reported an unchanged dpi of 96 even though it was in reality 163 and now everyone are depending on that? CSS defines one inch = 96px, because doing otherwise broke content (even pre-iOS content). http://www.w3.org/TR/css3-values/#absolute-lengths ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Assuming I'm understanding Kalle correctly, it seems this could already be accomplished with @media resolution? http://www.w3.org/TR/css3-mediaqueries/#resolution Not to be too cute about it, but CSS dpi is _always_ 96 CSS pixels per CSS inch. What this means onscreen is (almost) completely up to the user-agent. This is (potentially) why the resolution media query is defined (via the very link above) to only work for bitmap media types, not screen. Dealing with hardware that has a screen dpi much higher than what CSS prescribes for a device at its viewing distance (viewing distance matters: http://www.w3.org/TR/css3-values/#reference-pixel ) is a hard problem, and is one that is being discussed at length on the previously-mentioned threads and elsewhere. The iPhone seems to handle it by introducing a third type of pixels between hardware and CSS (a device/density-independent-pixel, or dip) that allows them to pretend that even the new iPhone has only 320px of width in portrait. BlackBerry has done other things at various times, currently taking advantage of dpi scaling (a little of which you can see in BlackBerry::WebKit::WebPagePrivate::recomputeVirtualViewportFromViewportArguments ). Android and Chrome-for-Android also have congruent practices, even exposing some of it to authors using target-densitydpi. Using HTML attributes and CSS properties to offload the effort of supporting multiple densities to the author from the user-agent might be the best way to solve this problem. I'm not as conversant in all the points as I feel I'd need to be to render a full opinion, but my uneducated opinion is that this sounds kinda hackish. Regardless, this indeed seems like it should be discussed by the standards bodies, not webkit-dev. Style, Chris H-C - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Thanks Chris, I'll go bring it up on the relevant w3.org lists (I'm guessing I'll start on public-HTML-comments) and see where that takes me, after refining my idea a bit to use more conventional naming, and to hopefully account for other scales than 2x in an elegant manner. I just wanted to make sure no one here told me don't bother, we've got superior solution x in the works, or due to y, that's not gonna fly! Surely, 2x images can be implemented in a sane and efficient manner for web developers. -Tom On Apr 25, 2012, at 10:23 AM, Chris Hutten-Czapski chut...@rim.com 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 Not to be too cute about it, but CSS dpi is _always_ 96 CSS pixels per CSS inch. What this means onscreen is (almost) completely up to the user-agent. This is (potentially) why the resolution media query is defined (via the very link above) to only work for bitmap media types, not screen. Dealing with hardware that has a screen dpi much higher than what CSS prescribes for a device at its viewing distance (viewing distance matters: http://www.w3.org/TR/css3-values/#reference-pixel ) is a hard problem, and is one that is being discussed at length on the previously-mentioned threads and elsewhere. The iPhone seems to handle it by introducing a third type of pixels between hardware and CSS (a device/density-independent-pixel, or dip) that allows them to pretend that even the new iPhone has only 320px of width in portrait. BlackBerry has done other things at various times, currently taking advantage of dpi scaling (a little of which you can see in BlackBerry::WebKit::WebPagePrivate::recomputeVirtualViewportFromViewportArguments ). Android and Chrome-for-Android also have congruent practices, even exposing some of it to authors using target-densitydpi. Using HTML attributes and CSS properties to offload the effort of supporting multiple densities to the author from the user-agent might be the best way to solve this problem. I'm not as conversant in all the points as I feel I'd need to be to render a full opinion, but my uneducated opinion is that this sounds kinda hackish. Regardless, this indeed seems like it should be discussed by the standards bodies, not webkit-dev. Style, Chris H-C - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On Wednesday 25 April 2012, Chris Hutten-Czapski 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 Not to be too cute about it, but CSS dpi is _always_ 96 CSS pixels per CSS inch. Well always now, historically it has been different. Anyway to continue your description CSS pixels have usually been 1-1 with device pixels on the desktop, except for printing where CSS pixels were recalculated to a number of device pixels. In the printing sense there is there is nothing new in high DPI devices, the new devices are just the first interactive devices that end up using the printing tricks of large CSS pixels. This means we already have CSS and media query support for high DPI devices, but there are just only two meaningful DPIs on interactive devices: 96 or 192 (with 288 dpi reserved for future bling). Best regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
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
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
To answer my own question:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/MediaQueryEvaluator.cpp#L66
On Mon, Apr 23, 2012 at 11:11 PM, Eric Seidel e...@webkit.org 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
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
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
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
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.
As far as the resolution media query is concerned, the resolution of the
new iPad and the iPhone 4 (and anything else with a device-pixel-ratio
of 2) is exactly 192dpi.
This is because the CSS 'dpi' unit is defined to mean dots device pixels
per *CSS inch*, and CSS inches are hardcoded to be 96 CSS pixels.
This means that—without real physical units—the resolution media query
is always redundnant with device-pixel-ratio, which a) we already
implement, and b) is easier to explain to authors than explaining why
both the new iPad and the iPhone 4 are 192 dpi.
Ted
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Hi Tom, You wrote: 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. webkit-dev probably isn't the best place to design new Web-facing features; in particular, there is ongoing work on this problem space in the CSS WG, the WHATWG, and elsewhere. See for instance the threads starting here http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/thread.html#34683 and here http://lists.w3.org/Archives/Public/www-style/2012Feb/thread.html#msg1103 Anybody is welcome to contribute to www-style and the whatwg list. Ted ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On what standard mailing lists have this idea been proposed or discussed?
At glance, it seems like a bad idea to add a specific element for the
double resolution images. What makes us think that someone won't come up
with 3x or 4x resolution screens in near future?
On Mon, Apr 23, 2012 at 2:44 PM, Tom Penzer tpen...@mailcan.com wrote:
1) The new meta tag 'double-resolution-images' (whose value would be a
string for the double-res filename key - the often-standardized string
added to the filename for 2x assets, i.e. '_2x'), with the optional boolean
(defaulted to 'true') attribute 'assume-present', and maybe eventually the
optional attribute 'double-resolution-path' for cases where sites store all
their 2x image assets in a different directory than their 1x images.
You mean a content attribute? It's unusual for a content attribute name to
include -.
2) A new optional attribute to the img tag called 'double-resolution',
(possible values include 'true', 'false', a string for the double-res
filename key - the often standardized string added to the filename for 2x
assets, i.e. '_2x', or 'url()' to specify a completely different path for
the 2x asset)
You mean an attribute?
3) The new optional CSS properties '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()').
Again, what makes us think that we won't need background-image-3x,
background-image-4x, ... in the future? Or maybe background-image-7.5x?
A simple example usage of these new capabilities would be the following:
meta double-resolution-images=_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'.
Not all images end with .ext. It could be generated by a server-side
script for example. What do we do with them?
By using this approach, we avoid the need to specify the same list of
filenames varying only by 2x-res 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.
A much better solution would be adding a new http request header, and let
the server send back back double resolution images.
Quite frankly, I don't think we're interested in implementing this proposal.
- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On Apr 23, 2012, at 3:42 PM, Ryosuke Niwa rn...@webkit.org wrote: On what standard mailing lists have this idea been proposed or discussed? I have not yet submitted to w3.org public-html or public-html-comments as I wanted to get the take of the webkit community first, since you guys are particularly interested in this issue. Again, what makes us think that we won't need background-image-3x, background-image-4x, ... in the future? Or maybe background-image-7.5x? Then maybe a meta 'image-scaling' attribute rather than 2x-specific. The main point is to avoid requiring each image path for the different scales to be explicitly written, when it's likely a standardized variation from the 1x image file path. We should explore ways to codify those variations, instead of making our lives hard. Not all images end with .ext. It could be generated by a server-side script for example. What do we do with them? Well, if you could think of a way to codify that request in a standardized way, that would certainly be something to consider. Do you think this type of system could be extended to account for such a situation? By using this approach, we avoid the need to specify the same list of filenames varying only by 2x-res 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. A much better solution would be adding a new http request header, and let the server send back back double resolution images. Quite frankly, I don't think we're interested in implementing this proposal. - Ryosuke If that means we don't need to go through and fill out every single file path for every different scale image if there's a file naming system in place, then I'm all for it. I'm just scared we're needlessly making our lives harder than they should be. -Tom P. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
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
