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

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

From: Simon Miles-Taylor <smilestaylor@gmail.com>
Date: Wed, 5 Nov 2014 10:18:11 +0000
Message-ID: <CAGeVLLMnuPDOLQo9Ex7gdr4v+gA30j4EBN+s-XxZ0oijQp9QHQ@mail.gmail.com>
To: Ilya Grigorik <igrigorik@google.com>, public-respimg@w3.org
Hi IIya,

I understand the geometry issues, I have 20,000 images.  My point is that,
quite understandably, the time to render text is minimal whilst the time to
render an image is significant.  Unless you "reserve" space for the image
the rendering process does not know how much space to allocate for the
image and will re-position the text once the geometry has been
established.  With an undetermined aspect the text will be pushed out of
the way to accommodate the image.

So if you images have a variable geometry, I create a container larger than
the maximum aspect and center and vertically align the image within that
container and a separate container for the text.  This way the text can be
rendered independently without any knowledge of the true dimensions of each
image as the image will always fit its dedicated image container.

Yes I understand the concept of reading the header to ascertain the
geometry, I already use this to store the image aspects for each of the
images using a database program which is then uplifted to the web.

The delay in rendering images is totally understandable, enabling rendering
engines to be able to position text and images can be acheived if you
construct the page allowing a distinct space for images and a seperate
space for the text underneath the image container.

Simon

On 5 November 2014 00:48, Ilya Grigorik <igrigorik@google.com> wrote:

> 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
>>>
>>
>>
>
Received on Wednesday, 5 November 2014 10:18:39 UTC

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