sizes
attribute should directly set the intrinsic width of the image
#3981
Labels
needs implementer interest
Moving the issue forward requires implementers to express interest
normative change
topic: img
As currently defined, the
sizes
attribute onimg
/source
doesn't have any direct effect on the image; instead, it expresses a desired intrinsic width. You then combine it with sources having aw
descriptor, describing how wide the source is in image pixels. Dividingsizes
byw
thus gives you an effective density, which lets you choose between sources. Finally, when you actually download the image, if, thew
descriptor was telling the truth (the image actually is that wide in image pixels), applying the effective density to it results in an intrinsic size equal to what you said insizes
.This is roundabout, but it works. But it hinges on the
w
descriptor telling the truth; if it lies, and the image is actually a different width in image pixels, when you apply the effective density you'll get a different size than whatsizes
says. Thus, you can't tell what the intrinsic width will actually be until you download the image, even tho in normal situations you have all the information you need right there in the markup.This causes some bad interactions with the proposed
intrinsicsize
attribute. In most cases it directly provides the intrinsic width/height, but we want to respect thesizes
attribute, as it's useful and powerful; so instead, when used on a sizes/w-using source, it just provides the intrinsic ratio.The problem, then, is that even tho we can virtually always count on
sizes
giving us an intrinsic width, andintrinsicsize
giving a ratio, thus giving us an intrinsic height, technically we have to wait until the image is downloaded to tell what the actual intrinsic width will be, thus negating the benefit ofintrinsicsize
.I think we can make this change compatibly: any image that is using
w
correctly will experience no change, and any image that is using it incorrectly would have already had confusing sizing behavior, such that this has a good chance of actually improving things.The text was updated successfully, but these errors were encountered: