Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Relationship to responsive image features #3
There was a lot of talk back in the day about adding an
Does this proposal have any advantages over this (which was proposed but not yet spec'd or implemented):
<img srcset="image.jpg 600w 400h" />
I can see some disadvantages.
<img srcset="300x200.jpg 300w, 600x400.jpg 600w, 800x533.jpg 800w" />
<picture> <source media="(max-width: 600px)" srcset="cropped-square-sm.jpg 600w, cropped-square-lg.jpg 1200w" sizes="100vw" /> <img srcset="full-16x9-sm.jpg 800w, full-16x9-med.jpg 1400w, full-16x9-lg.jpg 2000w" sizes="100vw" /> </picture>
In cases where
@tigt yup! You might have small changes because of rounding (3000×2000 → 188×125), dunno if those would ever matter? But per spec,
If the aspect-ratio is changing in non-scaling-rounding related ways (e.g., 16:9 → 1:1), use multiple
My bad. I didn't know the aspect-ratio would remain the same.
However, I have a different opinion in terms of which solution is cleaner:
In addition, from an implementation's perspective, "intrinsic-size" attribute will be easier to parse ([number] x [number], and always in px unit). The logic is easier to implement and understand too. Adding an 'h' dimension sounds great and comprehensive, but it does add some complication, to both web dev and browser dev to interpret.
Apologies in advance for my inexperience in web dev or any misunderstanding of this issue.
Let me check my understanding of the explainer. I’m worried that things might get a little weird and/or complicated re: intrinsic sizes and responsive images. Consider the following markup:
<img intrinsicsize="16x9" srcset="small.jpg 640w, medium.jpg 960w, large.jpg 1024w, extra-large.jpg 1280w" sizes="100vw" />
Let's say the user agent picks
I think the intent is that it would render at
However, given the current kinda-vague language in the explainer, I worry...
I think the above image has:
So! Given the language of the explainer and my current understanding of the spec, I worry this markup in this context will render at
This seems bad. Am I missing something?
intrinsicsize will work as an intrinsic ratio when it comes to responsive images.
@tabatkins and I talked about the possibilities of modifying how responsive images determine intrinsic dimensions based on the "intrinsicsize" attribute. He might have more thoughts on how it will work with intrinsic density.
I was looking at how responsive images calculates its source size , and I think the algorithm below would make "intrinsicsize" work well with responsive images:
The “Intrinsicsize” attribute sets the image’s intrinsic aspect ratio, and the intrinsic width and height equivalent to descriptor ‘1x’.
For #2, intrinsic dimensions here are post-density correction, so there's no need to invoke density at all here. The value specified in
So, you can just collapse away the second bullet point entirely and just rely on the first and third.
Sounds workable? I’ve got a question about how this might interact with Client Hints, but I’ll spin up another thread for that. A couple of markup-focused follow-ups:
Yes. I think that's the most reasonable interpretation here, as it preserves the full meaning of
I don't think so. Either we allow both
That's exactly what we do, yes. If
Just to close the loop, for the two examples in the OP...
<img srcset="300x200.jpg 300w, 600x400.jpg 600w, 800x533.jpg 800w" sizes="100vw" intrinsicsize="3x2" />
<picture> <source media="(max-width: 600px)" srcset="cropped-square-sm.jpg 600w, cropped-square-lg.jpg 1200w" sizes="100vw" intrinsicsize="1x1" /> <img srcset="full-16x9-sm.jpg 800w, full-16x9-med.jpg 1400w, full-16x9-lg.jpg 2000w" sizes="100vw" intrinsicsize="16x9" /> </picture>
@ojanvafai, does any of this need to be captured in the explainer, or can it wait until there's a spec?