Skip to content

[resize-observer] Shouldn't ResizeObserverEntry contain writing-mode values? #5486

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
trusktr opened this issue Aug 30, 2020 · 2 comments
Open

Comments

@trusktr
Copy link

trusktr commented Aug 30, 2020

Otherwise we must call getComputedStyle on the observed element to get the value. There's otherwise no way to get the writing-mode as far as I know.

The callback's handling code may needs to know whether to use inlineSize as width or as height (and similar with blockSize).

This issue could be avoided if there were verticalSize and horizontalSize values instead of inlineSize and blockSize, so that the vertical and horizontal sizing could be reliable without needing to look for the writing-mode value.

@Loirooriol
Copy link
Contributor

Otherwise we must call getComputedStyle on the observed element to get the value

That's actually unreliable, since the writing mode might have changed since the ResizeObserverEntry was created:

/* script 1 */
new ResizeObserver(([entry], ro) => {
  ro.disconnect();
  entry.target.style.writingMode = "vertical-lr";
}).observe(document.documentElement);

/* script 2 */
document.documentElement.style.cssText = "width: 100px; height: 50px";
new ResizeObserver(([entry], ro) => {
  ro.disconnect();
  const isHorizontal = getComputedStyle(entry.target).writingMode.startsWith("horizontal");
  const [{blockSize, inlineSize}] = entry.contentBoxSize;
  const width = isHorizontal ? inlineSize : blockSize;
  const height = isHorizontal ? blockSize : inlineSize;
  console.log(`${width}x${height}`); // 50x100 !!!
}).observe(document.documentElement);

What you can do is use contentRect, but "is only included for current web compat reasons. It may be deprecated in future levels". Also, bad luck if the content area is a square, but you want the physical dimensions of the border area which is not a square; there is no borderRect or such.

This issue could be avoided if there were verticalSize and horizontalSize values instead of inlineSize and blockSize

Removing inlineSize and blockSize seems a bad idea, because ResizeObserver is inherently logical. If the physical dimensions are swapped but the logical ones stay the same, then no observation is notified. That is, ResizeObserver tracks changes to the logical dimensions, so not exposing them seems wrong.

Also, verticalSize and horizontalSize are usually called height and width.

Shouldn't ResizeObserverEntry contain writing-mode values?

The exact writing-mode may not be needed, only whether it's vertical or horizontal.

So one option could be exposing all inlineSize, blockSize, width and height with getters that resolve to the right thing. Internally, the browser would only need to store 2 sizes and 1 bit for the verticality.

@trusktr
Copy link
Author

trusktr commented Jun 17, 2023

width/height is much better indeed, and re-reading the OP I'm not sure why I expressed having these properties "instead of" the other ones. Adding additional width/height properties makes sense. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants