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

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/

Received on Friday, 7 November 2014 17:32:58 UTC