You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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. 👍
Otherwise we must call
getComputedStyle
on the observed element to get the value. There's otherwise no way to get thewriting-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 withblockSize
).This issue could be avoided if there were
verticalSize
andhorizontalSize
values instead ofinlineSize
andblockSize
, so that the vertical and horizontal sizing could be reliable without needing to look for the writing-mode value.The text was updated successfully, but these errors were encountered: