Before this change, we'd always insert one line box fragment, even when
a float was taking up too much space on the line, and the fragment
didn't actually fit.
We now perform line breaks until we have enough space between floats.
This fixes many page layouts where we'd previously see small fragments
of inline content outside the right edge of the containing block.
If the containing block has indefinite height, we can't resolve
percentage heights against it. Instead of treating it as 0 by accident,
let's treat it as "auto" on purpose.
This brings back the cheek borders on Acid2.
We didn't set their display at all before, and since CSS display is not
inherited, anonymous block wrappers were actually "display: inline", but
it kinda worked anyway because we positioned blocks based on their C++
class (BlockContainer) rather than their CSS display value.
Now that we position based on CSS display value, this broke positioning
of anonymous wrapper blocks, and this fixes that.
Before this change, block-level boxes were laid out vertically by
placing them after the nearest previous BlockContainer sibling. This
only worked if the preceding block-level box happened to be a
BlockContainer.
This fixes an issue where the screenshot on netsurf-browser.org was not
being laid out properly (it was `img { display: block }` which creates
a block-level ImageBox, and ImageBox is not a BlockContainer but a
ReplacedBox, so the following block-level box was skipping over the
ImageBox and being placed next to whatever was before the ImageBox..)
We were constantly measuring and re-measuring the "alt" attribute text
of ImageBox layout nodes, even when the alt text didn't change. By
caching this, we avoid a *lot* of repeated text measurement work.
- Use the border box of the floated element when testing if something
needs to flow around it.
- Take the floated element's containing block size into account (instead
of the BFC root) when calculating available space on a line where a
right-side float intrudes.
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
This is a really starter attempt at formatting the grid. It doesn't yet
take into account the computed_values of grid-template-rows, nor the
values in grid-column-start and like CSS properties.
But these changes are a start and make it so the examples in
display-grid.html work.
To be fleshed out further..
Add functionality to begin parsing grid-template-columns and
grid-template-rows. There are still things to be added, like parsing
functions, but I would say a couple of the major points are already
adressed like length, percentage, and flexible-length.
This is a basic attempt at trying to handle parent container case
justify-content: flex-end.
Test-scenario:
Head to https://ryanwatkins.me and note that now the header nav is on
the right as opposed to the left in-line with how Chrome/Firefox would
respectively handle it also, i.e. 'flex-end'
Implementation:
Move cursor to the end and render in reverse backwards shifting the
cursor leftwards.
If absolutely positioned divs do not have a fixed position, then their
position must be calculated based off of the position of their parent
and their siblings.
Factor out the code that computes the vertical position of a Box with
respect to its siblings so that it can be used when computing the
absolutely positioned divs as well.
This commit moves both the ImageStyleValue and LinearGradientStyleValue
to a common base class of AbstractImageStyleValue. This abstracts
getting the natural_width/height, loading/resolving, and painting
the image.
Now for 'free' you get:
- Linear gradients working with the various background sizing/repeat
properties.
- Linear gradients working as list-markers :^) -- best feature ever!
P.s. This commit is a little large as it's tricky to make this change
incrementally without breaking things.
Previously absolutely positioned boxes could only have a % height if
their parent had a absolute height (a height in pixels, em, etc).
This broke some websites/demos such as the "Francine CSS oil painting",
which starts to appear after this commit.
Francine: https://diana-adrianne.com/purecss-francine/
Previously we were checking if values were "auto" after resolving the
"auto"-ness out of them, which didn't work. There's still a bunch of
work to do on this algorithm, but now we can at least resolve some basic
automatic height scenarios.
Percentage sizes of flex items are relative to the flex container, but
even when the flex container is automatically sized, we still have to
support them.
To make this work, we first do a pass where percentage sizes are ignored
(treated as "auto", basically) in order to get a "reference" value.
Then we do a second pass where percentages can be resolved against this
reference value.
We were neglecting to clamp flex items when calculating the intrinsic
main size of the flex container. This was covered by a FIXME, which we
can now remove. :^)
We had an older incomplete implementation of flex container max-content
sizing that we used for unconstrained main size determination.
This patch replaces the old implementation with a call to the new
max-content sizing code.
Note that this isn't a complete implementation of flex container sizing
still, but at least we've deduplicated some code.
The CSS-FLEXBOX-1 spec gives us two situations in which flex item cross
sizes should be considered definite. Both of them happen *during* flex
layout, which is super finicky but it is what it is.
When calculating intrinsic sizes, we don't need to recurse into *every*
box and layout its insides. IIUC, we can skip any unconstrained box with
definite sizes in both axes. So this patch does exactly that.
When we decide that a box has definite width or height based on its
containing block's corresponding size, we'll want to resolve the
current box's size as well. Otherwise anyone querying the size on
this box will get the bogus message of "yes, this definite, and its
value is zero."
Previously, we considered all LengthPercentage values for used flex
basis to be definite. This is not accurate, as percentages should only
be considered definite if the reference value they resolve against is
a definite size.
Fix this by checking the flex container's main definite size flag.
There's no need to override the sizes before calculating the cross size.
Besides, by the time we're calculating the hypothetical cross size of
flex items, we may already have established a definite main size anyway,
so overriding it would be wrong.
This state is less static than we originally assumed, and there are
special formatting context-specific rules that say certain sizes are
definite in special circumstances.
To be able to support this, we move the has-definite-size flags from
the layout node to the UsedValues struct instead.
If we wait until after the parent context has laid out the flex
container, abspos children are able to use the final results of the
parent sizing the flex container.
This makes `height:auto` work on abspos children of a flex container.
