There's nothing really background-size-specific about this, but since
there is no `<size>` value type defined in the CSS spec at this time,
and background-size is the only user of it, I think this name makes more
sense. But I'm not 100% convinced.
...as opposed to storing StyleValues, which we have to later check are
IdentifierStyleValues, which store identifiers that we can convert to
Repeat values later. It's fewer allocations, and we can't end up with
invalid values by mistake. :^)
While right now this doesn't save much complexity, it will do once we
care about multiple background layers per node. Then, having a single
repeat value per layer will simplify things.
It also means we can remove the pseudo-property concept entirely! :^)
This is step 1 in removing the two `background-repeat-x/y`
pseudo-properties. Since adding the concept of compound StyleValues, we
don't need `background-repeat` to be split in two any more.
This is done a bit differently from other properties: using a
TokenStream instead of just a Vector of ComponentValues. The reason for
this is, we can then use call the same function when parsing the
`background` shorthand. Otherwise, we would have to know in advance how
many values to pass down, which basically would involve duplicating the
`background-position` parsing code inside `background`.
The StyleValue is PositionStyleValue, since it represents a
`<position>`: https://www.w3.org/TR/css-values-4/#typedef-position
Unfortunately, background-position's parsing is a bit different from
`<position>`'s, (background-position allows 3-value syntax and
`<position>` doesn't) so we'll need to come back and write a different
parsing function for that later.
This also allows us to get rid of the ShareableBitmap(Bitmap)
constructor which was easy to misuse. Everyone now uses Bitmap's
to_shareable_bitmap() helper instead.
We achieve this by simply setting the intrinsic size to the size needed
to render the replacement text.
This fixes a long-standing issue where non-loaded images would default
to the goofy-looking 300x150 fallback size for replaced elements.
Use a simple heuristic to exclude uninteresting whitespace and
de-clutter the inspector's DOM tree.
Uninteresting whitespace is currently one of these:
- Non-rendered whitespace-only text nodes
- Rendered whitespace-only text nodes between block-level elements
This changes Web::Bindings::throw_dom_exception_if_needed() to return a
JS::ThrowCompletionOr instead of an Optional. This allows callers to
wrap the invocation with a TRY() macro instead of making a follow-up
call to should_return_empty(). Further, this removes all invocations to
vm.exception() in the generated bindings.
This allows supporting websites to use a light or dark theme to match
our desktop theme, without being limited to palette colors. This can be
overridden with the `WebContentServer::set_preferred_color_scheme()` IPC
call.
This also required converting URLSearchParams::for_each and the callback
function it invokes to ThrowCompletionOr. With this, the ReturnType enum
used by WrapperGenerator is removed as all callers would be using
ReturnType::Completion.
We now compute the used height of height:auto by measuring from the top
content edge (y=0) to the bottom of the bottommost line box within the
block container.
This fixes an issue where we'd fail to account for the topmost line box
being taller than any of its fragments (which can happen if the
line-height is greater than the height of all fragments on the line.)
I don't remember why we did things this way, but it's clearly not right
to stretch fragments vertically. Instead, we should just align their
bottom to the appropriate line (as we already do.)
When using bitmap fonts, the computed *font* that we're using may be
smaller than the font-size property asked for. We can still honor the
font-size value in layout calculations.
