1651776 - [css-sizing-4] Should aspect-ratio be used for abspos `top: 0; bottom: 0;`?

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Mozilla Apprentice]

A resolution was made for csswg-drafts/#5151.

[css-sizing-4] Should aspect-ratio be used for abspos `top: 0; bottom: 0;`?

• RESOLVED: Accept proposal

Discussion.

Comment 1

[Boris Chiou [:boris]]

The linked wpt: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/css-sizing/aspect-ratio/abspos-004.tentative.html

Comment 2

[Boris Chiou [:boris]]

OK. I think we should fix all the absolute postion issues when we apply aspect-ratio: https://drafts.csswg.org/css-position/#abspos-auto-size in this bug.

Comment 3

[Boris Chiou [:boris]]

Attachment: Bug 1651776 - Move Compute{Inline|Block}SizeFromAspectRatio() into AspectRatio struct.

Comment 4

[Boris Chiou [:boris]]

Attachment: Bug 1651776 - aspect-ratio should be used for abspos when insets on the block axis are specified.

First, we have to handle zero width (e.g. width:auto or width:0) case properly
for aspect-ratio. We shouldn't resolve the block size when inline size
is 0 by a finite-ratio aspect-ratio becasue it doesn't make sense.

However, this may have impact for width:auto on the absolute position
element, which may resolve the auto inline size as 0.
IMO, we shouldn't resolve the block size by zero inline-size and a
finite aspect-ratio. This may fail the condition check
(i.e. computedSize.BSize(cbwm) == NS_UNCONSTRAINEDSIZE) in ReflowInput
when resolving the auto block size by insets.

Based on https://github.com/w3c/csswg-drafts/issues/5151,
if the block size is auto, we still can use the insets to resolve the auto
block size on absoluate position elements, so we still can use this resolved
block size to calculate the inline size through aspect-ratio.

Comment 5

[Boris Chiou [:boris]]

Attachment: Bug 1651776 - Factor out the common function which computes the inline size by the resolved block size and aspect-ratio.

Those if-checks and computation could be factored out as a common function.
Besied, I use the "inline" term for the current element, instead of
the containing block.

Comment 6

[Boris Chiou [:boris]]

Attachment: Bug 1651776 - Refine the terminology of writing modes when handling unconstrained block-size on out-of-flow boxes.

I'd like to handle aspect-ratio in those code block, so it'd be better
to always handle unconstrained block-size on the writing mode of the current
block. Besides, we move it as a method of ReflowInput.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7a0000c0272f
Move Compute{Inline|Block}SizeFromAspectRatio() into AspectRatio struct. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/0f9d01688ca8
Refine the terminology of writing modes when handling unconstrained block-size on out-of-flow boxes. r=TYLin
https://hg.mozilla.org/integration/autoland/rev/e65987e878dc
aspect-ratio should be used for abspos when insets on the block axis are specified. r=TYLin

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/26600 for changes under testing/web-platform/tests

Comment 9

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/7a0000c0272f
https://hg.mozilla.org/mozilla-central/rev/0f9d01688ca8
https://hg.mozilla.org/mozilla-central/rev/e65987e878dc

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot