W3C home > Mailing lists > Public > public-respimg@w3.org > November 2014

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

From: <steve@steveclaflin.com>
Date: Thu, 06 Nov 2014 15:01:51 -0600
To: Yoav Weiss <yoav@yoav.ws>
Cc: Frédéric Kayser <f.kayser@free.fr>, public-respimg@w3.org, Simon Miles-Taylor <smilestaylor@gmail.com>, Ilya Grigorik <igrigorik@google.com>
Message-ID: <7d79064873aaae1ccdc8d054812bafe3@steveclaflin.com>
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-explained-in-slowmo
> [2] http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2
Received on Thursday, 6 November 2014 20:55:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:15 UTC