Previously we didn't check if we could insert the element in the
adjusted insertion location's parent.
Also makes the return type NonnullRefPtr, as that's what element is.
The mutation algorithms now more closely follow the spec and
fixes some assertion failures in tests such as Acid3 and Dromaeo.
The main thing that is missing right now is passing exceptions to the
bindings layer. This is because of issue #6075. I spent a while trying
to work it out and got so frustrated I just left it as a FIXME. Besides
that, the algorithms bail at the appropriate points.
This also makes the adopting steps in the document more spec compliant
as it's needed by the insertion algorithm. While I was at it, I added
the adoptNode IDL binding.
This adds a bunch of ancestor/descendant checks to TreeNode as well.
I moved the "remove_all_children" function to Node as it needs to use
the full remove algorithm instead of simply removing it from
the child list.
This is because it includes the initial node that the function was
called on, which makes it "inclusive" as according to the spec.
This is important as there are non-inclusive variants, particularly
used in the node mutation algorithms.
This will instead be done by Node, as they need to occur at precise
steps of the mutation algorithms. Additionally, some of the events
may need to be run multiple times. For example, the removal steps
is run for all the shadow-including descendants of the node that
just got removed.
Also updates the "inserted_into" function as per the previous commit.
Changes the FIXME, as according to the spec there is no notification
system to be notified of things such as the node becoming connected.
Instead, "becomes connected" means when the insertion steps are run,
the element is now connected when it previously wasn't.
https://html.spec.whatwg.org/multipage/infrastructure.html#becomes-connected
This is done in this PR because the insertion steps are run when the
start tag is inserted. This made it try to prepare the script too early
for inline scripts.
The order of operations in the HTML document parser ensures that
the parser document is set before the insertion steps are run.
This particularly affects the insertion steps and the removed steps.
The insertion steps no longer take into the parent that the node
was inserted to, as per the spec. Due to this, I have renamed the
function from "inserted_into" to simply "inserted". None of the
users of the insertion steps was using it anyway.
The removed steps now take a pointer to the old parent instead of
a reference. This is because it is optional according to the spec
and old parent is null when running the removal steps for the
descendants of a node that just got removed.
This commit does not affect HTMLScriptElement as there is a bit
more to that, which is better suited for a separate commit.
Also adds in the adopted steps as they will be used later.
The background-repeat value may be specified as either one- or two-value
identifiers (to be interpreted as horizontal and vertical repeat). This
adds two pseudo-properties, background-repeat-x and background-repeat-y,
to handle this. One-value identifiers are mapped to two-value in
accordance with the spec.
These are properties that may used internally by LibWeb when resolving
style values, but may not be set by external stylesheets. For example,
'background-repeat' may be a two-value CSS property that internally
translates to 'background-repeat-x' and 'background-repeat-y'.
For now, painting of background color is kept separate. The ICB needs to
perform a "translate" call between painting the color and background,
whereas other divs must not make that call.
This also adds an API to Label to determine if the Label itself or its
child TextNode is hovered. This allows ButtonBox to render in a hovered
state when the label is hovered.
A label's format is: <label>Label text</label>
So, a TextNode is created as a child of the Label node, and EventHandler
will send events to the TextNode. This changes TextNode to accept mouse
events if its parent is a Label, and to forward those events upward.
The HTML <label> element is special in that it may be associated with
some other <input> element. When the label element is clicked, the input
element should be activated.
To achieve this, a LableableNode base class is introduced to provide an
interface for "labelable" elements to handle mouse events on their
associated labels. This not only allows clicking the label to activate
the input, but dragging the mouse from the label to the input (and vice-
versa) while the mouse is clicked will also active the label.
As of this commit, this infrastructure is not hooked up to any elements.
For example:
<div>
<input type=radio name=group value=item1 />
</div>
<div>
<input type=radio name=group value=item2 />
</div>
Is a valid DOM and clicking on of these radio buttons should uncheck
the other.
Object introspection in the Browser's JS console is still not great, but
this makes it a lot easier to find out the exact type of an object by
checking its 'constructor' property.
It also fixes all the things that rely on these properties being set, of
course :^)
A FrameHostElement is an HTML element (<frame> or <iframe>) that may
have a content frame that participates in the frame tree.
This basically just moves code from <iframe> to a separate base class
so we can share it with <frame> once we implement <frame>.
Update the painting of background images for both <body> nodes and other
non-initial nodes. Currently, only the following values are supported:
repeat, repeat-x, repeat-y, no-repeat
This also doesn't support the two-value syntax which allows for setting
horizontal and vertical repetition separately.
This is required for the block formatting context to know the height of
the <br> element while computing the height of its parent. Specifically,
this comes into play when the <br> element is the first or last child of
its parent. In that case, it previously would not have any fragments, so
BlockFormattingContext::compute_auto_height_for_block_level_element
would infer its top and bottom positions to be 0.
We now run queued promise jobs after calling event handler, timer, and
requestAnimationFrame() callbacks - this is a bit ad-hoc, but I don't
want to switch LibWeb to use an event loop right now - this works just
fine, too.
We might want to revisit this at a later point and do tasks and
microtasks properly.
When hit testing a stacked context, skip hit testing children if the
child's z-index is less than the parent's. The children are already
sorted by z-index, but also need to consider the parent.
Turns out compute_position should be invoked before placing the element
in normal flow. Otherwise, the position isn't set on the first layout.
The effect was that the block would "jump" into place on a secondary
layout.
This is a follow-up to commit:
deda7c8995
Section 10.3 "Calculating widths and margins" indicates that the 'left'
and 'right' properties of relatively positioned elements should be set
in accordance with the rules of section 9.4.3.
Section 10.6.4 rule 5 of the CSS height property spec outlines a method
to compute the height of an absolutely positioned block when the 'top'
and 'bottom' CSS properties are specified.
