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

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


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] 
> (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

> plained-in-slowmo [2] 
> http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2

Received on Thursday, 6 November 2014 21:33:46 UTC