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)
For simplicity in user code, the `parse_foo_value()` methods should
parse anything that is a `<foo>`. In these cases, that means a
number/integer or calculation that resolves to them.
These uses in parse_css_value_for_properties() specifically only want a
literal IntegerStyleValue/NumberStyleValue, as calc-parsing is done
elsewhere. So, do the parsing for them locally.
(cherry picked from commit 79bd942dd1284112db24fd50203ff4f1fe6263b1)
Parsing a `Gfx::Color` no longer makes sense, as CSS has many ways of
defining a color, often in a dynamic way where the color value isn't
known until later. This is a small preparatory change before a much
larger color rewrite.
(cherry picked from commit 9bc71ab1fe6f5207b858bb3681f48871f3e18673)
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)
Being constrained by this macro is going to make it more difficult to
refactor our StyleValue types to match the Typed-OM spec, so let's
reintroduce the boilerplate for now.
No functional changes.
(cherry picked from commit 2e1f62681cf8c11b00eccf041aabe2d4bd5c2941)
The CSS property "text-overflow" as well as its valid identifiers are
added to the relevant json files for code generation
(cherry picked from commit a8d3c077eabc8ae833db5dda38281b9103d9bb09)
Use more widely recognized name among browser engine developers.
(cherry picked from commit 854b269338b1a1b31c0346f48dc58fa55ccf7d9f,
minorly amended due to the CornerRadius move in #24523)
This will allow users to avoid including Painter.h
(cherry picked from commit 254d040ff4f81a0e04364d5d29a25c98d580cbb5;
amended to fix conflict in Painter.cpp because we didn't remove the
scale concept, and to keep a forwarding enum in place until we've
converted the rest of our code.)
The `start` and `end` value set the text alignment based on the computed
value of `direction`. The default value of `text-align` is now `start`
instead of `left`.
(cherry picked from commit 1537d589ca4908c3631dc38e66c97fd37fa2f526)
Right now, we deviate from the CSSOM spec regarding our
CSSStyleDeclaration classes, so this is not as close to the spec as I'd
like. But it works, which means we'll be able to test pseudo-element
styling a lot more easily. :^)
(cherry picked from commit 14611de362d1d41429688dc02ffaf037a32e2e5d)
As noted, this is hacky because the parser wasn't written to allow
parsing an individual component of a selector. (Fox example, the
convenient-sounding `parse_pseudo_simple_selector()` assumes the first
colon has already been consumed...) So until that changes, this parses
the input as an entire selector-list, and then throws it away if it's
not a single pseudo-element selector.
It's only temporary though, I promise. 😅
(cherry picked from commit dae9c9be40e069989e0079745b7077dd9bab1c26)
`content` determines the element or pseudo-element's layout, including
its children.
(cherry picked from commit d58c1c1176332d3f402872cb3f7eeaf314714e2b)
This adds a motion preference to the browser UI similar to the existing
ones for color scheme and contrast.
Both AppKit UI and Qt UI has this new preference.
The auto value is currently the same as NoPreference, follow-ups can
address wiring that up to the actual preference for the OS.
(cherry picked from commit 099b77d60f6c30b4d533872fda29ea6d660ed358)
Pseudo-elements' style is only computed while building the layout tree.
This meant that previously, they would not have their style recomputed
in some cases. (Such as when :hover is applied to an ancestor.)
Now, when recomputing an element's style, we also return a full
invalidation if one or more pseudo-elements would exist either before or
after style recomputation.
This heuristic produces some false positives, but no false negatives.
Because pseudo-elements' style is computed during layout building, any
computation done here is then thrown away. So this approach minimises
the amount of wasted style computation. Plus it's simple, until we have
data on what approach would be faster.
This fixes the Acid2 nose becoming blue when the .nose div is hovered.
(cherry picked from commit 7daf5cdaff0fa1bba211ad40eadca5a0a52437ad)
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)
Not every value in a StyleProperties will be non-null by the time we
perform `revert`, so let's make a specialized function for reverting a
property instead of using the path that requires the value to be
non-null.
(cherry picked from commit a10610a1cad56294089fc9457e713eb7083312cd)
They already used TokenStream for parsing the function parameters, but
this makes the `parse_foo_gradient()` functions themselves take a
TokenStream.
(cherry picked from commit 9de73bf89b061d6f168f7c1c3278e8f203959b3a)
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
This shrinks each instance of PercentageOr by 8 bytes and avoids virtual
dispatch when resolving calc() values. It's a win-win!
Many data structures shrink as a result. An example is ComputedValues
which goes from 3376 bytes to 3024 bytes per instance.
(cherry picked from commit c282138fd0b20604384b39bfc0a8c5f6ccab56bd)
This avoids padding the style value array, shrinking StyleProperties
from 4368 bytes to 2288 bytes per instance.
(cherry picked from commit b42b7c8dd02911504e6947fc2816b85220cdcf9f)
We were saving to source declarations for *every* property, even though
we only ever looked it up for animation-name.
This patch gets rid of the per-property source pointer and we now keep
a single pointer to the animation-name source only.
This shrinks StyleProperties from 6512 bytes to 4368 bytes per instance.
(cherry picked from commit c288bfb40453d4abe95af694dfc7c2175cd04a14)
These have a few rules that we didn't follow in most cases:
- CSS-wide keywords are not allowed. (inherit, initial, etc)
- `default` is not allowed.
- The above and any other disallowed identifiers must be tested
case-insensitively.
This introduces a `parse_custom_ident_value()` method, which takes a
list of disallowed identifier names, and handles the above rules.
(cherry picked from commit 6ae2b8c3d901d8a7255046a4517fddd8b0fa84c4)
Now that `Tokenizer::tokenize()` just returns a String, there are no
errors to propagate, and we can simplify the user code a bit.
(cherry picked from commit 59778d2b365476ecb5b50218dae4457493ee7bf7)
This removes some ambiguity about what the return value should be if
the index is out of range.
Previously, we would sometimes return a JS null, and other times a JS
undefined.
It will also let us fold together the checks for whether an index is a
supported property index, followed by getting the value just afterwards.
(cherry picked from commit c5c1a8fcc78af986e5dd1a1f0bef1223e458ed37)
We don't need this for any case, so just remove it to simplify handling
in PlatformObject.
(cherry picked from commit 081c92bf3dc66773887243718cf41011289ac55e)
These let you format counters' current values as strings for use in
generated content.
(cherry picked from commit 898e3bd89878ddb87df06e056031673dc770be2b)
