This makes resizing work correctly for the examples here; a WPT reftest
version of the reduced testcase is included.
Note that this does *not* address cases where the orthogonal flow depends
more indirectly on the ICB size, as seen in bug 1953570.
Differential Revision: https://phabricator.services.mozilla.com/D247272
This makes resizing work correctly for the examples here; a WPT reftest
version of the reduced testcase is included.
Note that this does *not* address cases where the orthogonal flow depends
more indirectly on the ICB size, as seen in bug 1953570.
Differential Revision: https://phabricator.services.mozilla.com/D247272
We can't get text-align right during the initial table reflow because the
inline-size within which the cell content is to be aligned is not yet known
(it'll come from the block-size we compute for the parent row).
So to deal with this, we record during tableRowFrame reflow whether any
cells with orthogonal writing mode were present; and if so, at the end of
the row reflow, we make another pass over the orthogonal cells and reflow
them to properly align their content within the computed cell size.
Differential Revision: https://phabricator.services.mozilla.com/D245615
The table cell's inner frame itself will be shrink-wrapped, but we don't want to also
shrink-wrap its descendant blocks, as that prevents them being sized or aligned properly
to fit the cell.
So instead of checking whether the frame is orthogonal to mCBReflowInput (which may
still refer to the table-cell frame, whose writing mode does not reflect the writing
mode of its inner content), check against alignCB (the parent within which this frame
is aligned).
Differential Revision: https://phabricator.services.mozilla.com/D245148
The old "orthogonal limit" in ReflowInput was a rather ad hoc mechanism created
during the early implementation of writing modes, to avoid reflowing orthogonal
flows with unconstrained inline size. The spec has since been clarified to describe
the expected behavior in more detail, and we can dispense with the orthogonal-limit
concept and instead implement the constraints called for in the spec.
With this, we pass all the css-writing-modes/available-size-* tests (as well as
fixing a couple of other testcases that are dependent on this behavior).
Differential Revision: https://phabricator.services.mozilla.com/D241117
Reasoning with these functions gets confusing, because anchor
functions can become percentage as well as auto.
Defer optimization for now.
Differential Revision: https://phabricator.services.mozilla.com/D237098
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Try to resolve math function nodes with percentage basis of zero. Invalid
anchor functions will make the value Invalid-At-Computed-Value-Time (i.e.
`auto`), so that is handled. Otherwise, `CalcNode` existing indicates use
of percentage values and/or anchor functions. If only anchor functions
are used, we can use the resolved value as-is - otherwise, it must be
re-resolved before its value is queried.
This is of course redundant, and may require some optimization down
the line (We don' eagerly get percentage basis since that requires
ancestor traversal that may be wasted).
Differential Revision: https://phabricator.services.mozilla.com/D237095
Reasoning with these functions gets confusing, because anchor
functions can become percentage as well as auto.
Defer optimization for now.
Differential Revision: https://phabricator.services.mozilla.com/D237098
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Try to resolve math function nodes with percentage basis of zero. Invalid
anchor functions will make the value Invalid-At-Computed-Value-Time (i.e.
`auto`), so that is handled. Otherwise, `CalcNode` existing indicates use
of percentage values and/or anchor functions. If only anchor functions
are used, we can use the resolved value as-is - otherwise, it must be
re-resolved before its value is queried.
This is of course redundant, and may require some optimization down
the line (We don' eagerly get percentage basis since that requires
ancestor traversal that may be wasted).
Differential Revision: https://phabricator.services.mozilla.com/D237095
Reasoning with these functions gets confusing, because anchor
functions can become percentage as well as auto.
Defer optimization for now.
Differential Revision: https://phabricator.services.mozilla.com/D237098
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Try to resolve math function nodes with percentage basis of zero. Invalid
anchor functions will make the value Invalid-At-Computed-Value-Time (i.e.
`auto`), so that is handled. Otherwise, `CalcNode` existing indicates use
of percentage values and/or anchor functions. If only anchor functions
are used, we can use the resolved value as-is - otherwise, it must be
re-resolved before its value is queried.
This is of course redundant, and may require some optimization down
the line (We don' eagerly get percentage basis since that requires
ancestor traversal that may be wasted).
Differential Revision: https://phabricator.services.mozilla.com/D237095
Note that both keywords are disabled in the CSS parser for now, behind
these about:config prefs:
layout.css.stretch-size-keyword.enabled
layout.css.webkit-fill-available.enabled
Prior to this patch, we handled both keywords as pure aliases for
'-moz-available' (which has the correct 'stretch' behavior in the inline axis
but which just behaves like the initial value in the block axis).
This patch changes that so that 'stretch' and '-webkit-fill-available' will now
actually do the right thing in the block axis (if they're enabled at all, via
their aforementioned about:config prefs).
The relevant spec text here is:
https://drafts.csswg.org/css-sizing-4/#valdef-width-stretchhttps://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing
Differential Revision: https://phabricator.services.mozilla.com/D217688
And don't resolve them prematurely; the computed value should remain
logical, and only be mapped to physical sides at use time.
Differential Revision: https://phabricator.services.mozilla.com/D229998
And don't resolve them prematurely; the computed value should remain
logical, and only be mapped to physical sides at use time.
Differential Revision: https://phabricator.services.mozilla.com/D229998
