Re: Informing the browser of the expected size of the image

Nelson,

That actually is the sort of thing I was originally thinking of.  But, 
it is possible that the aspect ratio be different for each url in the 
srcset.  The <picture> element is preferred  for that situation, but I 
don't think anything does or should preclude the images in a srcset list 
from having different aspect ratios.  So that would lead to a more 
complicated syntax for your case, something like:

<img src="lighthouse-160.jpg" alt="lighthouse"
      sizes="80vw"
      srcset="lighthouse-160.jpg 160/200 160w,
              lighthouse-320.jpg 320/400 320w,
              lighthouse-640.jpg 640/600 640w,
              lighthouse-1280.jpg 1280/1000 1280w">

That complexity led me to the thought of offloading the specifying of 
the individual image information to an at-rule.

As to Greg's comment about a new HTML attribute, I was thinking it would 
be nice (and seem logical) if the name defined in the at-rule be useable 
as a src attribute value.  But there may not be any syntax that would be 
backward compatible.  I was going to test things like 
src="lighthouse-160.jpg #my-at-rule-name" to see if that would break in 
any browsers.

Steve


On 2014-11-07 04:57, Nelson Menezes wrote:
> I've been a little out of the loop, so apologies if this is a
> beaten-to-death, silly suggestion, but wouldn't something like this
> address the issue?
> 
> <img src="lighthouse-160.jpg" alt="lighthouse"
>      sizes="80vw"
>      aspect-ratio="160 200"
>      srcset="lighthouse-160.jpg 160w,
>              lighthouse-320.jpg 320w,
>              lighthouse-640.jpg 640w,
>              lighthouse-1280.jpg 1280w">
> 
> From the above code the browser should be able to determine the aspect
> ratio (160/200 = 4/5) and allocate the appropriate screen space as
> determined by CSS reflows (CSS sizing, if present, should override the
> property).
> 
> Of course, this would be applicable in <picture><source> as well.
> 
> On 6 November 2014 22:33, Greg Whitworth <gwhit@microsoft.com> wrote:
> 
>> This is worth discussing with Tab as we already have image-set in L3
>> of Images: http://dev.w3.org/csswg/css-images-3/#image-set-notation
>> [1]
>> 
>> My only issue with what you propose below is that I think it should
>> follow how fonts currently work. You should only tie the image-set
>> to their respective DOM element using currently supported selectors,
>> not with a new html attribute.
>> 
>> Thanks,
>> Greg
>> 
>> -----Original Message-----
>> From: steve@steveclaflin.com [mailto:steve@steveclaflin.com]
>> Sent: Thursday, November 6, 2014 1:02 PM
>> To: Yoav Weiss
>> Cc: Frédéric Kayser; public-respimg@w3.org; Simon Miles-Taylor;
>> Ilya Grigorik
>> Subject: Re: Informing the browser of the expected size of the
>> image
>> 
>> We're kind of sliding down the path toward implementation details,
>> which isn't necessarily a bad thing...
>> 
>> But, I'd still like to see some way for the designer to code in the
>> sizing info with the initial HTML, so that the browser would
>> immediately know what the expected dimensions are, and, at the point
>> where it starts to apply media queries (which hopefully is early in
>> the overall process), it can adjust the allocated space based on a
>> max-width rule.
>> 
>> This seems particularly important in the "art direction" use case,
>> where the individual images might have different aspect ratios.
>> 
>> Sorry if I'm treading back over material that was covered in
>> earlier discussions - so maybe something along the lines of the
>> following has already been considered and discarded:
>> 
>> It seems that the specifications of an image bear at least some
>> similarity to definition of a font. So, maybe some sort of way to
>> define a spec for an image, tied to a global name, could be used -
>> the same way a font file is described, including a selection of
>> files the browser chooses from, and mapped to a name.
>> 
>> The image spec would describe all the stuff that the browser would
>> need, including actual image width, height, and/or aspect ratio.
>> This would be similar to the HTTP/2 headers the last few respondents
>> have mentioned.
>> 
>> It could use a syntax like @image-spec { ... } (very similar to
>> the srcset, source approach used in img and picture currently). All
>> that would map to a name, like a font-family does.
>> 
>> Then, an img tag could list a src attribute for fallback purposes,
>> and something like src-spec="spec-name" for savvy browsers, which
>> would get the same type of info that they now get from source/srcset
>> from the @image-spec. (I realize that one flaw in this is that
>> @image-spec is CSS, and at the moment the image choice is done in
>> the HTML, but this could open up the possibility of making the image
>> file choice in CSS).
>> Or the image spec could be done in a more HTML manner.
>> 
>> By putting the specifications in a separate block outside the HTML,
>> I think it could use a more verbose, precise, and intuitive syntax.
>> Plus that helps with the separation of presentation from content
>> issue that still seems to get discussed around the current approach
>> (the content is the spec name, and the presentation comes from the
>> spec details).
>> 
>> On 2014-11-06 13:41, Yoav Weiss wrote:
>>> Google's John Mellor experimented with a similar idea a while
>> back..
>>> You can see the gist of it at
>>> http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2
>> [2] [2]
>>> (click the down arrow to see the image download progress.
>> Apologies
>>> for the huge images that are downloaded as part of the
>> presentations
>>> :/ )
>>> 
>>> On Thu, Nov 6, 2014 at 8:24 PM, Frédéric Kayser
>> <f.kayser@free.fr>
>>> wrote:
>>> 
>>>> Hello,
>>>> I sought a bit about this before going to bed and wake up with
>> this
>>>> idea, HTTP/2 servers could send progressive JPEG images sliced
>>>> exactly at scan borders (each progressive "refinement pass" is
>> called
>>>> a scan and starts after a xFFDA Start Of Scan marker), the
>> effect
>>>> could be especially neat if servers send the first image scan of
>> each
>>>> image first, this could be relatively fast. To get an idea of
>> the
>>>> data size needed to send just this part you can apply JSK (JPEG
>> Scan
>>>> Killer [1]) to a progressive JPEG and check the size of the
>> first
>>>> file it produces. Parsing a JPEG file to find the scan borders
>> is
>>>> quite easy and fast since no real decompression of the image has
>> to
>>>> be performed, it could be done in realtime or cached if needed.
>>>> 
>>>> Frédéric Kayser
>>>> 
>>>> Le 5 nov. 2014 à 01:48, Ilya Grigorik <igrigorik@google.com> a
>> écrit
>>>> :
>>>> 
>>>> Simon, I'm not sure I follow.. I think what you're describing is
>>>> orthogonal to what Kornel and I are saying.
>>>> 
>>>> With HTTP/2 the server can send the first KB (or whatever
>> amount) of
>>>> the image to allow the browser to decode the image header and
>> get the
>>>> geometry of the image much earlier.. which minimizes reflows
>> during
>>>> initial page load (which is awesome).
>>>> 
>>>> ig
>>>> 
>>>> On Wed, Nov 5, 2014 at 9:01 AM, Simon Miles-Taylor
>>>> <smilestaylor@gmail.com> wrote:
>>>> 
>>>> IIya,
>>>> 
>>>> The trick with images is to put them in a Div and the text
>> underneath
>>>> that way the browser can place the text underneath and deposit
>> the
>>>> image into a "container" above.
>>>> 
>>>> If you put a Null image preceding the real image with Height of
>> 100%
>>>> and Width of 0 and use vertical align on both images you will
>> get
>>>> vertical alignment.
>>>> 
>>>> I cheat I have VB code that collects and stores the image
>> attributes.
>>>> 
>>>> Simon
>>>> 
>>>> On 4 November 2014 22:14, Ilya Grigorik <igrigorik@google.com>
>>>> wrote:
>>>> 
>>>> On Fri, Oct 31, 2014 at 10:38 AM, Kornel <pornel@pornel.net>
>> wrote:
>>>>> On 27 Oct 2014, at 17:03, steve@steveclaflin.com wrote:
>>>>> 
>>>>> Now, in particular, when we could have images with different
>>>> aspect ratios, it seems like the browser wouldn't know until it
>>>> downloads one what the aspect ratio is. And we might end up with
>> a
>>>> very jumpy page.
>>>> 
>>>> For this I'm rooting for "smart" HTTP/2 servers that can push
>> all
>>>> image file headers (that contain image dimensions) to the client
>> very
>>>> early, and resume sending of the rest of the image data only
>> after
>>>> other assets have been sent. In theory HTTP/2 allows servers to
>> do
>>>> this automatically with very little overhead and it would "just
>> work"
>>>> without need for any extra markup.
>>>> 
>>>> Of course, we're not there yet. I feel your pain, interaction
>> between
>>>> image height and max-width is really annoying.
>>>> s/we're not there yet/we'll be there in few weeks time/
>>>> 
>>>> Chrome 39 is shipping http/2 in stable, so is FF 35. Meaning, in
>> a
>>>> few weeks time we'll have a significant fraction of users
>> running
>>>> HTTP/2 capable browsers... and we can start experimenting with
>> above
>>>> server implementations.
>>>> 
>>>> ig
>>> 
>>> 
>>> 
>>> Links:
>>> ------
>>> [1]
>>> 
>> 
> http://encode.ru/threads/1800-JSK-JPEG-Scan-Killer-progressive-JPEG-ex
>> [3]
>>> plained-in-slowmo [2]
>>> http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2
>> [2]
> 
> --
> 
> Nelson Menezes
> http://fittopage.org [4]
> 
> 
> Links:
> ------
> [1] http://dev.w3.org/csswg/css-images-3/#image-set-notation
> [2] http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2
> [3] 
> http://encode.ru/threads/1800-JSK-JPEG-Scan-Killer-progressive-JPEG-ex
> [4] http://fittopage.org/

Received on Friday, 7 November 2014 15:30:49 UTC