This will be required for percentages to resolve against it correctly
after we make set_content_height() not automatically mark heights as
definite sizes.
Before this change, we were always assigning the calculated height to
each block container after laying it out in BFC.
This should really only happen during intrinsic sizing, since that is
how measurements are communicated to the client there.
This makes them cheap to move around, since we can store them in a
NonnullOwnPtr instead of memcopying 2584(!) bytes.
Drastically reduces the chance of stack overflow while building the
layout tree for deeply nested DOMs (since tree building was putting
these things on the stack).
This change also exposed a completely unnecessary ComputedValues deep
copy in block layout.
Until now, we had implemented flex container sizing by awkwardly doing
exactly what the spec said (basically having FFC size the container)
despite that not really making sense in the big picture. (Parent
formatting contexts should be responsible for sizing and placing their
children)
This patch moves us away from the Flexbox spec text a little bit, by
removing the logic for sizing the flex container in FFC, and instead
making sure that all formatting contexts can set both width and height
of flex container children.
This required changes in BFC and IFC, but it's actually quite simple!
Width was already not a problem, and it turns out height isn't either,
since the automatic height of a flex container is max-content.
With this in mind, we can simply determine the height of flex containers
before transferring control to FFC, and everything flows nicely.
With this change, we can remove all the virtuals and FFC logic for
negotiating container size with the parent formatting context.
We also don't need the "available space for flex container" stuff
anymore either, so that's gone as well.
There are some minor diffs in layout test results from this, but the
new results actually match other browsers more closely, so that's fine.
This should make flex layout, and indeed layout in general, easier to
understand, since this was the main weird special case outside of
BFC/IFC where a formatting context delegates work to its parent instead
of the other way around. :^)
Similar to calculate_inner_width(), let's make the caller responsible
for handling "auto" instead of returning the input height as is when
when it cannot be resolved.
Initially, this function was made to return CSS::Length because some of
its callers were expecting it to ignore "auto" width on input and
return it as is. Instead, let's just forbid using "auto" for input
width and always return CSSPixels.
According to the CSS font matching algorithm specification, it is
supposed to be executed for each glyph instead of each text run, as is
currently done. This change partially implements this by having the
font matching algorithm produce a list of fonts against which each
glyph will be tested to find its suitable font.
Now, it becomes possible to have per-glyph fallback fonts: if the
needed glyph is not present in a font, we can check the subsequent
fonts in the list.
Setting the marker's content width here is causing the text that follows
the marker to be indented a bit too much. This is noticeable when a line
with a disclosure marker is followed by a line with any other marker. It
previously would look something like:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
Now the disclosure marker line matches other marker types:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
This commit removes DeprecatedString's "null" state, and replaces all
its users with one of the following:
- A normal, empty DeprecatedString
- Optional<DeprecatedString>
Note that null states of DeprecatedFlyString/StringView/etc are *not*
affected by this commit. However, DeprecatedString::empty() is now
considered equal to a null StringView.
Before, we only ensured that boxes establishing BFC did not overlap
with floats because that is what CSS 2.2 specification says. However,
we should also apply the same for boxes establishing FFC or GFC as this
aligns with the behavior of other browsers.
Fixes https://github.com/SerenityOS/serenity/issues/21095
When calculating the edge offset of the next floating item based on the
offset of the preceding floating item, we need to ensure that the
preceding offset is always > 0. This isn't explicitly written in the
spec, but all other popular engines do that.
Fixes https://github.com/SerenityOS/serenity/issues/21023
Before, we completely ignored clearance for block-level boxes if they
were floated. This was incorrect because it is valid for a block-level
box to be floated and still have clearance. However, unlike clearance
on normal flow boxes, clearance on floating boxes does not affect the
y-position of subsequent normal flow boxes. Instead, it pushes the
box's position to the very beginning of an edge.
Work towards https://github.com/SerenityOS/serenity/issues/21023
Previously we always set the height of the HTML element equal to the
viewport height but now this will only happen in quirks mode as it is
intended. Otherwise the html element height will be computed as auto.
Since we always pass the px value as an argument to resolved(), we can
pass it directly as CSSPixels instead of wrapping it in Length. This
approach allows us to avoid converting to a double, resulting in fewer
precision issues.
This is intended to annotate conversions from unknown floating-point
values to CSSPixels, and make it more obvious the fp value will be
rounded to the nearest fixed-point value.
In general it is not safe to convert any arbitrary floating-point value
to CSSPixels. CSSPixels has a resolution of 0.015625, which for small
values (e.g. scale factors between 0 and 1), can produce bad results
if converted to CSSPixels then scaled back up. In the worst case values
can underflow to zero and produce incorrect results.
Changing `calculate_min_content_heigh()` and
`calculate_min_content_heigh()` to accept width as `CSSPixels`, instead
of `AvailableSize` that might be indefinite, makes it more explicit
that width is supposed to be known by the time height is measured.
This change has a bit of collateral damage which is rows height
calculation regression in `table/inline-table-width` that worked before
by accident.
Using avilable space directly while resolving table container width
allows to avoid assigning it to table wrapper box content width which
sometimes involves infinite (saturated) values.
Also this allows to get rid of set_max_content_width() which is a hack
that allows to bypass set_content_width() to assign infinite
(saturated) width to a box.
Closes https://github.com/SerenityOS/serenity/issues/19521
Returning greatest_child_width() from automatic_content_width() in BFC
if root box children are inline and there are min/max-width that caused
width to be changed after IFC layout while content_width should be
always set to correct value by layout_inline_children() regardless of
layout mode.
I'm not sure if this is exactly correct, the link to CSS2 spec above
says something that clearance cannot separate boxes, but I'm not sure if
I understood it correctly or if I've done it in the right place.
However, this change fixes our block-and-inline/clearfix.html test again
(was regressed in previous commit).
Pseudo-elements like ::before and ::after were discarded when their
content property was an empty string (ignoring whitespace), because they
are anonymous containers with no lines.
Our previous way around it was to add an empty line box (see b062a0fb7c)
however it didn't actually work for cases described in the previous
commit.
This makes avatars and cover arts square on last.fm and "fixes" the test
css-pseudo-element-should-not-be-affected-by-presentational-hints.html.
Unfortunately, this also regresses on block-and-inline/clearfix.html,
but that hopefully will be handled in subsequent commit.
Allow the left margin of a box which creates a block formatting context
to overlap with left floating boxes which are siblings in the document
tree.
Fixes#20233 and the comment layout on https://lobste.rs.
In particular, in BFC:
- Non-floating, non-replaced elements
- Floating, non-replaced elements
- Floating, replaced elements
The first two regressed in 1d76126abe
The third one seems to have been introduced by this regression, as it
was seemingly copied from compute_width_for_floating_box in
7f9ede07bc
With multi-line text cells, we don't reliably know the height would stay
the same as the one set by the independent format context run. In such
situations, we can end up with a table box which is sized inconsistently
with the grid boxes of the table due to differences in line breaks.
In compute_table_box_width_inside_table_wrapper, we should only consider
available_width when it's valid. Values which come from {min,
max}-content constraints aren't meaningful and shouldn't be considered
for the cap.
When resolving a percentage min-width or min-height size against a
containing block currently under a min-content constraint, we should act
as if the containing block has zero size in that axis.
This is technically "undefined behavior" per CSS 2.2, but it seems
sensible to mirror the behavior of max-height in the same situation.
It also appears to match how other engines behave.
Fixes#19242
The margin from the containing blocks shouldn't be included in the
amount by which we increment x after a float was places. That coordinate
should be relative to the containing block.
Fixes the comments layout on https://lobste.rs.
