fix(splitter): improving sizing calculations in percent splitter #13252 - master

[ChronosSF]

Closes #13252

Additional information (check all that apply):

• Bug fix
• New functionality
• Documentation
• Demos
• CI/CD

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code (test guidelines)
• This PR includes API docs for newly added methods/properties (api docs guidelines)
• This PR includes feature/README.MD updates for the feature docs
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes ng update migrations for the breaking changes (migrations guidelines)
• This PR includes behavioral changes and the feature specification has been updated with them

[mddragnev]

There is still ~1 px of orange background (as in the sample) when reproducing the issue. Probably because you are reducing the delta too much when calculating the maximum delta.

[ChronosSF]

There is still ~1 px of orange background (as in the sample) when reproducing the issue. Probably because you are reducing the delta too much when calculating the maximum delta.

Yeah I noticed but my belief is that it actually comes from imperfection of the percent calculations when the browser tries to render them with subpixel precision combined with the presence of the splitter element. Before the fix, what would happen is that the pane getting enlarged would receive additional size because it didn't take the minimum size of the shrinking panel into account when determining max size during the drag. This made the percentages exceed 100% and all kinds of weird issues coming from that.

I'd say that if you can't reproduce this with pixel resizing, we can probably leave it as is unless you have other ideas.

[mddragnev]

If you set the size of the first pane, i.e

 <igx-splitter-pane [size]="'300px'" [minSize]="'150px'"> ... </igx-splitter-pane> 

and leave the second pane to be percentage sized then the gap becomes even more

which again is because the panesize+siblingSize in px does not add up to the total size

[ChronosSF]

As discussed with @MayaKirova , I added flex-grow/shrink for % panes to ensure this doesn't require resize observer.