| Age | Commit message (Collapse) | Author |
|---|
|
Until now, some formatting contexts (BFC in particular) have been
assigning size to the root box. This is really the responsibility of the
parent formatting context, so let's stop doing it.
To keep position:absolute working, parent formatting contexts now notify
child contexts when the child's root box has been sized. (Note that the
important thing here is for the child root to have its final used height
before it's able to place bottom-relative boxes.)
This breaks flexbox layout in some ways, but we'll have to address those
by improving the spec compliance of FFC.)
|
|
We sometimes had a stale stacking context tree sitting around, causing
incorrect paints until the next full layout invalidation.
Fix this by simply rebuilding the stacking context tree when asked to.
|
|
BFC currently has a number of architectural issues due to it being
responsible for setting the dimensions of the BFC root.
This patch moves the logic for setting up the ICB from BFC to Document.
|
|
- padded_rect() -> absolute_padding_box_rect()
- bordered_rect() -> absolute_border_box_rect()
|
|
|
|
This fits better since it's now used by all SVGGeometryElements.
|
|
From the spec:
> Interface SVGGeometryElement represents SVG elements whose rendering
> is defined by geometry with an equivalent path, and which can be
> filled and stroked. This includes paths and the basic shapes.
- https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement
Making them all create an SVGPathBox, and return a Path from get_path(),
means we can implement the "basic shapes" using the path system we
already have. :^)
|
|
|
|
Before this, we were filling and stroking every <path>, whether they had
a fill/stroke color or not. We can avoid a bunch of unnecessary work by
checking if the color is transparent (also the case if unset) before
doing the painting work.
If there is no fill color, we also avoid making a copy of the path to
ensure that it's closed.
|
|
Previously disabled checkbox could be checked by clicking on it's label
|
|
We also pass whether the shadow goes inside or outside the element. Only
outer shadows are rendered currently, and inner ones may want to be
handled separately from them, as they will never interfere with each
other.
|
|
Because why not? :^)
|
|
We renamed the Frame class to BrowsingContext a while back, but forgot
to update some variable names.
|
|
We should no longer be generating empty fragments at the start and end
of an InlineNode, so we can drop this check.
|
|
|
|
This property represents the CSS content size, so let's reduce ambiguity
by using the spec terminology.
We also bring a bunch of related functions along for the ride.
|
|
Instead of making each Layout::Node compute style for itself, we now
compute it in TreeBuilder before even calling create_layout_node().
For non-element DOM nodes, we create the style and layout tree node
in TreeBuilder. This allows us to move create_layout_node() from
DOM::Node to DOM::Element.
|
|
Most of the time, we cannot resolve a `calc()` expression until we go to
use it. Since any `<length-percentage>` can legally be a `calc
()`, let's store it in `LengthPercentage` rather than make every single
user care about this distinction.
|
|
|
|
While IFC flows text into a block container, floating objects are
anchored at the BFC root, not necessarily the local block container.
Because of this, we have to use root-relative coordinates when checking
how much space is available in between left and right floated objects.
|
|
Block placement is now divided into a vertical and horizontal step. The
vertical step runs before formatting boxes internally. The horizontal
step still runs after (since we may need the final width value.)
This solves a long-standing architectural problem where IFC didn't know
its origin Y position within the BFC root box. This is required for
figuring out how to flow around floating objects. (Floating objects are
always relative to the BFC root.)
|
|
Seems like we can share the code for these.
|
|
|
|
We were doing the exact same thing for both replaced and non-replaced
elements, so let's share the code. :^)
|
|
This simplifies some code and allows us to use tighter types for the
parent context everywhere.
|
|
|
|
|
|
|
|
For now only Wavy is additionally supported, but the infrastructure is
there.
|
|
This patch makes the property 'text-decoration-style' known throughout
all the places in LibWeb that care.
|
|
This ensures that <br> produces empty line boxes with the line-height
property as their height.
|
|
If we run out of horizontal space when placing floating objects,
we now perform a "break" and continue with a new line of floats
below the bottommost margin edge of the current line.
This is definitely not 100% to-spec yet, but a huge improvement
on ACID1 already. :^)
|
|
This patch adds a BFC::FloatSideData struct so we can contain left and
right floating object layout state in a struct. This is preparation for
adding more per-side state.
|
|
After pruning empty last line boxes, we now avoid re-running the
horizontal fragment positioning step, since that would be wasted work.
|
|
This is poorly factored. TextNode needs to know whether the most
recently inserted fragment on the current line was empty or ended in
whitespace. This is used when deciding what to do with leading
whitespace in text nodes.
Let's keep this working for now, but we should eventually sort this out
and make text chunk iteration not depend on this information.
|
|
This is always a block container (the IFC's containing block.)
|
|
When collapsing whitespace, we can skip over all-whitespace chunks at
the start of each line, and immediately following fragments that
themselves end in whitespace.
|
|
Now that we build lines incrementally, we no longer need the atomic line
splitting API.
The new InlineLevelIterator and LineBuilder setup does have some
regressions from the old behavior, but we can deal with them as we go.
|
|
Vertical inline alignment is still very unsophisticated, but let's at
least put everything within each line on the same baseline.
|
|
|
|
In this layout mode, we should only break when forced (e.g by an
explicit <br> tag.) This is used when determining intrinsic sizes.)
|
|
Marker boxes are managed explicitly by the corresponding list item box.
|
|
We won't know if we need to break before the inline-block box until
after we've dimensioned it.
|
|
We don't want to descend into inline-block containers when iterating
inline-level items, since that would make the inline-level children of
the inline-block bubble up to the containing block of the inline-block.
|
|
This resolves a long-standing architectural problem in LibWeb that made
it unable to place CSS floating objects correctly due to not having
final vertical position information when computing the amount of
available horizontal space for each line.
|
|
This class will be used to place items on lines incrementally instead of
the current two-phase approach.
|
|
|
|
This patch adds a new mechanism that allows InlineFormattingContext to
build line boxes incrementally instead of all-in-one go.
Incremental build will eventually allow much better support for CSS
floating objects.
|
|
|
|
Despite looking like it was still needed, it was only used for passing
to other calls to Length::resolved() recursively. This makes the
various `foo.resolved().resolved()` calls a lot less awkward.
(Though, still quite awkward.)
I think we'd need to separate calculated lengths out to properly tidy
these calls up, but one yak at a time. :^)
|
