@simevidas Maybe @eeeps has an idea since he investigated image sizing? I have a feeling it’s just built-in browser stuff in regards to how a <source> gets rendered in an <img> that fails to take account of the “Always show scroll bar” setting on macOS?
@db@eeeps I’m not familiar with the details of responsive images, but 100vw seems like a bad default. Why make images cause horizontal overflow by default in browsers with classic scrollbars?
Of course, the web page can set max-width: 100% on <img> to avoid this issue, but the default should not cause issues to begin with.
@simevidas@eeeps In general, omitting sizes in such markup is an author error, and since sizes can’t use percentages, 100vw sounds like a sensible second choice that nonetheless should not be reached
@db@eeeps So what is one to do to avoid the issue in HTML alone? Set sizes to the pixel width of the image and then add an extra 20px to the media condition to account for a potential scrollbar?
@simevidas@meduz@db Responsive images SHOULD have extrinsic widths; sizes is supposed to be a hint of the extrinsic size, and sometimes I worry that it was a mistake to make it also affect the intrinsic size, but – what else should the default intrinsic size of a responsive image be? I don't have a better answer.
@eeeps@meduz@db The problem is that the default is 100vw, which can cause the page to overflow horizontally in browsers with classic scrollbars. Maybe a better default would be the width of the ICB (initial containing blog)? That would fix the potential overflow issue (since the width of the ICB decreases when scrollbars are present).
@eeeps@meduz@db By default, classic scrollbars are automatic (they only appear when they’re needed), so the browser cannot know before layout what the final width of the ICB will be.
If responsive images resized with the ICB, that would cause layout shifts in the vertical direction I guess, so that’s not good.
@simevidas@meduz@db Right, sizes is there to give a value before layout that's a hint of the after-layout width. If it changes after layout, you could get double-loads, which defeat the whole point.
Is the concern what the platform can do for users when authors make the mistake of omitting CSS, like this? Or is there an unmet use case around "HTML-only" responsive images, that you think is important?
@eeeps@meduz@db I think that responsive images should work well without requiring any extra CSS.
If the author defines image sources via srcset and width descriptors (srcset="example.jpg 1000w, etc.") and nothing else (no sizes attribute, no CSS), then the browser should not make the image 100vw wide, but slightly smaller.
This could be achieved by defaulting the sizes attribute to
100vw - 16px (default body margin) - scrollbar size (only in browsers with classic scrollbars)
@eeeps@meduz@db 100vw is just a bad value (because viewport units ”assume scrollbars never exist”). Authors should not use 100vw to set element widths, and the HTML standard should not use it either for its features.
@simevidas@meduz@db I'm not sure if this is fixable soon, in a web-compatible way. Some images (like the one you found) are depending on the intrinsic size, and folks might be surprised at some new whitespace / consider their layouts "broken".
I'm doubting that the fix you mentioned will fix this, because it depends on other CSS, and srcset selection can't depend on any CSS. I guess this will end up like 1em meaning different things in different contexts?
@eeeps@simevidas I found it intriguing that sizes influences the layout width, so I pored over the HTML spec to get a better picture. Thanks for bringing these things up, fun times with the web platform!
@db I’m not sure I like the term “density-adjusted natural dimensions”. “Adjusted” and “natural” feel like opposites to me. When something is adjusted, it’s no longer natural. If I had to guess, I’d say that “natural” is the image’s own dimension, outside of the browser. This is unless the density adjustment happens in the image’s own EXIF data, and the browser just reads that data without making any further adjustments, which I don’t think is happening in this case.
> Instead of describing the preferred image densities, width descriptors (using the w suffix) declare the original width of each of the image sources.
So the image’s own dimensions are referred to as ”original”. That’s different from “natural”, right? Or is “original” the same as “natural”, which are different from “density-adjusted natural”?
So if the website provides ultra-high-density image sources, and the user zooms the page, Safari won’t use those sources, even after page reload. In other words, at high page zoom levels, images on some websites will be noticeably blurrier in Safari than in Chrome and Firefox. That sounds like a bug to me.
@simevidas Yeah, that would be amazing. I haven’t looked closely at how pinch-zooming is implemented, but it does look like it works by increasing the size of the CSS pixel
> The scale transform of the visual viewport is often referred to as "pinch-zoom". Conceptually, this transform changes the size of the CSS reference pixel but changes the size of the layout viewport proportionally so that it does not cause reflow of the page’s contents.
Add comment