This parses the new background-position-x/y longhands and properly
hooks up them up. This requires converting PositionStyleValue to
just contain two EdgeStyleValues so that it can be easily expanded
into the longhands.
In situations where we need a width to calculate the intrinsic height of
a flex item, we use the fit-content width as a stand-in. However, we
also need to clamp it to any min-width and max-width properties present.
In `flex-direction: column` layouts, a flex item's intrinsic height may
depend on its width, but the width is calculated *after* the intrinsic
height is required.
Unfortunately, the specification doesn't tell us exactly what to do here
(missing inputs to intrinsic sizing is a common problem) so we take the
solution that flexbox applies in 9.2.3.C and apply it to all intrinsic
height calculations within FlexFormattingContext: if the used width of
an item is not yet known when its intrinsic height is requested, we
substitute the fit-content width instead.
Note that while this is technically ad-hoc, it's basically extrapolating
the spec's suggestion in one specific case and using it in all cases.
When calculating the intrinsic width of a box, we now make its content
width & height indefinite before entering the intrinsic sizing layout.
This ensures that any geometry assigned to the box by its parent
formatting context is ignored.
For intrinsic heights, we only make the content height indefinite.
This is because used content width is a valid (but optional) input
to intrinsic height calculation.
The "flex item automatic minimum size in the main axis is the
content-based minimum size" behavior should only apply to flex item
sizes in the main axis. There was one case where we incorrectly applied
this behavior in the cross axis
The "flex item automatic minimum size in the main axis is the
content-based minimum size" behavior should only apply to flex items
that aren't scroll containers. We were doing it for all flex items.
When calculating one of the intrinsic sizes for a flex container, we
already go through the flex layout algorithm.
There's no need to perform some of the algorithm steps a second time.
This is a relic from an earlier time when we tried to bail early from
the layout algorithm in the intrinsic sizing case. Now that we go
through the whole thing anyway, this is much simpler. :^)
Negative width/height sizes are not allowed in CSS, so if our layout
algorithm resolves something to a negative size, we have boogs.
Instead of crashing or rendering something very wrong, we now clamp the
values to 0 and whine on the debug log so that someone can go and figure
out how we got the negative values in the first place. :^)
If the previous sibling of an out-of-flow box has been wrapped in an
anonymous block, we now stuff the out-of-flow box into the anonymous
block as well.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
Previously we were using the HTML parse_dimension_value method for the
height and width attributes of an SVG element. These attributes should
however be treated as css properties instead and thus also support
calc() and absolute units so we use the css parser for this instead.
Instead of special-casing FlexFormattingContext in the intrinsic sizing
layout helpers, add FormattingContext::automatic_content_width() and let
each context subclass decide what that means.
No behavior change here, just moving this responsibility.
Explicitly check is_viewport() instead of looking at the corresponding
DOM node. (The viewport has the DOM document as its DOM node, but that's
not obvious from context here.)
This fixes an issue where e.g `height: 100%` on a flex item whose
container has indefinite height was being resolved to 0. It now
correctly behaves the same as auto.
Previously, when having inline contexts consisting of just a `<br/>`
tag, we would not create a line box.
Ensure that there is always a line box when a line is explicitly being
broken and also ensure it won't be trimmed due to being empty.
This will a fix a number of sites that use `<br>` tags for layouts
between block elements (even though the spec says they shouldn't).
Before this patch, we would build full computed style for these pseudo
elements, for every DOM element, even if no ::before/::after selector
actually matched.
This was a colossal waste of time, and we can also just not do that.
Instead, just abort pseudo element style resolution early if no relevant
selectors matched. :^)
When we're calculating the intrinsic size of a flex container, we don't
*need* to layout the inside of each flex item. That's only necessary if
the flex items will be seen (as is the case for "normal" layout).
This avoids a whole bunch of unnecessary layout work on pages that use
flexbox layout. :^)
According to CSS Inline Layout Module Level 3 § 2.2 Step 1. atomic
inlines should be layed out in a line box based on their margin box.
However, up until this patch we were unconditionally considering only
the border box during line box height calculation. This made us
essentially drop all vertical margins for atomic inlines.
If normal flow layout has caused us to progress past the current
innermost float in the block axis, we still need to consider the floats
stacked outside of it.
Fix this by always walking the currently stacked floats from innermost
to outermost when placing new floats.
Until now we were just creating a stacking context for the tree root,
which usually is the viewport element. This lead to weird painting
behaviour when negative z-index children of the html element that
established their own stacking context were drawn below the canvas
background.
Now we establish a stacking context for both, the root element and the
viewport.
When using the flex shrink factor, the flexible length resolution
algorithm was incorrectly ignoring the `frozen` flag on items and would
update the same items again, causing overconsumption of the remaining
free space on the flex line.
