We often want to call a function with either a built-in or custom
property, and that means either passing it as a string (and converting
back and forth between strings and PropertyIDs) or using the
PropertyIDOrCustomPropertyName variant, which complicates user code.
PropertyNameAndID is intended to make that easier: Create it with a
string or PropertyID, and it can tell you either one.
property_accepts_type() only looks at the property itself, not any
longhands it might have, so we thought that `font` didn't accept
`<custom-ident>`s, and seeing "-apple-..." makes us throw out the
declaration even though it's valid as a font name.
We'll reject these like any other unrecognized value if it's somewhere
that's not supported, so this was really just an optimization for a
rare edge case, and removing the check doesn't have any observable
effect except fixing this bug and any similar cases.
Changing property_accepts_type() to look at longhands is not
straightforward, as not all longhand values are valid in the shorthand.
`set_source` takes a ByteString but the implementation might require a
specific encoding. Make it fallible so that we don't need to crash in
the case of invalid UTF-8 or similar.
The test includes a sequence of invalid UTF-8 bytes that crash the
browser without this change.
This applies size, inline-size, and style containment in some cases.
There are other WPT tests for that, but we seem to not implement enough
of containment for this to have an effect so I've not imported those.
Gets us 35 WPT subtests.
Use `Float32Array or sequence<GLfloat>` instead of
`BufferSource or sequence<GLfloat>`. This meaningfully changes behavior
for `Float16Array` and `Float64Array`: they are now converted to
`sequence<GLfloat>` by iterating the typed array, rather than being
treated as a `BufferSource`. As a result, many WebGL calls now work
correctly where we previously crashed in `VERIFY_NOT_REACHED()` due to
the assumption that a `BufferSource` was always a `Float32Array`.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/5962
Whether an absbox is positioned below or to the right of its previous
sibling in an `InlineFormattingContext` is determined by the
display-outside value before blockification, so we store the
pre-blockification `display` value in `ComputedValues` to access it in
`InlineFormattingContext` and position the box accordingly.
Before this change, we always used the flex container's full available
space as the width for intrinsic (height) sizing of flex items.
This meant that flex lines with more than one flex item had their
intrinsic height determined as if they were alone on the line.
For flex row layouts, if we've already determined the flex item's main
size, we now use that as the width to get the intrinsic height.
This leads to more correct layouts, and also avoids some redundant work
since we no longer do unnecessary sizing work with the wrong width (and
can hit cache instead).
...instead of taking the Layout::Box. This will allow us to make more
nuanced decisions in those functions by having access to flex layout
internal state.
For whatever reason, this method in particular ends up failing to link
into WebContent with a subsequent change. It's small and simple, so
just inline it.
