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

The only way to check is by downloading all images in a srcset, so no idea
how this can be done.
 On Nov 7, 2014 6:32 PM, <steve@steveclaflin.com> wrote:

> I agree in terms of best practices, but I don't think the spec for img
> disallows the use of urls with different aspect ratios in srcset.  So then
> a question arises as to whether the syntax should support legal but bad
> practices.
>
> Steve
>
> On 2014-11-07 10:51, Attiks wrote:
>
>> If the aspect ratio is different I think you better use picture, since
>> browsers are allowed to choose whatever they think is best. Especially
>> when the screen gets smaller they do not have to fetch a new one.
>>
>> On Fri, Nov 7, 2014 at 4:37 PM, <steve@steveclaflin.com> wrote:
>>
>>  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]
>>> [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] [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]
>>
>>  [3]
>>>
>>>  plained-in-slowmo [2]
>>>> http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2
>>>> [2]
>>>>
>>> [2]
>>>
>>
>>  --
>>
>>  Nelson Menezes
>>  http://fittopage.org [4] [4]
>>
>>  Links:
>>  ------
>>  [1] http://dev.w3.org/csswg/css-images-3/#image-set-notation [1]
>>  [2] http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2
>> [2]
>>  [3]
>> http://encode.ru/threads/1800-JSK-JPEG-Scan-Killer-progressive-JPEG-ex
>> [3]
>>  [4] http://fittopage.org/ [5]
>>
>>
>>
>> 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
>> [5] http://fittopage.org/
>>
>