w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.43k stars 656 forks source link

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

Open trusktr opened 4 years ago

trusktr commented 4 years ago

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 commented 2 years ago

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 commented 1 year ago

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. 👍