> From: m...@apple.com
...
> >>> I have always been comfortable with the 'x' part of srcset, but the w
> >>> and h part felt somewhat wrong to me. What you'd really want to consider
> >>> when deciding which image to pick isn't the size of the viewport itself,
> >>> but the size available for the image once the rest of the layout is
> >>> taken into account.
> >>
> >> Yeah. That's how I originally designed srcset="", actually, but it was
> >> pointed out to me that that's impossible to implement because at the time
> >> the browsers need to pick an image, they haven't yet gotten the style
> >> sheet so they don't know what the layout will be.
> >>
> >> (Note that the media-query-based solutions have the same problem.)
> >
> > If people are really concerned about this latency then they can inline the
> > style so that the image layout size is known before other resources are
> > available - this may just be the image CSS pixel size and many of these
> > proposals require this to be included anyway.
>
> That's not really a viable solution. Many authors take little care i making
> their pages load fast, but browser implementors still consider it important
> to load them fast.
Yes, the load time is important, and if the images is chosen based only on
media queries than it can be loaded immediately. However the loaded images may
not be an appropriate resolution - too small with not enough detail or too
larger slowing page load.
> > It will also help with backwards compatibility to have the style available.
> > For example:
> >
> >
> >
> > The dimensions here are in image pixels, not CSS pixels. The set would
> > include the 'src' image to give the declared image pixel size. The byte
> > size and perhaps height could be optional.
>
> The layout size of that element is not computable until all external
> stylesheets have loaded, as you have written it.
Actually, the image width is '10em' in this example, without having to load any
style sheets! The browser can immediately determine the image to use and load
it in this particular case.
I understand your point though. The layout size of the element can even
change after loading all resources as the user zooms or interacts with the
content. Currently there is only one image choice, and it may be too large
which would delay loading or too small and lack detail.
The latency caused by style sheet loading is something accepted long ago.
Pages that need the faster load times, such as landing pages, are going to
inline the style, and perhaps even images. Websites for which visitors are
expected to browse many pages would have common style sheets that would be
cached and available immediately after the first visit.
> > In other cases, browsers could either delay loading the image or lookup the
> > 'src' image in the set to obtain the declared image pixel size and use this
> > to speculatively load an image (once the image viewport size is finalized
> > the browser could then decide if a higher resolution image is needed and
> > load it then if necessary).Browsers will need to be prepared to reload
> > a higher resolution image anyway in case of zooming in.
>
> Speculatively loading the wrong image does not strike me as an implementation
> approach that we'd be interested in.
>
> Page loading performance is very important to users, and therefore to browser
> implementors. I think it's important to avoid defeating important existing
> optimizations when adding new features.
Consider that it will give the layout engine the image size before the images
are loaded, because the sizes are declared inline. This could significantly
reduce layout delays. Knowing the layout earlier could help make better
decisions about image load order.
Further, the layout engine may well be able to load a smaller lower resolution
images, reducing load times.
Page load times could be faster than they currently are by firstly loading the
lowest resolution images - and it would even be more practical to inline these
in data: URLs. Users may well prefer to have pages load faster with low
resolution images and accept the delay waiting to higher resolution images to
load.
There do appear to be opportunities to achieve even faster page load times, and
a better user experience. Perhaps you could take another look at the issues
and opportunities.
cheers
Fred
