Before we ask a replaced box about its intrinsic dimensions, we have
to "prepare" the box, which tells it to go and work out what its
intrinsic dimensions are.
I've added a FIXME about how this is silly (and clearly bug-prone)
but this patch only patches it locally in FFC for now.
Previously, floating elements computed the width by only using the
`width` property. Now, they will also use the `min-width` and
`max-width` properties. :^)
The new steps are from "10.4. Minimum and maximum widths: 'min-width'
and 'max-width'" in the CSS 2 spec.
Found it when looking at curl.se.
The spec grammar for `text-decoration-line` is:
`none | [ underline || overline || line-through || blink ]`
Which means that it's either `none`, or any combination of the other
values. This patch makes that parse for `text-decoration-line` and
`text-decoration`, stores the results as a Vector, and adjusts
`paint_text_decoration()` to run as a loop over all the values that are
provided.
As noted, storing a Vector of values is a bit wasteful, as they could be
stored as flags in a single `u8`. But I was getting too confused trying
to do that in a nice way.
By the time that property() gets called, we've already given every
single property a value, so we can just return it. This simplifies a
lot of places that were manually handling a lack of value
unnecessarily.
This function was written as if it returned `Optional<CSS::BoxSizing>`
but actually returned a plain `CSS::BoxSizing`, meaning if the property
was not set or was invalid, it would return whichever enum value was
first. This wasn't visible because we don't yet pay any attention to
the `box-sizing` property.
For inline-blocks and inline replaced elements, we previously fell into
a code path that tried to find a corresponding line box fragment to
invalidate. However, we don't need to do any of that, all we need to do
is get the absolute rect from our paintable, and invalidate that.
This makes CRC2D invalidations happen immediately instead of as a side
effect of some other invalidation.
When calling layout_inside() on a flex item that can't have children of
its own, layout_inside() will not return an independent formatting
context, so we need to handle that case here.
This is a hack that allows block-level replaced elements to be flex
items. Flexbox layout currently assumes (in many places) that it's
always possible to create an independent formatting context for each of
its items.
AFAICT, css-values-4 tells us that clamping numbers to a range where
min>max is okay. That means we can't use AK::clamp() since it will
VERIFY that max>=min.
This patch adds a css_clamp() helper (locally in FFC for now).
This fixes an issue where a bunch of sites were crashing due to the
VERIFY in AK::clamp().
We were mistakenly treating inline replaced elements as if they are the
start of a regular display:inline element. This meant that we collected
the horizontal start and end metrics from the box model, and then added
those to the inline-level item produced by InlineLevelIterator.
This effectively meant that <img>, <svg> and other replaced elements got
double-sized values for margin/border/padding on the left and right
sides. (Which manifested as a mysterious margin around the element.)
Change "compute" to "calculate" to make clearer that this is unrelated
to the CSS "computed height" concept.
Change "intrinsic" to "auto" to make clearer that this is not the same
as the intrinsic min-content and max-content sizing calculations.
When running the min-content and max-content sizing algorithms and the
target box creates a flex formatting context, we don't need to measure
its children.
FFC has already assigned the content_width and content_height values,
so we just need to pick those up from the container's formatting state.
This patch adds support for MinContent and MaxContent layout to FFC.
This means that an FFC can now calculate intrinsic sizes for the flex
container, to be used by the parent formatting context.
There are some FIXME's as usual, but this already works on basic things.
If white-space is nowrap then we don't want to break a text_node
into multiple line boxes. This fixes the width calculation in the
min-content case for white-space: nowrap elements. Before this
the min-width would be the width of the biggest line box.
We had an issue with computing a width of a block in MaxContent
mode because we would set the width of the containing block to
infinity which would make everything in the try_compute_width
block infinity as well.
This adds a special case for width = 'auto' when
width_of_containing_block is infinity and removes the width of
containing block from the equation entirely.
This builds on the work done by implementing the flex order CSS
property and implements flex reverse layouts by just reversing
the order and the items within each order bucket.
While calculating the minimum size for main min/max size violations
we were flooring the min size to 0 if the item doesn't have a min
main size. Instead of that determine the intrinsic min main size
of that element.
This fixes the flex: 80% 0 4/1/0 test case in the flex.html
test page.
This case was missed in a previous commit that added the
determine_min_main_size_of_child function
Before if an element didn't have a main min size we would clamp
it to a literal zero. If that element also had a flex-basis 0
it's width would end up being 0.
This patch adds a determine_min_main_size_of_child function that
will calculate the minimum main size for the box based on the
content of the box.
We use the result of that function now instead of clamping
the element main min size to 0.
This also adds one more box to the flex.html test page, which is
the same flex: 0 0 0 box but with flex-direction: column.
For computing height in FormattingContext::calculate_intrinsic_sizes
we were calling into BlockFormattingContext::compute_theoretical_height
which will check if the CSS height property was defined and calculate
the height based on that instead of calculating the intrinsic height
This patch adds a new function calculate_intrinsic_height, which will
call into compute_auto_height_for_block_level_element for a block
element, or into compute_height_for_replaced_element for a replaced
element.
We now position inline-level boxes based on ascent and descent metrics
from the font in use. This makes our basic text layouts look a lot more
like those produced by other browsers. :^)
I've tried to match the terminology used by the CSS Inline Layout spec.
This will regress Acid2 a little bit, and probably various other sites,
but on the whole it's the direction we should be heading, so let's go.
This avoids a bunch of unnecessary work in Painter which not only took
time, but sometimes also led to alignment issues. draw_text_run() will
draw the text where we tell it, and that's it.
Unlike BFC root blocks with height:auto, when the block *isn't* a BFC
root, we don't have to look for the "bottommost" block-level child and
determine the width from that.
Instead, we should just look at the last in-flow block-level child.
This was already indicated in the spec comment next to the code, but
the code itself was wrong.
This makes the body element on Acid3 have the correct height. It also
introduces a small regression on Acid2 that we'll have to track down.
Previously, we only allowed floats to take up its own border box's worth
of horizontal space when laid out inside an IFC.
We should instead consume the full margin box horizonally. This fixes an
issue where a floated box on Acid3 had {width:20px; margin-right:-20px;}
but still consumed 20px of the previously available space, despite being
moved out of the way by its own negative margin.
When doing max-content layout, we were not committing newlines even
though we were supposed to due to white-space:pre*.
This broke the WPT harness due to a VERIFY() in ChunkIterator where we
were assuming the commit would always succeed.
Thanks to Orphis for reporting this! :^)
When the spec tells us to measure from the top content edge of a block,
that just means we should measure from Y=0. We don't need to go looking
for a child box with a negative top offset and measure from there.
This gets us a bit closer to the recommended algorithms in CSS 2.2 and
CSS Table Module 3.
A couple of table heavy websites (e.g. news.ycombinator.com,
html5test.com, etc.) now look quite okay. :^)
