According to your manual, “A” should be the same length as “B” but it is not. “A” is equal to the width of the blue rectangle, and i think that’s a bad idea. And mozilla does so too:
Note: It is often useful to set box-sizing to border-box to layout elements. This makes dealing with the sizes of elements much easier, and generally eliminates a number of pitfalls you can stumble on while laying out your content. On the other hand, when using position: relative or position: absolute, use of box-sizing: content-box allows the positioning values to be relative to the content, and independent of changes to border and padding sizes, which is sometimes desireable.
It seems our version of Yoga is not calculating the width correctly. We’ll see what we can do about it. Worst case, we’ll make sure the documentation describes the existing behaviour.
Thanks for the prompt answer. Very much appreciated. Let me clarify, from the perspective of a layout creating user, why i - and i’m sure the vast majority of web-developers would agree - think it’s bad:
The problem is the entanglement of concerns. When you add your padding and border to the width and start to fine-tune the layout, the changes propagate down the tree. That means, if you want the underlying structure to stay the same - and you probably would, that’s why you did it the way you did - you have to readjust it. But then maybe the child looks off again and you add another few pixels… and then again to the parent… and to the child… back and forth… until you say “well that’s good enough, i’ve got other things to do”. If you go for the border-box approach instead and subtract padding and border from the width, you can play with the values independently from the parent and find the result that makes your brain go aaaahhhh! so much quicker und without that frustration of wasted time. Finally, if you really want that effect of adding something to the width, you simply use a margin.
For me, in most situations, content-box is like a cheap screwdriver: You get the job done somehow, but the joy over your work is severely reduced by the blisters on your hand
We had a second look at the examples you shared with us and the result is that although it may seem counter intuitive, padding/border will not be deducted from the element’s size when using flex-grow parameters.
When recreating your UXML example in HTML or Yoga, one can observe that padding is actually added to the size making the element B larger than element A.
Hi team! is this bug fixed? I’m missing the box-sizing property so I guess it should be the default behavior but still the boxes sizes are being affected by the padding (which box-sizing fixes in html)