This implements looking up a slottable's assigned slot, and a slot's
list of assigned slottables. For the latter, only unflattened lookups
are implemented so far.
This implements automatic slottable assignment by way of hooking into
the element attribute change steps. When the `name` attribute of a slot
or the `slot` attribute of a slottable changes, assignment is performed.
This implements manual slottable assignment by way of HTMLSlotElement's
`assign` API. This includes all of the slottable-related AOs needed to
perform the assignment.
A slottable is either a DOM element or a DOM text node. They may be
assigned to slots (HTMLSlotElement) either automatically or manually.
Automatic assignment occurs by matching a slot's `name` attribute to
a slottable's `slot` attribute. Manual assignment occurs by using the
slot's (not yet implemented) `assign` API.
This commit does not perform the above assignments. It just sets up the
slottable concept via IDL and hooks the slottable mixin into the element
and text nodes.
This is similar to the run activation behavior in that elements may
define these steps themselves. HTMLSlotElement is one such element. The
existing (ad-hoc) Element::attribute_changed() method is not sufficient
there as the steps require knowledge of the attribute's old value and
its namespace, which this extension provides.
Unlike the run activation behavior, we store these steps in a list. An
element may end up defining multiple attribute change steps. For example
all DOM elements must define steps to handle the "slot" attribute, and
HTMLSlotElement must define steps to handle the "name" attribute.
The spec now has a "toggle task tracker" to coalesce rapid changes to
this attribute. It also now has an explicit ToggleEvent to encapsulate
the old and new state of the element.
This further handles the attribute being added/removed using a override
of Element::attribute_changed(), rather than being the only element to
instead override Element::set/remove__attribute().
Call them from the helpers for strings. We'll have other object classes
soon that need to serialize ByteBuffers, so let's take advantage of the
encoding scheme we are already using for Strings.
We skip serializing any of the internal state of the Regex<ECMA262>
object, because that state is all computable from the input pattern
and flags. If it turns out that this is really, really slow, we can add
some optimizations to serialize more of the regex parse result.
If we serialize a string followed by some other object, the deserialize
helper would just happily keep appending bytes to the string until the
end of the serialization buffer. Avoid doing that by checking the string
length for figuring out when the string actually ends.
In order to access the string's contents, use the new
`StringStyleValue::string_value()` method.
I think I found all the existing places that relied on
`StringStyleValue::to_string()` returning an unquoted string, but it's
hard to know for sure until things break.
Previously we made StringStyleValues from these, but once we start
actually quoting StringStyleValues when serializing them, this will
break the font-family serialization.
When calculating the edge offset of the next floating item based on the
offset of the preceding floating item, we need to ensure that the
preceding offset is always > 0. This isn't explicitly written in the
spec, but all other popular engines do that.
Fixes https://github.com/SerenityOS/serenity/issues/21023
Before, we completely ignored clearance for block-level boxes if they
were floated. This was incorrect because it is valid for a block-level
box to be floated and still have clearance. However, unlike clearance
on normal flow boxes, clearance on floating boxes does not affect the
y-position of subsequent normal flow boxes. Instead, it pushes the
box's position to the very beginning of an edge.
Work towards https://github.com/SerenityOS/serenity/issues/21023
This is a simple mapping of some code-points to others.
I was going to use a ref test for this, but without knowing that the
font contains the code-points (which SerenitySans does not) we'd be
comparing a series of replacement characters to a series of replacement
characters, which doesn't tell you if they're the right code-points
underneath.
This one is a bit fun because it can be `add(<integer>)` or `auto-add`,
but children have to inherit the computed value not the specified one.
We also have to compute it before computing the font-size, because of
`font-size: math` which will be implemented later.
This is a `<display-inside>` keyword added by the MathML spec, and has
the rough meaning of "display in the default way". It enables the
standard layout rules for each MathML element (and is ignored for
anything that isn't a MathML element).
I believe we'll need an actual MathML formatting context to do the
layout correctly, but we can at least support a couple of elements that
behave the same as HTML ones.
Previously we were overly generous in what we accepted for `display`.
For example, we accepted:
- Multiple outside or inside identifiers
- Unrecognized identifiers
- Non-identifier tokens
Now, we reject all these cases. This makes us stop accepting the
`display: block math;` declaration in `MathML/Default.css`, and so the
one layout test we have containing MathML elements has changed to
reflect that.
When a button should use flex for alignment and also has ::before
and/or ::after, we previously did the following:
1. Prepended/appended the button's children with boxes for
pseudo-elements.
2. Replaced the button's direct children with a flex container that
contains its children.
As a result, the generated boxes for ::before/::after ended up as
children of the generated flex item, instead of being direct children
of the button layout box as they were supposed to be.
This change reverses these steps, ensuring that boxes for
pseudo-elements are generated only after modifications inside the
button layout are completed.
When modifying the button layout during tree building to use flex for
vertical alignment, let's explicitly set the button box's children to
be non-inline. It doesn't make sense to layout the button as an IFC
when its only child is a flex container.
These functions are required in the porting of the DocumentFragment
interface from DeprecatedString to String. Unfortunately since
ParentNode is used by Document, we can't fully remove the deprecated
versions of these functions yet.
Unfortunately we can't port these functions entirely over to FlyString
from DeprecatedString as Document includes NonElementParentNode and has
not yet been ported over to new AK string. In the mean time, this should
help up in porting over NonElementParentNode itself.
Closer matching spec text, as well as pre-existing use in
CharacterData::substring_data. This helps in porting of this file over
to new String which has no length member function.
We only need special-case code to handle two kinds of properties:
- Those with special rules, many of which are listed here:
https://www.w3.org/TR/cssom-1/#resolved-values
- Shorthands, because we only store longhand values.
In other cases, we can fall back to the computed values that we already
have, and these will be correct. So, we can remove them from here. :^)
