Re: [whatwg] responsive images srcalt proposal

I was thinking that having simplified rules in your markup that try to
describe image sizes related directly to device size would be tricky to
match with more advanced rules in CSS (eg. responsive images inside nested
rows)... That's why everything mentioned in srcoptions is related to
element-width as opposed to device-width. That said - I'm all for making
layouts simpler (avoid nested rows and whatnot) to be able to get
bulletproof preloading. It's just nearly impossible when image layout
absolutely _has_ to follow a fluid grid system.

Device-pixel-ratio can be quite relevant to include in urls; with an 2x
image compression artifacts in lossy formats (jpg, webp) are less visible
which in turn means you can crank up compression without losing visible
quality while getting an image that'll weigh roughly the same as the
equivalent 1x image. It's a very nice trick :)

The naming convention isn't set in stone - that was what the urlpattern was
for. Tweaking of how the actual options should be written is open for
suggestions. It might as well be written like this if that suits better:

<img src="/path/to/image-200-300-1x.jpg" width="200" height="300"
    srcoptions="/path/to/image-{width}-{height}-{dpr}x.{format};
200x300, 400x600; 1, 1.33, 2; webp, jpg"/>


The point I still feel srcoptions get right is shortness; almost all
examples of picture/srcset/src-n/srcalt feature images in only one format.
Just adding support for an extra format in the markup examples leads to a
lot of duplication where in srcoptions you just add ", webp" - done! :)



On Sat, Jan 25, 2014 at 5:31 PM, pghj <pghjvanblokland@gmail.com> wrote:

> We could minimize it dramatically if only a url-pattern and the available
>> options are exposed instead of a long list of explicit urls:
>>
>> <img src="/path/to/foo-320w-240h-1x.jpg" width="320" height="240"
>>     srcoptions="/path/to/foo-{width}-{height}-{dpr}.{format},    320w 480w 640w, 1x 1.33x 2x, webp jpg"/>
>>
>> Wouldn't this sort of thing be much easier to learn/read/write? Both
>> humans and machines.
>>
>> I won't bother you with all the details here - I've tried to flesh out
>> the idea in this gist: https://gist.github.com/rasmusfl0e/6727092
>>
>
>
> I think srcset refers to maximum device size, and your srcoptions to image
> sizes, so I'm not sure about the equivalence mentioned in the linked
> document.
>
>
>  Wouldn't srcoptions produce many URL aliases? I'd say these are the same
> image:
>
> /path/to/foo-320w-240h-2x.jpg
>
> /path/to/foo-640w-480h-1x.jpg
>
> This would cause cache misses (in proxy servers), or introduce complexity
> in the server for making redirects.
>
> If srcoptions also intends for each image to be visually identical, I
> don't see the point in including pixel densities anyway.
>
> Furthermore, the naming convention will be incompatible with many existing
> practices.
>
>
> If compacting/DRYing of markup is an issue, I would propose the following
> extension to srcalt:
>
>
>  <img srcbase="/path/to/" srcalt="image200.jpg 200x300 5kB, image400.jpg
> 400x600 12kB" />
>
> <img srcbase="/path/to/" srcalt="thumbnails/image.jpg 200x300 5kB, normal
> /image.jpg 400x600 12kB" />
>
> <img srcbase="/path/to/image.jpg" srcalt="?w=200 200x300 5kB, ?w=400
> 400x600 12kB" />
>
> <img srcbase="/path/to/image.jpg" srcalt="?s=small 200x300 5kB, ?s=large
> 400x600 12kB" />
>
>
>  where the URI reference in srcbase is resolved against the document base
> URI, and the references in srcalt are in turn resolved against that. A
> number of alternative naming schemes are shown. The last two offer the
> greatest opportunity for compacting markup.
>
>
> Josh.
>
>
>

Received on Saturday, 25 January 2014 17:22:25 UTC