* Fix size of tables in flow layout
The contents of a table can make it bigger than what we would expect
from its 'width', 'min-width', 'height' and ' min-height' properties.
Also, 'width: auto' doesn't stretch it to fill the containing block.
We had to refactor the resolution of margins to happen after layout,
otherwise 'auto' margins wouldn't align correctly.
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
* Feedback
* Consistently use `containing_block_for_table` in table layout
* Update test result
---------
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
This deviates from css2, but it's mandated by css-align, and matches
what other browsers do when no margin is 'auto'.
When some margin is 'auto', this should keep the proper round-tripping
behavior that Gecko and WebKit lack, and Blink recently adopted.
This adds support for table rows, columns, rowgroups and colgroups.
There are few additions here:
1. The createion of fragments, which allows script queries and hit
testing to work properly. These fragments are empty as all cells are
still direct descendants of the table fragment.
2. Properly handling size information from tracks and track groups as
well as frustrating rules about reordering rowgroups.
3. Painting a background seemlessly across track groups and groups. This
is a thing that isn't done in legacy layout (nor WebKit)!
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This implements a very naive row height allocation approach. It has just
enough to implement `vertical-align` in table cells. Rowspanned cells
get enough space for their content, with the extra space necessary being
allocated to the last row. There's still a lot missing here, including
proper distribution of row height to rowspanned cells.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This change starts collecting the starting baseline set for fragments,
which is necessary for some layout modes (flex and tables, namely) as
well as being important for the implementation of `align-items`. In
addition, it converts baseline measurement to use `Au` everywhere.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* use app unit in replaced elements
* more app unit usage
* Avoid unnecessary into()
* Run ./mach fmt
* use scaleby
* update
---------
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* layout: Implement computation of table column widths
This change implements the various steps of table column width
computation, ignoring features that don't exist yet (such as separated
borders, column elements, and colgroups).
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* Fix an issue with the assignment of column percent width
* Respond to review comments
---------
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Shape text during InlineFormattingContext construction rather than doing
it twice during fragment tree construction. This is a step on the way
toward proper font fallback.
This also moves all `TextRun` related code into `text_run.rs` to try to
trim down the size of `inline.rs`.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by
`[X]` when the step is complete, and replace `___` with appropriate
data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because this should only have
performance impacts.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox
is checked, so that we can help you if you get stuck somewhere along the
way.-->
<!-- Pull requests that do not address these steps are welcome, but they
will require additional verification as part of the review process. -->
This is just a bit of code movement that trims down the size of the
`inline.rs` file in order to make it a bit more manageable. It leads the
way to more refactoring and cleanup in the future.
* layout: Implement support for `line-height` and `vertical-align`
This is an initial implementation of proper `line-height` and
`vertical-align` support. While this change includes the bulk of the
work there are still many missing pieces for full support. In particular
some big missing things are:
- Flex containers do not properly compute their baselines. The idea is
to tackle this in a followup change. This causes various flex tests
to start failing because everything used to be top aligned.
- The implementation of the line-height quirks (only active in quirks
mode) are incomplete. While the quirk works in many cases, there are
still some cases where it is handled incorrectly. This requires more
redesign and refinement, better suited for a followup.
- Most of the features are CSS 3 such as precision control of the
baseline and first and last baselines are not implemented. This
change gets us close to CSS 2.x support.
While there are many new test passes with this change some tests are
starting to fail. An accounting of new failures:
Tests failing also in Layout 2013:
- /css/css2/positioning/toogle-abspos-on-relpos-inline-child.html (only passes in Chrome)
- /css/CSS2/fonts/font-applies-to-001.xht (potentially an issue with font size)
Invalid tests:
- /css/CSS2/visudet/inline-block-baseline-003.xht
- /css/CSS2/visudet/inline-block-baseline-004.xht
- These are are failing in all browsers. See https://bugs.chromium.org/p/chromium/issues/detail?id=1222151.
Missing table support:
- /_mozilla/mozilla/table_valign_middle.html
Missing `font-size-adjust` support :
- /css/css-fonts/font-size-adjust-zero-2.html (also failing in 2013)
Incomplete form field support :
- /html/rendering/widgets/the-select-element/option-add-label-quirks.html (label isn't rendered so button isn't the right size in quirks mode due to line height quirk)
Need support for calculating flexbox baseline:
- /css/css-flexbox/fieldset-baseline-alignment.html
- /css/css-flexbox/flex-inline.html
- /css/css-flexbox/flexbox-baseline-multi-line-horiz-001.html
- /css/css-flexbox/flexbox-baseline-single-item-001a.html
- /css/css-flexbox/flexbox-baseline-single-item-001b.html
Failing because we don't create anonymous inline boxes for text children of blocks:
- /css/CSS2/linebox/anonymous-inline-inherit-001.html
Passes locally (potentially related to fonts):
- /css/CSS2/css1/c414-flt-fit-004.xht
- /css/css-transforms/transform-input-017.html
- /html/obsolete/requirements-for-implementations/the-marquee-element-0/marquee-min-intrinsic-size.html
- /css/css-fonts/first-available-font-005.html
- /css/css-fonts/first-available-font-006.html
* Some cleanups after live review with @mukilan
Also update results.
This adds support for fixing up tables so that internal table elements
that are not properly parented in the DOM have the correct box tree
structure according to the CSS Table specification [1]. Note that this
only comes into play when building the DOM via script, as HTML 5 has its
own table fixups that mean that the box tree construction fixups here
are not necessary.
There are no tests for this change. In general, it's hard to write tests
against the shape of the box tree, because it depends on the DOM. We
plan to test this via WPT tests once layout is complete.
1. https://drafts.csswg.org/css-tables/#table-internal-element
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
When a box has overflow, any floats placed in that box will lower the
float ceiling into the overflow. If no float is placed in the box
though, the ceiling should be the block position where the overflow
starts. We already know where this is, because we might be passing a
negative value for the new block position after processing a box
(content_size - actual_size would be negative). This negative value
never raises the ceiling though since a maximum is used.
In the case that there is overflow, this change allows raising the
ceiling, but never passed the lowest float. This necessitates keeping
two values for the ceiling: one for floats and one for non-floats.
Fixes#30304.
This makes the names of flow relative geometry consistent with what is
used in the style crate and removes them from a module. With this change
it's more obvious what makes these types different from the ones in
`euclid`.
In the first phase, we gather LineItems and then when we have enough to
form a line we turn them into Fragments. This will make it possible to
more simply implement `vertical-align` and `text-align: justify` because
we need to measure the different aspects of the candidate line and then
produce a Fragments.
This is a general refactor of the way that inline layout works, so comes
with some progressions. In addition there are some new failures.
New failures:
Some tests are now failing because only the test or reference is getting
proper line height when it wasn't before. These should be fixed in a
followup change that properly calculate line-height in more cases:
- /_mozilla/css/list_style_position_a.html
- /css/CSS2/floats/float-no-content-beside-001.html
- /css/css-content/pseudo-element-inline-box.html
- /css/css-flexbox/flexbox_flex-none-wrappable-content.html
Some tests are now failing because floats are now placed properly, but
are no longer in their inline box stacking contexts. These will be fixed
by a followup change which properly parents them:
- /css/filter-effects/filtered-inline-applies-to-float.html.ini
- /css/css-color/inline-opacity-float-child.html.ini
One test is failing due to floating point precision errors:
- /css/CSS2/floats-clear/floats-141.xht.ini
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Avoid solve_containing_block_padding_border_and_margin_for_in_flow_box()
for a block-level box that establishes an independent formatting context
(or is replaced) in the presence of floats, since the margins and inline
size could then be incorrect.
No actual change in behavior: this patch still resolves the margins
incorrectly with solve_block_margins_for_in_flow_block_level(),
and also keeps the old logic for width:auto.
However, this refactoring prepares the terrain to address these issues
in #30072 and #30057.
With direction:ltr (and we don't support direction:rtl yet), the rules
from https://drafts.csswg.org/css2/#blockwidth imply that margin-left
shouldn't resolve auto to a negative amount.
This aligns Servo with Gecko and Blink. WebKit may resolve to a negative
amount in some cases.
When descending and we have the option, don't create new
PositioningContexts just to update the static position of laid out
abspos descendants. Instead, use the new PositioningContextLength to
only update the newly added hoisted abspos boxes.
Just use clamp_between_extremums() to resolve the inline size, and then
only call solve_inline_margins_for_in_flow_block_level() once.
There should be no change in behavior.
Consumers of PlacementAmongFloats weren't handling margins properly.
They were assuming that they would either get a positive adjustment,
or zero for no-op.
However, just like the regular clearance triggered by 'clear', the
clearance added onto blocks that establish an independent FC can be
zero or negative, and the effect is different than having no clearance.
Calculating the max-content size of a block container may add the outer
max-content sizes of multiple children. The problem is that the outer
size may be negative (due to margins), producing an incorrect result.
In particular, it could happen that the max-content size was 50-25=25,
but the min-content size would just take the maximum and be 50, which
doesn't make sense.
Therefore, this patch floors the size of all children by 0. This seems
to match Blink. Firefox and WebKit don't floor in some cases, but then
the result seems suboptimal to me. Note that there is no spec for this,
see https://github.com/w3c/csswg-drafts/issues/9120 for details.
A block that establishes an independent formatting context is placed
next to previous floats, so we should add their sizes when computing
the intrinsic contribution of the parent block container.
Remove rayon_croissant and refactor the way that information about
floats in flows bubbles up. This simplifies the code a good deal and
lets us take advantage of some more optimized functions provided by
rayon. This removes 2 crates from the dependency tree.
In addition, this allows avoiding passing `contains_floats` up from
every box tree construction function. This makes things simpler, but
also opens up the possibility of passing more of these flags up in the
future (such as `contains_counters`).
calculate_inline_content_size_for_block_level_boxes was relying on
inline_content_sizes to get the size of each block-level box child.
For absolutely positioned boxes, this was 0x0.
That was no-op before #29887, but then it prevented adding the sizes
of a sequence of floats. Abspos should just be ignored instead of
treated as 0x0.
This patch removes inline_content_sizes, moves the logic into
calculate_inline_content_size_for_block_level_boxes (the only caller),
and handles abspos correctly.
* Place replaced and non-auto inline size independent FCs next to floats
The CSS2 specification says that replaced content and independent
formatting contexts should be placed next to floats. This change adds
support for that, but punts on support for independent formatting
contexts that have an auto inline size. With an auto inline size, we
which requires a much more complex layout algorithm.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
* Fix issue with where last band was taken into account for inline size
* adjustment_from_floats should prevent margin collapse
* Properly handle elements with 0 height
---------
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This function is already quite big and the changes necessary for
properly laying out independent formatting contexts next to floats will
make it even more unwieldy. Split the function in two and add a helper
for calculating the containing block for children and the margin. As
time goes on the independent formatting case is probably going to be
more like the replaced case anyway.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
Every time that we would lay out a block box that could collapse its
top margin with its contents, we would do a lookahead to compute the
resulting margin in order to place floats correctly.
The problem was that this lookahead could iterate several descendants,
but then when laying these we would run the lookahead again.
This patch restricts the lookahead to boxes that either aren't collapsing
their top margin with their parent, or that have 'clear' different than
'none' (since clearance prevents collapsing margins with the parent).
Since the lookahead stops iterating when it finds a box that doesn't
collapse its top margin with its parent, or whose 'clear' isn't 'none',
this should ensure that lookahead never handles the same box twice.
Check computed (min-)block-size when determining margin collapse
To collapse margins through, CSS2 requires "zero or auto computed height" and "zero computed min-height" (the latter should also also include auto, which was introduced in CSS3 as the new initial value).
Similarly, "auto computed height" is required to collapse the bottom margin with the bottom margin of the contents.
Therefore this patch stops collapsing when the used height is clamped to zero by max-height, but the computed value is not zero. Same for non-zero percentages that are indefinite or that resolve to 0px.
Note that 0% and calc(0% + 0px) are still considered to be zero (so they allow margin collapse), this may a bit inconsistent but matches Firefox (for the collapsing through case).
This also matches the heuristics in find_block_margin_collapsing_with_parent(). We could change the heuristics instead, but then they would have to track block sizes in order to be able to resolve percentages.
The change makes margin-collapse-through-percentage-height-block.html fail, that test is only passing on Blink, which did a different interpretation of the spec. To be fair, various places of CSS2 loosely consider that indefinite percentages compute to auto, and even Firefox does so when determining whether to collapse the top margin with the contents.
Since the spec isn't particularly clear and interoperability is lacking, I filed https://github.com/w3c/csswg-drafts/issues/8919.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#29907
- [X] There are tests for these changes (1 test fails, see above)
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Padding percentages weren't being resolved, this function would think
that margins wouldn't collapse even if the percentage resolved to 0px.
And margin percentages were always resolved to 0px.
So now the function takes a ContainingBlock parameter that is used to
resolve these percentages properly.
To collapse margins through, CSS2 requires "zero or auto computed height"
and "zero computed min-height" (the latter should also also include auto,
which was introduced in CSS3 as the new initial value).
Similarly, "auto computed height" is required to collapse the bottom margin
with the bottom margin of the contents.
Therefore this patch stops collapsing when the used height is clamped
to zero by max-height, but the computed value is not zero. Same for
non-zero percentages that are indefinite or that resolve to 0px.
Note that 0% and calc(0% + 0px) are still considered to be zero (so they
allow margin collapse), this may a bit inconsistent but matches Firefox
(for the collapsing through case).
This also matches the heuristics in find_block_margin_collapsing_with_parent().
We could change the heuristics instead, but then they would have to track
block sizes in order to be able to resolve percentages.
The change makes margin-collapse-through-percentage-height-block.html fail,
that test is only passing on Blink, which did a different interpretation
of the spec. To be fair, various places of CSS2 loosely consider that
indefinite percentages compute to auto, and even Firefox does so when
determining whether to collapse the top margin with the contents.
Since the spec isn't particularly clear and interoperability is lacking,
I filed https://github.com/w3c/csswg-drafts/issues/8919.
Properly position floats when subsequent boxes collapse margins with containing block (2)
PR #29939 tried to address this but missed various cases.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#29944
- [X] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Clearance was implemented as a Length, where zero meant no clearance.
However, having a clearance of 0px should be different than having
no clearance, since the former can still prevent margin collapse.
This patch keeps the existing behavior, so it won't be possible to get
a clearance of Some(Length::zero()), but it prepares the terrain for
a follow-up to fix calculate_clearance to return the proper thing.
Margins should be able to collapse through floats when collapsing with
parent blocks (the containing block). To properly place floats in this
situation, we need to look at these subsequent floats to find out how
much of the margin will collapse with the parent.
This initial implementation is very basic and the second step would be
to cache this in order to avoid having to constantly recalculate it.
Fixes#29915.
Co-authored-by: Oriol Brufau <obrufau@igalia.com>