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
Resolved style is a spec concept that refers to the weird mix of
computed style and used style reflected by getComputedStyle().
The purpose of this class is to produce the *computed* style for a given
element, so let's call it StyleComputer.
Our "frame" concept very closely matches what the web specs call a
"browsing context", so let's rename it to that. :^)
The "main frame" becomes the "top-level browsing context",
and "sub-frames" are now "nested browsing contexts".
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
HTMLInputElement now inherits from FormAssociatedElement, which will
be a common base for the handful of elements that need to track their
owner form (and register with it for the form.elements collection.)
At the moment, the owner form is assigned during DOM insertion/removal
of an HTMLInputElement. I didn't implement any of the legacy behaviors
defined by the HTML parsing spec yet.
Text <input> fields will now generate a basic shadow DOM and attach it
to the input element.
The shadow DOM contains a <div> with some inline style, and an always-
editable text node inside it. Accessing the "value" attribute on such
an input element will get/set the value from that text node.
This is really cool, although not super stable since HTML editing is
not super stable. But it's a start! :^)
The approach of attaching sub-widgets to the web view widget was only
ever going to work in single-process mode, and that's not what we're
about anymore, so let's just get rid of WidgetBox so we don't have the
dead-end architecture hanging over us.
The next step here is to re-implement <input type=text> using LibWeb
primitives.
This is a workaround until we can implement a proper <input type=text>
in terms of LibWeb primitives.
This makes google.com not crash in multi-process mode (but there is no
search box.)
