Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
Previously, set_needs_display() was passed an empty rectangle in
ImageStyleValue::resource_did_load(). This led to the browser not
doing a repaint when the image loaded.
Fixes#14435
When swapping both values to perform the actual calculation, we need to
consider that `A + B == B + A`, but `A - B != B - A`, so turn it into
`-B + A`.
Co-Authored-By: Sam Atkins <atkinssj@serenityos.org>
Every StyleValue type now has its own `equals()` method, rather than
relying on the default "compare the to_string() output" method, which
has now been removed. This logic is still used by UnresolvedSV and
CalculatedSV, because it's probably the best option for them unless
performance becomes a real issue.
Also took this opportunity to move all the `equals()` implementations
into the .cpp file, which may or may not actually help with compile
times but StyleValue.h is huge and included everywhere, so it can't
hurt.
The `text-shadow` property is almost identical to `box-shadow`:
> Values are interpreted as for box-shadow [CSS-BACKGROUNDS-3].
> (But note that the inset keyword are not allowed.)
So, let's use the same data structures and parsing code for both. :^)
If the current Document is not attached to a Web::Page for whatever
reason, but we're trying to look up a color from the system palette,
let's just fail the lookup instead of crashing the process.
Instead of awkwardly visiting and mutating lengths inside StyleValues,
we now simply create a new StyleValue instead.
This fixes an issue where inherited relative lengths could get
absolutized using a parent as reference, and then not having the correct
values when used in a child context.
For now, we only understand `none`, `normal`, `<image>` and `<string>`.
The various other functions and identifiers can be added later.
We can *almost* use a StyleValueList for this, except it's divided into
two parts - the content, and the optional "alt text". So, I've added a
new StyleValue for it.
Depending on the type of the calc() expression, the percentage_basis has
to be the same dimension type. Several places were already passing `
{}` for this, so let's make that an empty Variant instead of an
undefined Length. :^)
None of these require any outside metrics, which is nice! I believe the
Values-4 spec would have us simplify them down into a single value at
parse time, but that's a yak for another day.
The previous static functions are now methods of their respective
CalcFoo structs, but the logic has not changed, only that they work
with CalculationResults instead of converting everything to floats.
calc() sub-expressions can return a variety of different types, which
then can be combined using the basic arithmetic operators. This class
should make that easier to deal with, instead of having to handle all
the possible combinations at each call site. :^)
We take the Layout::Node as a pointer not a reference, since later we'll
need to call these functions when resolving to `<number>` or `<integer>`
which don't use those, and we don't want to force users to pass them in
unnecessarily.
See https://www.w3.org/TR/css-values-3/#calc-type-checking
If the sub-expressions' types are incompatible, we discard the calc() as
invalid.
Had to do some minor rearranging/renaming of the Calc structs to make
the `resolve_foo_type()` templates work too.
This lets us produce valid CSS in its to_string() method, instead of
always adding commas as before. :^)
Also, finally added a Formatter for StyleValues.
Many of these will need to change in the future in order to include
features we don't yet support, and touching StyleValue.h is a great way
to have to wait for all of LibWeb to rebuild. I'm hoping this saves me
time in the long run. :^)
This is in a slightly weird state, where Percentages are sometimes
Lengths and sometimes not, which I will be cleaning up in subsequent
commits, in an attempt not to change all of LibWeb in one go. :^)
This represents a property value that hasn't been converted to a
"proper" StyleValue yet. That is, it's either a custom property's value,
or a value that includes `var()` references, (or both!) since neither of
those can be fully resolved at parse time.
This now outputs valid CSS representing the background, instead of
confusing debug info.
We can't guarantee that all the longhands have the same number of
values, since while that's always the case when parsing, we also create
BackgroundStyleValues when producing the resolved style, which just
combines the longhands together.
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.
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 always felt awkward to me, and required a few other hacks to make
it work. Now, the request is only started when `load_bitmap()` is
called, which we do inside `NodeWithStyle::apply_style()`.
