Currently placing floating blocks in anonymous nodes makes
https://stackoverflow.com/ hang so let's leave it to try
to place only absolute blocks in anonymous nodes for now.
Also it breaks flex formatting when element with floating is
flex child.
This adds support for parsing the ::placeholder pseudo-element and
injecting an anonymous layout node with that element when the input
element's data is empty.
This change makes out-of-flow blocks to be considered for joining
only to anonymous blocks that have inline children. It finally
solved the problem that out-of-flow break anonymous blocks into
chunks causing wrong layout without regressing Acid2.
Making floats to join anonymous block caused regressions in
Acid2 Test so let's leave it to be only absolute blocks who
might be joined into anonymous block when possible.
We now layout foreign objects as if they form a nested block formatting
context. This probably isn't the most correct way to do this, but it's
a start.
This removes a set of complex reference cycles between DOM, layout tree
and browsing context.
It also makes lifetimes much easier to reason about, as the DOM and
layout trees are now free to keep each other alive.
Yet another legacy "is inline-block?" condition was causing us to insert
inline nodes directly as children of inline-flex containers (instead of
wrapping them in anonymous blocks, which would then cause them to become
flex items.)
We were skipping over inline flex containers when looking for an
insertion parent. This made us not generate flex items in those cases.
This commit changes the behavior, so that non-inline-level items can
get inserted into an inline-outside parent, as long as the parent isn't
just flow-inside.
Now that we don't have to deal with the ad-hoc "inline" flag on layout
nodes anymore, we're free to simply obey the inline-outside flag from
the CSS display value when choosing whether to insert as an inline-level
node or not.
This is one of many small steps towards being able to remove the ad-hoc
Layout::Node::is_inline() in favor of honoring the CSS display value
everywhere instead.
I couldn't find anything in the specs about this, but GMail uses
empty generated boxes (`::before` and `::after` with `content: ""`)
inside a flexbox container in order to vertically center things.
The flexbox spec tells us to not generate flex items for empty
*anonymous* boxes, so we continue not doing that, but generated boxes
(any pseudo-element box) now always produce a flex item. This probably
isn't perfect either, and we'll have to revisit it for stuff like
`::first-letter`.
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 disables this system progress bar, and instead creates one
out of pseudo elements, that can be selected and styled with the
::-webkit-progress-bar/value selectors.
Due to a missing `return` statement, we were creating two anonymous
wrapper blocks around each piece of inline content inside a flex
container.
This had no visual impact, since they ended up with 0x0 dimensions,
but we were wasting a fair bit of time running layout on them.
Make sure we use the create_anonymous_wrapper() helper function whenever
wrapping inline content in anonymous wrapper blocks. We were forgetting
to do this in one case, which led to some wrapper blocks having 0px
font-size and line-height.
This was implemented too rigidly, which made it impossible to place
floats correctly when they occurred in inline flow.
The new invariant is "all in-flow children must be either inline or
block". Out-of-flow children like floating and absolutely positioned
boxes are ignored when deciding when to generate anonymous boxes.
This makes SVG-in-HTML behave quite a bit better by following general
replaced layout rules. It also turns <svg> elements into inline-level
boxes instead of block-level boxes.
TreeBuilder wasn't taking advantage of the fact that we already have
computed style cached on each DOM::Element by the time we're
constructing a layout tree.
So instead of using the cached style, we recomputed it from scratch for
every element. This was done because invalidation was broken in many
places, but now that it's more or less trustworthy, stop recomputing
style on the fly in TreeBuilder and use what the preceding style update
pass gave us instead.
This basically cuts style computation work in half. :^)
Let's make it very clear that these are *computed* values, and not at
all the specified values. The specified values are currently discarded
by the CSS cascade algorithm.
1. Make this decision *after* we've inserted the layout node into the
layout tree. Otherwise, we can't reach its containing block!
2. Per css-sizing-3, consider auto-sized blocks whose sizes resolve
solely against other definite sizes as definite themselves.
In particular, (2) makes us consider width:auto block children of a
definite-size containing block as having definite size. This becomes
very important in flex layout.
Previously, these were added during layout. This didn't fit into the new
world where layout doesn't mutate the tree incrementally, so this patch
adds logic to Layout::TreeBuilder for adding a marker to each list-item
box after its children have been constructed.
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.
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
Until now, we've internally thought of the CSS "display" property as a
single-value property. In practice, "display" is a much more complex
property that comes in a number of configurations.
The most interesting one is the two-part format that describes the
outside and inside behavior of a box. Switching our own internal
representation towards this model will allow for much cleaner
abstractions around layout and the various formatting contexts.
Note that we don't *parse* two-part "display" yet, this is only about
changing the internal representation of the property.
Spec: https://drafts.csswg.org/css-display
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
An svg layout element without a `SVGSVGElement` ancestor caused a failed
assertion before, because the svg context does not exist when `paint()`
is called
