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
