This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
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.
Instead of using Optional<LengthPercentage>, we now use LengthPercentage
for these values. The initial values are all `auto`.
This avoids having to check `has_value()` in a ton of places.
Anonymous wrappers get their non-inherited properties from the initial
state of a new CSS::ComputedValues object. Before this patch, all the
values in their margin and padding LengthBox would be "auto".
When we're performing max-content layout (a separate throwaway layout
pass that only exists to discover the intrinsic max-content size of
a specific box), we act as if the containing block has infinite width.
This allows an infinite length to propagate into the layout system,
which is fine, but at some point it needs to be turned into a finite
number or some loop conditions will not make sense and we can hang
indefinitely (e.g in the flexible lengths resolution algorithm.)
We fix this by making Length::resolved() turn non-finite values into
an "auto" length.
This commit has no behavior changes.
In particular, this does not fix any of the wrong uses of the previous
default parameter (which used to be 'false', meaning "only replace the
first occurence in the string"). It simply replaces the default uses by
String::replace(..., ReplaceMode::FirstOnly), leaving them incorrect.
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>
The lack of the commit() before returning the x_value here meant,
that in parse_background_value() the token stream would be one token
behind after parsing the background-size. This led to it to returning
null, after it sees the unexpected 'second' contain / cover token.
With this change all of backgrounds.html is working again.
This prevents font-face rules without a block statement from crashing
LibWeb during CSS parsing.
The issue was discovered by Lubrsi during CSS parser fuzzing. :)
Fixes#14141.
From the spec:
> This property previously accepted the values optimizeSpeed and
optimizeQuality. These are now deprecated; a user agent must accept
them as valid values but must treat them as having the same behavior
as pixelated and smooth respectively, and authors must not use them.
- https://www.w3.org/TR/css-images-3/#the-image-rendering
It's probably not in 1:1 as spec says, as it wants us to first upscale
the image to the nearest integer and then downscale it bilinearly.
But this mode still falls into the general description of the value:
> The image is scaled in a way that preserves the pixelated nature of
> the original as much as possible, but allows minor smoothing instead
> of awkward distortion when necessary.
Also, this way we don't have to allocate the memory just for the integer
scale. :^) :^)
Implement parsing of rgb(..) and hsl(..) in both the modern level 4
syntax without commas, and the legacy syntax with commas.
The parser accepts non-integer numbers but rounds to integer values
for now.
Using auto& when indexing an NNRPVector doesn't cause it to hold a
strong reference and is instead just a plain old reference.
If m_rules was the only storage holding a strong reference to old_rule,
we would remove it in step 4 and subsequently UAF it in step 5.
Previously, `var()` inside functions like `rgb()` wasn't resolved.
This will set the background color for badges in the New category on
https://ports.serenityos.net. :^)
Both of these are supposed to be set when the CSSRule is created. The
spec is silent on setting it when a CSSRule is added to a parent. So,
this is a bit ad-hoc.
The parent rule gets set whenever a rule is added to a new parent. The
parent stylesheet gets set whenever the rule or one of its ancestors is
added to a different stylesheet. There may be some nuance there that
I'm missing, but I'm sure we'll find out quickly once we have WPT
running!
The spec is a little bizarre here. One caller of this
(`CSSStyleSheet::insert_rule()`) wants to give it a parsed CSSRule, but
the spec itself wants it to take a string. (As will be used by
`CSSGroupingRule::insert_rule()`) Using a Variant isn't pretty but it's
the best solution I've come to - having two overloads was worse, whether
one called the other or they just duplicated the logic. This seems the
least bad.
When parsing <ndash-dimension> <signless-integer>, we tried to parse
a new token from the stream instead of using the value we had already
extracted. This caused pages that used the syntax to crash.
This was changed a while ago so the generated files are placed in the
Build directory. Let's remove the gitignore file so any old version of
the files stop conflicting with the new generated versions.
...and change how the two parsing steps fit together.
The two steps were previously quite muddled. Both worked with the
TokenStream directly, and both were responsible for rewinding that
stream if there was an error. This is both confusing and also made it
impossible to replace the rewinding with StateTransactions.
This commit more clearly divides the work between the two functions: One
parses ComponentValues and produces a string, and the other parses that
string to produce the UnicodeRange. It also replaces manual rewinding
in the former with StateTransactions.
