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

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


-- 
Nelson Menezes
http://fittopage.org