Bug 221202 – Webkit doesn't calculate padding-top/-bottom in % correctly when parent has padding

• Component: Layout and Rendering
• Status: RESOLVED FIXED

Created attachment 418862 [details]
Test case

** Short description:

Webkit doesn't calculate height in % correctly when the parent element has padding, not even when `box-sizing: border-box;` is set. This applies to child elements with `height: 100%` and/or `padding-bottom: 100%`.

** Steps to reproduce:

1) Open the attached test-case (or http://testcase.rejh.nl/webkit-border-box-width-height-padding/) in Safari (Big Sur, Tech Prev 119, iOS and iPadOS 14.4) 
2) Observe that none of the red boxes are the same height as their parent (yellow) [*]
3) Open the same test-case in Chrome or Firefox.
4) All red boxes are the same height as their parents [**]

** Expected result:

All red boxes should be the exact same with/height as their parent [**]

** Actual result:

The red boxes do not account for their parent's padding when calculating 100% height/padding-bottom.

---

[*] All red boxes have a 10px top/left offset to better illustrate they are two elements.

[**] I've included two boxes that use the experimental `aspect-ratio` css property as these are currently available in Tech Preview. As expected, the only browser that supports this in 'stable' releases is currently Chrome v88. However, I did expect Safari TP 119 to work correctly as its changelog states:

* Added support for aspect-ratio on positioned elements (r271061)
* Changed to take aspect-ratio into account for percentage resolution (r271293)

It seems Webkit's implementation is not (yet) working as expected..?

Created attachment 418863 [details]
Result of test-case in Safari 14.0.2 on Big Sur

Created attachment 418864 [details]
Result of test-case in Chrome 88

Created attachment 418865 [details]
Test case v2

Updated test case where the first box's css was incorrect.

It looks like `height: 100%` *is* correctly calculated but only `padding-bottom: 100%` is not.

[Radar WebKit Bug Importer]

<rdar://problem/74093422>

[Smoley]

Thanks for filing, I'm seeing this issue reproduce on Safari 13.1.3 as well as TOT.

[Rob Buis]

Created attachment 427894 [details]
Patch

[Rob Buis]

Created attachment 427915 [details]
Patch

[EWS Watchlist]

This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess

[Rob Buis]

Created attachment 427923 [details]
Patch

[Rob Buis]

Created attachment 427975 [details]
Patch

[Rob Buis]

Created attachment 427976 [details]
Patch

[Manuel Rego Casasnovas]

Comment on attachment 427976 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=427976&action=review

r=me

> Source/WebCore/ChangeLog:9
> +        https://www.w3.org/TR/CSS2/visudet.html#containing-block-details (4.2).

Nit: Maybe you can link the new CSS specs here, as this is quite an old reference:
https://drafts.csswg.org/css-position-3/#absolute-positioning-containing-block

[Rob Buis]

Created attachment 430000 [details]
Patch

[EWS]

Committed r278194 (238237@main): <https://commits.webkit.org/238237@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 430000 [details].

[Ahmad Saleem]

*** Bug 133049 has been marked as a duplicate of this bug. ***