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
Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was
18
Description
When there are multiple sticky columns and a column has the writing-mode: vertical-lr CSS rule applied (and assuming it is not the last sticky column), the table does not calculate the width of the column correctly. It uses the default horizontal-tb mode to calculate the width and uses that instead, causing subsequent sticky columns to overlap with non-sticky columns and creates a blank space between the column with the vertical-lr rule and the next sticky column.
Is this a regression?
The previous version in which this bug was not present was
18
Description
When there are multiple sticky columns and a column has the
writing-mode: vertical-lr
CSS rule applied (and assuming it is not the last sticky column), the table does not calculate the width of the column correctly. It uses the defaulthorizontal-tb
mode to calculate the width and uses that instead, causing subsequent sticky columns to overlap with non-sticky columns and creates a blank space between the column with thevertical-lr
rule and the next sticky column.Reproduction
StackBlitz link: https://stackblitz.com/edit/components-issue-starter-6mfsadjh?file=src%2Fmain.ts,package.json
Steps to reproduce:
width: 100%
to force column compressionExpected Behavior
The second column should have a
left
value that matches the width of the first column.Actual Behavior
The second column uses unrotated column width as its
left
valueEnvironment
The text was updated successfully, but these errors were encountered: