[resize-observer-1] physical, rather than logical, dimensions – for images

[eeeps]

ResizeObserverSize only delivers an observed element’s inline and block sizes.

This is great when working with textual content, but I ran into a use case today where I actually wanted the height and width of a box, when trying to dynamically load an image to fit it.

The image always needs to be oriented as we see the world -- with horizontal horizions, people's faces up, not sideways, etc. I need to know its width, and height -- not its size in dimensions relative to the writing direction.

Here's a very quick sketch - basically, inline and block rotate but the image content should not - if this is confusing I can throw together a more fleshed-out use case.

[css-meeting-bot]

The CSS Working Group just discussed [resize-observer-1] physical, rather than logical, dimensions – for images.

The full IRC log of that discussion

<dael> Topic: [resize-observer-1] physical, rather than logical, dimensions – for images
<dael> github: https://github.com//issues/4005
<dael> fantasai: Someone posted a strong use case to return phsyical dimensions. Prop is add phsyical to what resize-observer can return. Use case makes sense and we should do this
<dael> iank_: Use case is? How will they use this?
<dael> astearns: By my reading the block and inline size in a flow that is orthogonal to an image's useful orientation doesn't really help
<dael> astearns: Though in reading htis I'm a little confused as to if you know that's the case why you can't just flip the sizes you get. Are there cases where you don't know if block directio is useful?
<dael> myles: Spec that canvas rotated in veritical?
<dael> fantasai: NOt rotated. If he wants width of image he has to switch based on writing mode so he needs to switch to decide if he wants inline or block
<dael> iank_: No objections to adding but it's not explicitly a use case since it doesn't say how he's going to use information
<dael> fantasai: You can ask him for more details
<dael> myles: In agreeing with iank_ another solution solved by this would be not return logical and only physical. Need some information to know that both is better than just phsyical
<dael> fantasai: We're already returning block size. It's just that on image you then need writing mode
<fantasai> s/block/inline & block/
<dael> astearns: I don't think we can remove inline and block size and return something else
<dael> myles: Not clear to me canavas is used enough that it's a problem to change behavior
<dael> fantasai: Shouldn't return different APIs depending on the element.
<dael> astearns: Hearing a little concern about adding something that may or may not be useful given data. Do we need to go back with code examples or request more information?
<dael> dholbert: Also asking if they want to observe it or have it returned. From sketch is seems logical size isn't changing but physical is
<dael> AmeliaBR: Wouldn't they change at same or observing from change of writing mode?
<dael> dholbert: When writing mode changes they want notification? Not sure
<dael> AmeliaBR: Trickier. Observing size has changed and adding 2 entries to dictionary is straight forward. Changing what triggers observation is more complex
<dael> astearns: We have some questions and poster offered a more fleshed out use case so let's ask for more details on these questions.

[astearns]

@eeeps Thanks for opening this issue. We have some questions about the use case in the IRC log above. Could you look through and flesh out how you would use this extra information?

[eeeps]

So, my original use case was using ResizeObserver in order to load responsive images without sizes, ASAP after layout. Like this (view source).

That example uses the ResizeObserver v1 syntax (.contentRect.width+.height), assumes that images are extrinsically-constrained on width, and is not responsive to any changes after the initial layout. As soon as an <img> gets a width > 0, it says, "hey! this (still src-less) <img> has been laid out!" and inserts a src pointing to a resource that's a good fit for the observed, laid-out width.

After I sketched out this demo, I started wondering (probably inspired by @huijing) how all of this would work with the ROv2 syntax, and without making any assumptions about writing modes, and thought – wait – maybe it can't?

Here's an example page that swaps writing-modes at a breakpoint. With the either the v1 or v2 syntax, the listening-for-layout could be made robust to arbitrary writing-modes (and layouts!) by listening for both dimensions (inline and block), instead of just one, as my demo does. But when feeding the layout dimensions to an image CDN (or a sizes attribute, if whatwg/html#2973 ever gets resolved), you need to know which physical dimension you're dealing with: a height or a width. Knowing the block or inline size of the box doesn't help you (without also knowing the element's writing mode, which, I think, would require a .getComputedStyle, which [again I think] defeats some of the performance reasons for using ResizeObserver in the first place).

The art-directed hero image in the example suggests another interesting case. It's possible that an art-directed image could go from being, say, 1500w × 500h, to 500w × 1500h, at the breakpoint where the writing mode changes, and its inline and block sizes would remain unchanged. But clearly, anyone interested in the size of the image for any reason would want to know that such a drastic change had occurred.

[Loirooriol]

In #7564 we resolved to make the last remembered size logical since ResizeObserver tracks changes in the logical size.

A way to make ResizeObserver track changes in physical size would have allowed a physical last remembered size, which I'm not sure if it would be better, but it's what @tabatkins originally had in mind.

I guess:

• ResizeObserverOptions would have a new enum member with values "logical", "physical" or "both" (defaulting to "logical").
• ResizeObserverSize would have a new bool member to track whether the writing mode was vertical or horizontal. Possibly internal, and instead expose width and height getters that would map to the right size.
• isActive() would have to take the above into account.