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

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]
>>>
>>>
>>> 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]
>>>
>>>  (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]
>>>
>>>> plained-in-slowmo [2]
>>>> http://yoavweiss.github.io/respimg-blinkon-presentation/#/71/2
>>>>
>>> [2]
>>>
>>
>> --
>>
>> Nelson Menezes
>> http://fittopage.org [4]
>>
>>
>> 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/
>>
>
>