Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-20 08:03:21 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/CSS/StyleValues/CSSRGB.cpp

84 lines
2.9 KiB
C++
Raw Normal View History

LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
/*
* Copyright (c) 2024, Sam Atkins <sam@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include "CSSRGB.h"
#include <AK/TypeCasts.h>
#include <LibWeb/CSS/Serialize.h>
LibWeb: Inline CSSStyleValue::to_keyword() Shaves 120 ms of loading time off of https://wpt.fyi/
2025-01-27 21:09:12 +01:00
#include <LibWeb/CSS/StyleValues/CSSKeywordValue.h>
Revert "LibWeb/CSS: Rename CalculatedStyleValue -> CSSMathValue" This reverts commit 76daba3069de4c184c6b2317d0c89b50f81a8c00. We're going to need separate types for the JS-exposed style values, so it doesn't make sense for us to match their names with our internal types.
2024-12-11 15:05:56 +00:00
#include <LibWeb/CSS/StyleValues/CalculatedStyleValue.h>
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
#include <LibWeb/CSS/StyleValues/NumberStyleValue.h>
#include <LibWeb/CSS/StyleValues/PercentageStyleValue.h>
namespace Web::CSS {
Color CSSRGB::to_color(Optional<Layout::NodeWithStyle const&>) const
{
auto resolve_rgb_to_u8 = [](CSSStyleValue const& style_value) -> Optional<u8> {
// <number> | <percentage> | none
auto normalized = [](double number) {
LibWeb/CSS: Interpret NaN as 0 when resolving alpha and rgb values Fixes the crash in css/css-color/parsing/color-valid-hwb.html. The crash was probably introduced in 248e4bb5, as it was the first commit to VERIFY that the value given to `Color::with_opacity` were in the correct range. As the values in color-valid-hwb.html were resolved as NaN, the check never passed.
2024-12-02 23:59:57 -05:00
if (isnan(number))
number = 0;
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
return llround(clamp(number, 0.0, 255.0));
};
if (style_value.is_number())
return normalized(style_value.as_number().number());
if (style_value.is_percentage())
LibWeb/CSS: Tweak in CSSRGB::to_color() to avoid floating point errors Example of the difference: 50 * 2.55 --> 127.4999 --> round towards +∞ --> 127 50 * 255 / 100 --> 127.5000 --> round towards +∞ --> 128 Now, 9 failing WPT tests in /css/css-color/ pass.
2024-10-18 09:40:13 +00:00
return normalized(style_value.as_percentage().value() * 255 / 100);
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
Revert "LibWeb/CSS: Rename CalculatedStyleValue -> CSSMathValue" This reverts commit 76daba3069de4c184c6b2317d0c89b50f81a8c00. We're going to need separate types for the JS-exposed style values, so it doesn't make sense for us to match their names with our internal types.
2024-12-11 15:05:56 +00:00
if (style_value.is_calculated()) {
auto const& calculated = style_value.as_calculated();
LibWeb/CSS: Wrap calc()-resolution data in a struct Initially I added this to the existing CalculationContext, but in reality, we have some data at parse-time and different data at resolve-time, so it made more sense to keep those separate. Instead of needing a variety of methods for resolving a Foo, depending on whether we have a Layout::Node available, or a percentage basis, or a length resolution context... put those in a CalculationResolutionContext, and just pass that one thing to these methods. This also removes the need for separate resolve_*_percentage() methods, because we can just pass the percentage basis in to the regular resolve_foo() method. This also corrects the issue that *any* calculation may need to resolve lengths, but we previously only passed a length resolution context to specific types in some situations. Now, they can all have one available, though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
CalculationResolutionContext context {};
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
if (calculated.resolves_to_number())
LibWeb/CSS: Wrap calc()-resolution data in a struct Initially I added this to the existing CalculationContext, but in reality, we have some data at parse-time and different data at resolve-time, so it made more sense to keep those separate. Instead of needing a variety of methods for resolving a Foo, depending on whether we have a Layout::Node available, or a percentage basis, or a length resolution context... put those in a CalculationResolutionContext, and just pass that one thing to these methods. This also removes the need for separate resolve_*_percentage() methods, because we can just pass the percentage basis in to the regular resolve_foo() method. This also corrects the issue that *any* calculation may need to resolve lengths, but we previously only passed a length resolution context to specific types in some situations. Now, they can all have one available, though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
return normalized(calculated.resolve_number(context).value());
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
if (calculated.resolves_to_percentage())
LibWeb/CSS: Wrap calc()-resolution data in a struct Initially I added this to the existing CalculationContext, but in reality, we have some data at parse-time and different data at resolve-time, so it made more sense to keep those separate. Instead of needing a variety of methods for resolving a Foo, depending on whether we have a Layout::Node available, or a percentage basis, or a length resolution context... put those in a CalculationResolutionContext, and just pass that one thing to these methods. This also removes the need for separate resolve_*_percentage() methods, because we can just pass the percentage basis in to the regular resolve_foo() method. This also corrects the issue that *any* calculation may need to resolve lengths, but we previously only passed a length resolution context to specific types in some situations. Now, they can all have one available, though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
return normalized(calculated.resolve_percentage(context).value().value() * 255 / 100);
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
}
if (style_value.is_keyword() && style_value.to_keyword() == Keyword::None)
return 0;
return {};
};
auto resolve_alpha_to_u8 = [](CSSStyleValue const& style_value) -> Optional<u8> {
auto alpha_0_1 = resolve_alpha(style_value);
if (alpha_0_1.has_value())
LibWeb/CSS: Avoid double promotion in CSSColorValue code Co-authored-by: Nico Weber <thakis@chromium.org>
2024-11-06 10:20:45 +00:00
return llround(clamp(alpha_0_1.value() * 255.0f, 0.0f, 255.0f));
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
return {};
};
u8 const r_val = resolve_rgb_to_u8(m_properties.r).value_or(0);
u8 const g_val = resolve_rgb_to_u8(m_properties.g).value_or(0);
u8 const b_val = resolve_rgb_to_u8(m_properties.b).value_or(0);
u8 const alpha_val = resolve_alpha_to_u8(m_properties.alpha).value_or(255);
return Color(r_val, g_val, b_val, alpha_val);
}
bool CSSRGB::equals(CSSStyleValue const& other) const
{
if (type() != other.type())
return false;
auto const& other_color = other.as_color();
if (color_type() != other_color.color_type())
return false;
LibWeb: Skip dynamic_cast in CSSRGB after we already did a type check
2025-04-18 10:33:19 +02:00
auto const& other_rgb = static_cast<CSSRGB const&>(other_color);
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
return m_properties == other_rgb.m_properties;
}
// https://www.w3.org/TR/css-color-4/#serializing-sRGB-values
LibWeb: Don't serialize resolved CSS color values as named colors With all the plumbing in place, we can handle this quirk at the serialization layer. This allows us to remove the pass where StyleComputer would loop over all computed values and replace any color values with new values stripped of their original name strings.
2024-12-07 01:11:35 +01:00
String CSSRGB::to_string(SerializationMode mode) const
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
{
// FIXME: Do this properly, taking unresolved calculated values into account.
LibWeb: Don't serialize resolved CSS color values as named colors With all the plumbing in place, we can handle this quirk at the serialization layer. This allows us to remove the pass where StyleComputer would loop over all computed values and replace any color values with new values stripped of their original name strings.
2024-12-07 01:11:35 +01:00
if (mode != SerializationMode::ResolvedValue && m_properties.name.has_value())
LibWeb: Store CSS color name in CSSRGB When serializing an sRGB color value that originated from a named color, it should return the color name converted to ASCII lowercase. This requires storing the color name (if it has one). This change also requires explicitly removing the color names when computing style, because computed color values do not retain their name. It also requires removing a caching optimization in create_from_color(), because adding the name means that the cached value might be wrong. This fixes some WPT subtests, and also required updating some of our own tests.
2024-11-24 18:47:15 +01:00
return m_properties.name.value().to_string().to_ascii_lowercase();
LibWeb: Introduce color-function-specific style values 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. :^)
2024-08-16 16:42:16 +01:00
return serialize_a_srgb_value(to_color({}));
}
}
Reference in a new issue Copy permalink