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
Current implementation of the useMeasure hook calculates the element bounds based on content-box model. It is a little unexpected behaviour when the project and all the layout is based on border-box model. Thus, current hook ignores paddings calculating element's width and height.
What is the new or updated feature that you are suggesting?
Suggesting adding the additional hook input parameter which has to define whether calculate content-box or border-box of the element.
Example of code calculating the border-box based content size:
const[observerHandler]=useRafCallback<UseResizeObserverCallback>((entry)=>{// For example:if(boxSizing==='border-box'){setMeasures({height: entry.borderBoxSize[0].blockSize,width: entry.borderBoxSize[0].inlineSize,});}else{setMeasures({width: entry.contentRect.width,height: entry.contentRect.height});}});
Why should this feature be included?
Mostly border-box model is used, and content-box calculations are unexpected behaviour as expected to calculate the box-sizing model needed. Makes sense to add optional parameter to override the initial box-sizing model of the calculation to prevent unexpected miscalculations and debugging.
The text was updated successfully, but these errors were encountered:
New Features
Current implementation of the
useMeasure
hook calculates the element bounds based oncontent-box
model. It is a little unexpected behaviour when the project and all the layout is based onborder-box
model. Thus, current hook ignores paddings calculating element'swidth
andheight
.What is the new or updated feature that you are suggesting?
Suggesting adding the additional hook input parameter which has to define whether calculate
content-box
orborder-box
of the element.Example of code calculating the
border-box
based content size:And extend this logic into current calculation:
Why should this feature be included?
Mostly
border-box
model is used, andcontent-box
calculations are unexpected behaviour as expected to calculate the box-sizing model needed. Makes sense to add optional parameter to override the initial box-sizing model of the calculation to prevent unexpected miscalculations and debugging.The text was updated successfully, but these errors were encountered: