On Apr 27, 2012, at 2:49 PM, Jason H <[email protected]> wrote:
> 1. To my knowledge w3c has never specified file naming conventions. Maybe
> extensions, as they are related to mime types, but this would be a new
> function of filename itself that would affect rendeing quality. What about
> images that already exist out there that are named as such? No, we should not
> use the filename for metadata.
But it's what humans are already using, and it allows for a powerful and
flexible system. Perhaps we should start using the file name and filename
extension as meta data, and not make our lives harder than they need to be.
> 2. The user agent can use Javascript to do this already.
How can this be standardized, where the various browsers make an informed
decision which image scale to request?
> 3. The JS method is backwards compatible and requires no changes. To say it
> degrades gracefully, I think is the wrong direction. Initial sources should
> be low-res, then upgrade accordingly.
That's how this works. You have the following code:
<meta image-scaling={2,"_2x"} />
<img src="path/to/filename.ext" />
And then the browser loads the 2x asset at 'path/to/filename_2x.ext' if it
understands the image-scaling meta attribute, or just the default 1x asset at
'path/to/filename.ext/' otherwise.
>
> From: Tom Penzer <[email protected]>
> To: Jason H <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Sent: Friday, April 27, 2012 4:57 PM
> Subject: Re: Image Scaling for High-Pixel-Density (i.e. Retina) Displays -
> Re: -webkit-image-set and <image>
>
> The main advantages of doing it this way are:
> 1) You don't need to specify a different path for every scale of every image
> if you follow a naming convention.
> 2) the user agent makes the decision of which asset to request (based on
> factors such as screen resolution and network quality/value of bandwidth)
> 3) It's backwards-compatible and degrades gracefully.
>
> -Tom
>
>
> On Apr 27, 2012, at 1:50 PM, Jason H <[email protected]> wrote:
>
>> I think the approach of attacking it from setting a scaling is wrong.
>> The real approach is to set the final dimensions, and let the software give
>> the appropriate scaling based on the image metadata.
>>
>> If you want a double-density image, you're just asking for 100x100 to be
>> rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50
>> WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display
>> density is identical to the sampling (pixel density) by not including the
>> height and width attributes.
>>
>> The real challenge as I see it, is having an efficient way of not sending
>> over-sampled data across the wire, unless you mean to. Sending a double
>> density image actually sends 4 times the data as a native resolution image.
>> I would suggest we leave it up to java script to handle the pixel density
>> matching, where it can dynamically assign the assets to the proper
>> size-density, if needed. For the most part pick something not over sampled
>> and let the browser scale it up if need be. A server-component could
>> dynamically render and cache the common sizes of an image. But I don't see a
>> need to change HTML.
>>
>>
>>
>>
>>
>>
>>
>> From: Tom Penzer <[email protected]>
>> To: [email protected]
>> Sent: Friday, April 27, 2012 3:47 PM
>> Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re:
>> -webkit-image-set and <image>
>>
>> Hi everybody,
>>
>> I'm 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/[email protected]") />', or to
>> its css properties by doing: '.class {background-image-2x:
>> url("path/to/[email protected]");}'.
>>
>> 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.
>>
>> 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
>> humble web coding noob
>>
>>
>>
>>
>
>
