Search Issue Tracker

By Design

Votes

0

Found in

6000.0.54f1

6000.1.14f1

6000.2.0b12

6000.3.0a3

Issue ID

UUM-113019

Regression

No

UI Toolkit child elements get squashed when margin with percentage value is used and parent's size is set to "auto"

-

How to reproduce:
1. Open the “UIBugs.zip“ project
2. Open the “RecipeTest.uxml“ file in UI Builder
3. Select and compare the “Item“ elements under “PinContainer-Percent“ and under “PinContainer-Pixel“ in the UI Builder’s viewport

Expected result: The elements look the same (circular)
Actual result: The elements under “PinContainer-Percent“ look a bit squashed (oval)

Reproducible in: 2023.1.0a1, 6000.0.54f1, 6000.1.14f1, 6000.2.0b12, 6000.3.0a3

Reproduced on: Windows 11 Pro (24H2)
Not reproduced on: No other environment tested

Notes:
- How squashed the elements look depends only on the Margin of the element - the bigger the margin, the more squashed the element will look
- The element will become circular if the parent’s height is set 1 pixel more than the element’s height (101 px), or the width is set to 0px
- Does not reproduce with pixel type values

  1. Resolution Note:

    Since the size of the parent is auto, when the intrinsic with is measured (the natural with that would fit all children) the margins in percentage are evaluated at that point at 0 because the size of the parent is unknown/undetermined.

    This causes a difference in the size of the parent when the child have margins expressed in percentage. Then, since margins in percentage are applied afterwards, the there is not ennough space for the child and the flex-shrink=1 enable the child to reduce their vertical size until everything fits. This causes them to be "squished"

    From the last published CSS spec: https://www.w3.org/TR/css-flexbox-1

    4.2. Flex Item Margins and Paddings

    Percentage margins and paddings on flex items, like those on block boxes, are resolved against the inline size of their containing block, e.g. left/right/top/bottom percentages all resolve against their containing block’s width in horizontal writing modes.

    4.5 For the purpose of calculating an intrinsic size of the box (e.g. the box’s min-content size), a content-based minimum size causes the box’s size in that axis to become indefinite (even if e.g. its width property specifies a definite size). Note this means that percentages calculated against this size will behave as auto.

    9.2.4 Determine the main size of the flex container using the rules of the formatting context in which it participates. For this computation, auto margins on flex items are treated as 0.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.