Instead of CSSColorValue holding a Gfx::Color, make it an abstract class
with subclasses for each different color function, to match the Typed-OM
spec. This means moving the color calculations from the parsing code to
the `to_color()` method on the style value.
This lets us have calc() inside a color function, instead of having to
fully resolve the color at parse time. The canvas fillStyle tests have
been updated to reflect this.
The other test change is Screenshot/css-color-functions.html: previously
we produced slightly different colors for an alpha of 0.5 and one of
50%, and this incorrect behavior was baked into the test. So now it's
more correct. :^)
(cherry picked from commit 3af6a69f1e13803c64466a9b24b7bd7d75d459df;
amended to:
* resolve a minor conflict in Parser.cpp due to upstream not having
https://github.com/LadybirdBrowser/ladybird/pull/385#issuecomment-2227130015
* rebaseline canvas-fillstyle-rgb.png since the diff didn't apply due to
us not having https://github.com/LadybirdBrowser/ladybird/pull/999
* remove css-color-functions-ref.png and instead update
css-color-functions-ref.html since that file is still a reftest due to us
not having https://github.com/LadybirdBrowser/ladybird/pull/736
Makes it much easier to see what actually changed.
)
"Parse a style value for <foo>", where we don't care if it's a literal
<foo> or a calculated one, is a really common thing that we previously
didn't have methods for.
A couple of methods we had have been extended to parse calc(), and the
others have been filled in.
The method for parsing the `flex` property's value is renamed
`parse_flex_shorthand_value()` as it conflicted.
(cherry picked from commit 27be8678c973da41379f47f07c8b0a9ff692bcd3)
Soon, CSSColorValue will be an abstract class, and we'll instead create
a CSSRGB, CSSHSL, or other specific color type from the Typed-OM spec.
However, it's still useful to have an easy "just give me a style value
for this color" method. So change the name to distinguish this from the
usual StyleValue::create() methods.
(cherry picked from commit 37ea4e3b5f33464a58ee1260fe3ce5fc0699e29a)
Colors can be specified in a way that `Gfx::Color` can't represent, such
as named system colors, `currentColor`, or functions involving `calc()`.
(cherry picked from commit 4e48afd9a7e32cc97fcec5086afc2d2967ec4360)
This matches the name in the CSS Typed OM spec.
https://drafts.css-houdini.org/css-typed-om-1/#csscolorvalue
This is not (yet) the same as the CSSColorValue, but one step at a time.
(cherry picked from commit 581d00293c184e47015a5d7e9c4230410567db45)
CSS-Typed-OM has the following hierarchy:
CSSStyleValue
- CSSNumericValue
- CSSUnitValue
- CSSMathValue
- ...various math functions...
Somewhat unintuitively, numbers are also stored using CSSUnitValue with
`unit = "number"`.
There are no distinct classes for LengthStyleValue, etc in the spec, but
they're convenient for us, so they are implemented as subclasses of
CSSUnitValue, at least for now.
(cherry picked from commit 895276426791567f22a612c4a40fa177571cc03e)
We previously had 4 single-instance StyleValues for these keywords.
CSS-Typed-OM expects them keywords to be exposed as CSSKeywordValue, so
it's simpler to treat them the same. The single-instance behaviour is
kept by having StyleValue::create() use a cached instance for each of
these.
(cherry picked from commit f518811f73539b5ca6631084001d8f517ea292be)
For a long time, we've used two terms, inconsistently:
- "Identifier" is a spec term, but refers to a sequence of alphanumeric
characters, which may or may not be a keyword. (Keywords are a
subset of all identifiers.)
- "ValueID" is entirely non-spec, and is directly called a "keyword" in
the CSS specs.
So to avoid confusion as much as possible, let's align with the spec
terminology. I've attempted to change variable names as well, but
obviously we use Keywords in a lot of places in LibWeb and so I may
have missed some.
One exception is that I've not renamed "valid-identifiers" in
Properties.json... I'd like to combine that and the "valid-types" array
together eventually, so there's no benefit to doing an extra rename
now.
(cherry picked from commit 6a74b0164423d63904cf5a5b594772b595f57600;
very minorly amended to fix conflict in GenerateCSSKeyword.cpp caused
by #22870, and in libweb_generators.cmake due to us not having
https://github.com/LadybirdBrowser/ladybird/pull/741)
Use more widely recognized name among browser engine developers.
(cherry picked from commit 854b269338b1a1b31c0346f48dc58fa55ccf7d9f,
minorly amended due to the CornerRadius move in #24523)
For the SVG <use> element, we want to support loading HTML documents
that have a SVG element inside of it pointed to by the URL fragment.
In this situation we would need to fetch and parse the entire document
in SharedImageRequest (so that we can still cache the SVGs). Rename
SharedImageRequest to SharedResourceRequest to make the class a little
more generic for future usecases.
(cherry picked from commit a342370dfb4f1eeabc7dcb8fbe6f8e4eb6f6b1f4)
These let you format counters' current values as strings for use in
generated content.
(cherry picked from commit 898e3bd89878ddb87df06e056031673dc770be2b)
This is `counter(name, style?)` or `counters(name, link, style?)`. The
difference being, `counter()` matches only the nearest level (eg, "1"),
and `counters()` combines all the levels in the tree (eg, "3.4.1").
(cherry picked from commit 576a4314084e5c3b839006da00dddb16e58b3503)
These control the state of CSS counters.
Parsing code for `reversed(counter-name)` is implemented, but disabled
for now until we are able to resolve values for those.
(cherry picked from commit 017d6c3314d57d4e351764f328c1d25dbc9d033a)
We already have a FlyString of its value from parsing, and most users
also want a FlyString from it, so let's use that instead of converting
backwards and forwards.
The two users that did want a String are:
- Quotes, which make sense as FlyString instead, so I've converted that.
- Animation names, which should probably be FlyString too, but the code
currently also allows for other kinds of StyleValue, and I don't want
to dive into this right now to figure out if that's needed or not.
(cherry picked from commit 9fb44cb05777c6d7a8a1950258edadfcee6d4e09)
This property is now correctly parsed.
Ladybird always uses overlay scrollbars so this property does nothing.
(cherry picked from commit 662317726549cd2dde4c7902b99f0b83397a3396)
Apple Clang doesn't like this, rather than waiting for their version of
random-clang-commit-to-call-a-release to catch up with llvm trunk, just
work around the issue.
Fixes#186.
(cherry picked from commit 8c9d3b30cf62016ffb03e425f1e7e3f2461262bf)
Now that EasingStyleValue is a lot nicer to use, there isn't much reason
to keep TimingFunction around.
(cherry picked from commit 7950992fc21e2428a7f32954bbe893a2b2d58cf7,
manually amended with the output of `git clang-format master`)
The values aren't that complex, so it doesn't make much sense to have a
dedicated generator for them. Parsing them manually also allows us to
have much more control over the produced values, so as a result of this
change, EasingStyleValue becomes much more ergonomic.
(cherry picked from commit 667e313731f06fabf2a3f75893c3e8f15a4172be,
manually amended with the output of `git clang-format master`)
As the parser was trying to directly unwrap an unresolved duration.
Currently we are outputting the wrong results for the serialized
duration, but this is still a step forwards.
Fixes a crash seen on: https://evaparish.com/blog/how-i-edit
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
From https://drafts.csswg.org/css-backgrounds-4/#background-clip
"The background is painted within (clipped to) the intersection of the
border box and the geometry of the text in the element and its in-flow
and floated descendants"
This change implements it in the following way:
1. Traverse the descendants of the element, collecting the Gfx::Path of
glyphs into a vector.
2. The vector of collected paths is saved in the background painting
command.
3. The painting commands executor uses the list of glyphs to paint a
mask for background clipping.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
When the caller of NumericCalculationNode::resolve() does not provide
a percentage_basis, it expects the method to return a raw percentage
value.
Fixes crashing on https://discord.com/login
Instead of serializing two calc() values to String and then comparing
those strings, we can now compare calc() values by actually traversing
their internal CalculationNode tree.
This makes style recomputation faster on pages with lots of calc()
values since it's now much cheaper to check whether a property with
some calc() value actually changed.
This change fixes GC-leak caused by following mutual dependency:
- SVGDecodedImageData owns JS::Handle for Page.
- SVGDecodedImageData is owned by visited objects.
by making everything inherited from HTML::DecodedImageData and
ListOfAvailableImages to be GC-allocated.
Generally, if visited object has a handle, very likely we leak
everything visited from object in a handle.
Before this change, we used Gfx::Bitmap to represent both decoded
images that are not going to be mutated and bitmaps corresponding
to canvases that could be mutated.
This change introduces a wrapper for bitmaps that are not going to be
mutated, so the painter could do caching: texture caching in the case
of GPU painter and potentially scaled bitmap caching in the case of CPU
painter.
Having two ways that `<position>` is represented is awkward and
unnecessary. So, let's combine the two paths together. This first step
copies and modifies the `parse_position()` code to produce a
`PositionStyleValue`.
Apart from returning a StyleValue, this also makes use of automatic enum
parsing instead of manually comparing identifier strings.
