Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/CSS/StyleValues/CalculatedStyleValue.h

800 lines
38 KiB
C
Raw Normal View History

LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2018-2020, Andreas Kling <andreas@ladybird.org>
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
* Copyright (c) 2021, Tobias Christiansen <tobyase@serenityos.org>
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
* Copyright (c) 2021-2025, Sam Atkins <sam@ladybird.org>
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
* Copyright (c) 2022-2023, MacDue <macdue@dueutil.tech>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
#include <AK/Function.h>
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
#include <LibWeb/CSS/Angle.h>
LibWeb/CSS: Remove unused includes from CSSStyleValue.h A couple of these were needed transitively, so I've added them to the relevant files.
2025-02-17 16:21:50 +00:00
#include <LibWeb/CSS/Enums.h>
LibWeb: Implement Flex and FlexStyleValue types
2023-09-28 15:18:14 +01:00
#include <LibWeb/CSS/Flex.h>
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
#include <LibWeb/CSS/Frequency.h>
#include <LibWeb/CSS/Length.h>
LibWeb: Remove unnecessary includes in Percentage.h
2025-08-06 22:15:01 +12:00
#include <LibWeb/CSS/Number.h>
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
#include <LibWeb/CSS/NumericType.h>
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
#include <LibWeb/CSS/Percentage.h>
LibWeb: Make resolution calculable No tests unfortunately, because no CSS property we currently support accepts `<resolution>`.
2023-12-30 17:05:23 +00:00
#include <LibWeb/CSS/Resolution.h>
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
#include <LibWeb/CSS/StyleValues/StyleValue.h>
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
#include <LibWeb/CSS/Time.h>
namespace Web::CSS {
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
class CalculationNode;
LibWeb/CSS: Link CalculationContext to new spec definition Corresponds to https://github.com/w3c/csswg-drafts/commit/ad244f3413a683e431676caabb432822730808f2 There's nothing that we need to do differently I think, but it's nice to have a clear spec definition to refer to. :^)
2025-06-17 10:59:50 +01:00
// https://drafts.csswg.org/css-values-4/#calc-context
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
// Contains the context available at parse-time.
LibWeb/CSS: Give calc() a CalculationContext for resolving percentages This is passed in at construction, meaning we will be able to refer to it later, when we're no longer inside the Parser.
2025-01-08 16:14:17 +00:00
struct CalculationContext {
Optional<ValueType> percentages_resolve_as {};
LibWeb/CSS: Tell CalculationContext whether to treat numbers as integers Calc simplification eventually produces a single style-value as its output. This extra context data will let us know whether a calculated number should be treated as a `<number>` or an `<integer>`, so that for example, `z-index: 12` and `z-index: calc(12)` both produce an `IntegerStyleValue` containing 12.
2025-01-28 15:49:55 +00:00
bool resolve_numbers_as_integers = false;
LibWeb/Meta: Compute the accepted value range for CalculationContexts This currently only applies to property-level calculation contexts, more work to be done to generate accepted ranges for other calculation contexts (e.g. within transformation functions, color functions, etc)
2025-08-06 16:09:09 +12:00
AcceptedTypeRangeMap accepted_type_ranges {};
LibWeb/CSS: Give calc() a CalculationContext for resolving percentages This is passed in at construction, meaning we will be able to refer to it later, when we're no longer inside the Parser.
2025-01-08 16:14:17 +00:00
};
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
class CalculatedStyleValue : public StyleValue {
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
public:
class CalculationResult {
public:
LibWeb: Make resolution calculable No tests unfortunately, because no CSS property we currently support accepts `<resolution>`.
2023-12-30 17:05:23 +00:00
using Value = Variant<Number, Angle, Flex, Frequency, Length, Percentage, Resolution, Time>;
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
static CalculationResult from_value(Value const&, CalculationResolutionContext const&, Optional<NumericType>);
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
CalculationResult(double value, Optional<NumericType> type)
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
: m_value(value)
, m_type(move(type))
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
{
}
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
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
void add(CalculationResult const& other);
void subtract(CalculationResult const& other);
void multiply_by(CalculationResult const& other);
void divide_by(CalculationResult const& other);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
void negate();
void invert();
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
double value() const { return m_value; }
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
Optional<NumericType> const& type() const { return m_type; }
LibWeb: Use correct resolved type for round() CSS function Function is defined as `round(<rounding-strategy>?, A, B?)` With this change resolved type is `typeof(resolve(A))`, instead of `typeof(A)`. For example `round(up, 20%, 1px)` with 200px percentage basis is now correctly resolved in 40px instead of 40%. Progress on https://www.notion.so/ landing page.
2024-09-17 17:51:48 +02:00
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
[[nodiscard]] bool operator==(CalculationResult const&) const = default;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
private:
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
double m_value;
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
Optional<NumericType> m_type;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
};
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
static ValueComparingNonnullRefPtr<CalculatedStyleValue const> create(NonnullRefPtr<CalculationNode const> calculation, NumericType resolved_type, CalculationContext context)
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
{
LibWeb/CSS: Give calc() a CalculationContext for resolving percentages This is passed in at construction, meaning we will be able to refer to it later, when we're no longer inside the Parser.
2025-01-08 16:14:17 +00:00
return adopt_ref(*new (nothrow) CalculatedStyleValue(move(calculation), move(resolved_type), move(context)));
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
}
LibWeb: Add mode flag to CSSStyleValue::to_string() This will be used to differentiate between serialization for resolved style (i.e window.getComputedStyle()) and serialization for all other purposes.
2024-12-07 00:59:49 +01:00
virtual String to_string(SerializationMode) const override;
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
virtual ValueComparingNonnullRefPtr<StyleValue const> absolutized(CSSPixelRect const& viewport_rect, Length::FontMetrics const& font_metrics, Length::FontMetrics const& root_font_metrics) const override;
virtual bool equals(StyleValue const& other) const override;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
bool resolves_to_angle() const { return m_resolved_type.matches_angle(m_context.percentages_resolve_as); }
bool resolves_to_angle_percentage() const { return m_resolved_type.matches_angle_percentage(m_context.percentages_resolve_as); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<Angle> resolve_angle_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<Angle> resolve_angle(CalculationResolutionContext const&) const;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
bool resolves_to_flex() const { return m_resolved_type.matches_flex(m_context.percentages_resolve_as); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<Flex> resolve_flex_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<Flex> resolve_flex(CalculationResolutionContext const&) const;
LibWeb: Implement Flex and FlexStyleValue types
2023-09-28 15:18:14 +01:00
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
bool resolves_to_frequency() const { return m_resolved_type.matches_frequency(m_context.percentages_resolve_as); }
bool resolves_to_frequency_percentage() const { return m_resolved_type.matches_frequency_percentage(m_context.percentages_resolve_as); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<Frequency> resolve_frequency_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<Frequency> resolve_frequency(CalculationResolutionContext const&) const;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
bool resolves_to_length() const { return m_resolved_type.matches_length(m_context.percentages_resolve_as); }
bool resolves_to_length_percentage() const { return m_resolved_type.matches_length_percentage(m_context.percentages_resolve_as); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<Length> resolve_length_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<Length> resolve_length(CalculationResolutionContext const&) const;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb: Use CSSNumericType for CalculatedStyleValue resolved type
2023-06-30 16:29:06 +01:00
bool resolves_to_percentage() const { return m_resolved_type.matches_percentage(); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<Percentage> resolve_percentage_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<Percentage> resolve_percentage(CalculationResolutionContext const&) const;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
bool resolves_to_resolution() const { return m_resolved_type.matches_resolution(m_context.percentages_resolve_as); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<Resolution> resolve_resolution_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<Resolution> resolve_resolution(CalculationResolutionContext const&) const;
LibWeb: Make resolution calculable No tests unfortunately, because no CSS property we currently support accepts `<resolution>`.
2023-12-30 17:05:23 +00:00
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
bool resolves_to_time() const { return m_resolved_type.matches_time(m_context.percentages_resolve_as); }
bool resolves_to_time_percentage() const { return m_resolved_type.matches_time_percentage(m_context.percentages_resolve_as); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<Time> resolve_time_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<Time> resolve_time(CalculationResolutionContext const&) const;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
bool resolves_to_number() const { return m_resolved_type.matches_number(m_context.percentages_resolve_as); }
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<double> resolve_number_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<double> resolve_number(CalculationResolutionContext const&) const;
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
Optional<i64> resolve_integer_deprecated(CalculationResolutionContext const&) const;
LibWeb: Add new `CalculatedStyleValue::resolve_*` methods These new methods are built on top of the spec's `simplify_a_calculation_tree` algorithm where the old methods were ad-hoc. These methods are not used anywhere yet as callers will need to be migrated over from the deprecated methods one-by-one to account for differences in behaviour. No functionality changes.
2025-07-02 19:50:16 +12:00
Optional<i64> resolve_integer(CalculationResolutionContext const&) const;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
LibWeb/CSS: Introduce helper methods for parsing numeric values "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.
2024-08-16 09:41:10 +01:00
bool resolves_to_dimension() const { return m_resolved_type.matches_dimension(); }
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
bool contains_percentage() const;
LibWeb/CSS: Add dump method to CalculatedStyleValue The individual nodes all have dump methods, but there was no way of calling them from the outside. So now there is.
2024-08-16 16:42:58 +01:00
String dump() const;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ref<CSSStyleValue> reify(JS::Realm&, String const& associated_property) const override;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
explicit CalculatedStyleValue(NonnullRefPtr<CalculationNode const> calculation, NumericType resolved_type, CalculationContext context)
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
: StyleValue(Type::Calculated)
LibWeb/CSS: Give calc() a CalculationContext for resolving percentages This is passed in at construction, meaning we will be able to refer to it later, when we're no longer inside the Parser.
2025-01-08 16:14:17 +00:00
, m_resolved_type(move(resolved_type))
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
, m_calculation(move(calculation))
LibWeb/CSS: Give calc() a CalculationContext for resolving percentages This is passed in at construction, meaning we will be able to refer to it later, when we're no longer inside the Parser.
2025-01-08 16:14:17 +00:00
, m_context(move(context))
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
{
}
LibWeb: Return an intermediate struct from `CSV::resolve_value` Returning this struct will allow us to modify the underlying value of the `CalculationResult` without requiring us to go through the process of constructing a whole new `CalculationResult` to return.
2025-08-06 16:16:43 +12:00
struct ResolvedValue {
double value;
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
Optional<NumericType> type;
LibWeb: Return an intermediate struct from `CSV::resolve_value` Returning this struct will allow us to modify the underlying value of the `CalculationResult` without requiring us to go through the process of constructing a whole new `CalculationResult` to return.
2025-08-06 16:16:43 +12:00
};
Optional<ResolvedValue> resolve_value(CalculationResolutionContext const&) const;
LibWeb/CSS: Use CalcSV's context to determine what percentages are This lets us implement the `matches_number()` and `matches_dimension()` methods of `CSSNumericType` to spec, instead of being an ad-hoc hack.
2025-01-09 17:23:20 +00:00
Optional<ValueType> percentage_resolved_type() const;
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
NumericType m_resolved_type;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<CalculationNode const> m_calculation;
LibWeb/CSS: Give calc() a CalculationContext for resolving percentages This is passed in at construction, meaning we will be able to refer to it later, when we're no longer inside the Parser.
2025-01-08 16:14:17 +00:00
CalculationContext m_context;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
};
// https://www.w3.org/TR/css-values-4/#calculation-tree
LibWeb/CSS: Make CalculationNodes ref-counted Calc simplification (which I'm working towards) involves repeatedly deriving a new calculation tree from an existing one, and in many cases, either the whole result or a portion of it will be identical to that of the original. Using RefPtr lets us avoid making unnecessary copies. As a bonus it will also make it easier to return either `this` or a new node. In future we could also cache commonly-used nodes, similar to how we do so for 1px and 0px LengthStyleValues and various keywords.
2025-01-22 16:50:54 +00:00
class CalculationNode : public RefCounted<CalculationNode> {
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
public:
enum class Type {
Numeric,
// NOTE: Currently, any value with a `var()` or `attr()` function in it is always an
// UnresolvedStyleValue so we do not have to implement a NonMathFunction type here.
LibWeb: Parse `min()` css math function
2023-05-26 11:21:49 +02:00
// Comparison function nodes, a sub-type of operator node
// https://drafts.csswg.org/css-values-4/#comp-func
Min,
Max,
Clamp,
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
// Calc-operator nodes, a sub-type of operator node
// https://www.w3.org/TR/css-values-4/#calculation-tree-calc-operator-nodes
Sum,
Product,
Negate,
Invert,
LibWeb: Implement CSS `abs()`
2023-05-27 22:56:41 +02:00
// Sign-Related Functions, a sub-type of operator node
// https://drafts.csswg.org/css-values-4/#sign-funcs
Abs,
Sign,
LibWeb: Implement CSS `sin()`
2023-05-27 23:50:33 +02:00
// Trigonometric functions, a sub-type of operator node
// https://drafts.csswg.org/css-values-4/#trig-funcs
Sin,
Cos,
Tan,
Asin,
Acos,
Atan,
Atan2,
LibWeb: Implement CSS `pow()`
2023-05-28 11:26:42 +02:00
// Exponential functions, a sub-type of operator node
// https://drafts.csswg.org/css-values-4/#exponent-funcs
Pow,
Sqrt,
Hypot,
Log,
Exp,
LibWeb: Implement CSS `round()`
2023-05-27 16:07:50 +02:00
// Stepped value functions, a sub-type of operator node
// https://drafts.csswg.org/css-values-4/#round-func
Round,
Mod,
Rem,
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +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
using NumericValue = CalculatedStyleValue::CalculationResult::Value;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
virtual ~CalculationNode();
Type type() const { return m_type; }
LibWeb: Return true for `is_operator_node()` for math-function nodes
2023-07-04 16:08:19 +01:00
// https://www.w3.org/TR/css-values-4/#calculation-tree-operator-nodes
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
bool is_operator_node() const
{
LibWeb: Return true for `is_operator_node()` for math-function nodes
2023-07-04 16:08:19 +01:00
return is_calc_operator_node() || is_math_function_node();
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
}
LibWeb: Return true for `is_operator_node()` for math-function nodes
2023-07-04 16:08:19 +01:00
bool is_math_function_node() const
{
switch (m_type) {
case Type::Min:
case Type::Max:
case Type::Clamp:
case Type::Abs:
case Type::Sign:
case Type::Sin:
case Type::Cos:
case Type::Tan:
case Type::Asin:
case Type::Acos:
case Type::Atan:
case Type::Atan2:
case Type::Pow:
case Type::Sqrt:
case Type::Hypot:
case Type::Log:
case Type::Exp:
case Type::Round:
case Type::Mod:
case Type::Rem:
return true;
default:
return false;
}
}
// https://www.w3.org/TR/css-values-4/#calculation-tree-calc-operator-nodes
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
bool is_calc_operator_node() const
{
return first_is_one_of(m_type, Type::Sum, Type::Product, Type::Negate, Type::Invert);
}
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
StringView name() const;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const = 0;
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
Optional<NumericType> const& numeric_type() const { return m_numeric_type; }
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
virtual bool contains_percentage() const = 0;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const = 0;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const = 0;
// Step 4 of simpliRfy_a_calculation_tree(). Only valid for math-function nodes.
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const { VERIFY_NOT_REACHED(); }
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const = 0;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const = 0;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const { return nullptr; }
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
protected:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
CalculationNode(Type, Optional<NumericType>);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
private:
Type m_type;
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
Optional<NumericType> m_numeric_type;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
};
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
enum class NonFiniteValue {
Infinity,
NegativeInfinity,
NaN,
};
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
class NumericCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<NumericCalculationNode const> create(NumericValue, CalculationContext const&);
static RefPtr<NumericCalculationNode const> from_keyword(Keyword, CalculationContext const&);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
~NumericCalculationNode();
virtual bool contains_percentage() const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
bool is_in_canonical_unit() const;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override { return *this; }
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
RefPtr<StyleValue const> to_style_value(CalculationContext const&) const;
LibWeb/CSS: Simplify calculations after parsing them If a calculation was simplified down to a single numeric node, then most of the time we can instead return a regular StyleValue, for example `calc(2px + 3px)` would be simplified down to a `5px` LengthStyleValue. This means that parse_calculated_value() can't return a CalculatedStyleValue directly, and its callers all have to handle non-calculated values as well as calculated ones. This simplification is reflected in the new test results. Serialization is not yet correct in all cases but we're closer than we were. :^)
2025-01-28 16:24:39 +00:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return {}; }
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
NumericValue const& value() const { return m_value; }
LibWeb/CSS: Remove now-redundant CalculationNode::to_string() The main users were the `dump()` functions, which now dump their children instead, which is more correct anyway. The others are for serializing numeric values, so NumericCalculationNode's to_string() is renamed to value_to_string () and used for those for convenience.
2025-02-27 14:07:04 +00:00
String value_to_string() const;
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
Optional<NonFiniteValue> infinite_or_nan_value() const;
bool is_negative() const;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<NumericCalculationNode const> negated(CalculationContext const&) const;
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
NumericCalculationNode(NumericValue, NumericType);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
NumericValue m_value;
};
class SumCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<SumCalculationNode const> create(Vector<NonnullRefPtr<CalculationNode const>>);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
~SumCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return m_values; }
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
SumCalculationNode(Vector<NonnullRefPtr<CalculationNode const>>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
Vector<NonnullRefPtr<CalculationNode const>> m_values;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
};
class ProductCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<ProductCalculationNode const> create(Vector<NonnullRefPtr<CalculationNode const>>);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
~ProductCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return m_values; }
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
ProductCalculationNode(Vector<NonnullRefPtr<CalculationNode const>>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
Vector<NonnullRefPtr<CalculationNode const>> m_values;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
};
class NegateCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<NegateCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
~NegateCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
CalculationNode const& child() const { return m_value; }
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit NegateCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
};
class InvertCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<InvertCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
~InvertCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
CalculationNode const& child() const { return m_value; }
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Reimplement CalculatedStyleValue as a calculation node tree VALUES-4 defines the internal representation of `calc()` as a tree of calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal ) VALUES-3 lacked any definition here, so we had our own ad-hoc implementation based around the spec grammar. This commit replaces that with CalculationNodes representing each possible node in the tree. There are no intended functional changes, though we do now support nested calc() which previously did not work. For example: `width: calc( 42 * calc(3 + 7) );` I have added an example of this to our test page. A couple of the layout tests that used `calc()` now return values that are 0.5px different from before. There's no visual difference, so I have updated the tests to use the new results.
2023-04-11 15:48:06 +01:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
InvertCalculationNode(NonnullRefPtr<CalculationNode const>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
};
LibWeb: Parse `min()` css math function
2023-05-26 11:21:49 +02:00
class MinCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<MinCalculationNode const> create(Vector<NonnullRefPtr<CalculationNode const>>);
LibWeb: Parse `min()` css math function
2023-05-26 11:21:49 +02:00
~MinCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return m_values; }
LibWeb: Parse `min()` css math function
2023-05-26 11:21:49 +02:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Parse `min()` css math function
2023-05-26 11:21:49 +02:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
MinCalculationNode(Vector<NonnullRefPtr<CalculationNode const>>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
Vector<NonnullRefPtr<CalculationNode const>> m_values;
LibWeb: Parse `min()` css math function
2023-05-26 11:21:49 +02:00
};
LibWeb: Parse `max()` css math function
2023-05-26 15:00:22 +02:00
class MaxCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<MaxCalculationNode const> create(Vector<NonnullRefPtr<CalculationNode const>>);
LibWeb: Parse `max()` css math function
2023-05-26 15:00:22 +02:00
~MaxCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return m_values; }
LibWeb/CSS: Use CSSNumericType for CalculationResult's numeric type When we originally implemented calc(), the result of a calculation was guaranteed to be a single CSS type like a Length or Angle. However, CSS Values 4 now allows more complex type arithmetic, which is represented by the CSSNumericType class. Using that directly makes us more correct, and allows us to remove a large amount of now ad-hoc code. Unfortunately this is a large commit but the changes it makes are interconnected enough that doing one at a time causes test regressions. In no particular order: - Update our "determine the type of a calculation" code to match the newest spec, which sets percent hints in a couple more cases. (One of these we're skipping for now, I think it fails because of the FIXMEs in CSSNumericType::matches_foo().) - Make the generated math-function-parsing code aware of the difference between arguments being the same type, and being "consistent" types, for each function. Otherwise those extra percent hints would cause them to fail validation incorrectly. - Use the CSSNumericType as the type for the CalculationResult. - Calculate and assign each math function's type in its constructor, instead of calculating it repeatedly on-demand. The `CalculationNode::resolved_type()` method is now entirely unused and has been removed.
2024-12-18 13:15:26 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Parse `max()` css math function
2023-05-26 15:00:22 +02:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
MaxCalculationNode(Vector<NonnullRefPtr<CalculationNode const>>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
Vector<NonnullRefPtr<CalculationNode const>> m_values;
LibWeb: Parse `max()` css math function
2023-05-26 15:00:22 +02:00
};
LibWeb: Parse `clamp()` css math function
2023-05-26 15:40:39 +02:00
class ClampCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<ClampCalculationNode const> create(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
LibWeb: Parse `clamp()` css math function
2023-05-26 15:40:39 +02:00
~ClampCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Parse `clamp()` css math function
2023-05-26 15:40:39 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_min_value, m_center_value, m_max_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb/CSS: Reify math functions into CSSMathValue types
2025-08-22 11:10:24 +01:00
virtual GC::Ptr<CSSNumericValue> reify(JS::Realm&) const override;
LibWeb: Parse `clamp()` css math function
2023-05-26 15:40:39 +02:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
ClampCalculationNode(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<CalculationNode const> m_min_value;
NonnullRefPtr<CalculationNode const> m_center_value;
NonnullRefPtr<CalculationNode const> m_max_value;
LibWeb: Parse `clamp()` css math function
2023-05-26 15:40:39 +02:00
};
LibWeb: Implement CSS `abs()`
2023-05-27 22:56:41 +02:00
class AbsCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<AbsCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `abs()`
2023-05-27 22:56:41 +02:00
~AbsCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `abs()`
2023-05-27 22:56:41 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `abs()`
2023-05-27 22:56:41 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit AbsCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `abs()`
2023-05-27 22:56:41 +02:00
};
LibWeb: Implement CSS `sign()`
2023-05-27 23:02:39 +02:00
class SignCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<SignCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `sign()`
2023-05-27 23:02:39 +02:00
~SignCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `sign()`
2023-05-27 23:02:39 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `sign()`
2023-05-27 23:02:39 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit SignCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `sign()`
2023-05-27 23:02:39 +02:00
};
LibWeb: Implement CSS `sin()`
2023-05-27 23:50:33 +02:00
class SinCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<SinCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `sin()`
2023-05-27 23:50:33 +02:00
~SinCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `sin()`
2023-05-27 23:50:33 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `sin()`
2023-05-27 23:50:33 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit SinCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `sin()`
2023-05-27 23:50:33 +02:00
};
LibWeb: Implement CSS `cos()`
2023-05-27 23:57:01 +02:00
class CosCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<CosCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `cos()`
2023-05-27 23:57:01 +02:00
~CosCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `cos()`
2023-05-27 23:57:01 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `cos()`
2023-05-27 23:57:01 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit CosCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `cos()`
2023-05-27 23:57:01 +02:00
};
LibWeb: Implement CSS `tan()`
2023-05-28 00:02:43 +02:00
class TanCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<TanCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `tan()`
2023-05-28 00:02:43 +02:00
~TanCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `tan()`
2023-05-28 00:02:43 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `tan()`
2023-05-28 00:02:43 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit TanCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `tan()`
2023-05-28 00:02:43 +02:00
};
LibWeb: Implement CSS `asin()`
2023-05-28 10:55:52 +02:00
class AsinCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<AsinCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `asin()`
2023-05-28 10:55:52 +02:00
~AsinCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `asin()`
2023-05-28 10:55:52 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `asin()`
2023-05-28 10:55:52 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit AsinCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `asin()`
2023-05-28 10:55:52 +02:00
};
LibWeb: Implement CSS `acos()`
2023-05-28 11:00:35 +02:00
class AcosCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<AcosCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `acos()`
2023-05-28 11:00:35 +02:00
~AcosCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `acos()`
2023-05-28 11:00:35 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `acos()`
2023-05-28 11:00:35 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit AcosCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `acos()`
2023-05-28 11:00:35 +02:00
};
LibWeb: Implement CSS `atan()`
2023-05-28 11:04:57 +02:00
class AtanCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<AtanCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `atan()`
2023-05-28 11:04:57 +02:00
~AtanCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `atan()`
2023-05-28 11:04:57 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `atan()`
2023-05-28 11:04:57 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit AtanCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `atan()`
2023-05-28 11:04:57 +02:00
};
LibWeb: Implement CSS `atan2()`
2023-05-28 11:19:10 +02:00
class Atan2CalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<Atan2CalculationNode const> create(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `atan2()`
2023-05-28 11:19:10 +02:00
~Atan2CalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `atan2()`
2023-05-28 11:19:10 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_y, m_x } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `atan2()`
2023-05-28 11:19:10 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
Atan2CalculationNode(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_y;
NonnullRefPtr<CalculationNode const> m_x;
LibWeb: Implement CSS `atan2()`
2023-05-28 11:19:10 +02:00
};
LibWeb: Implement CSS `pow()`
2023-05-28 11:26:42 +02:00
class PowCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<PowCalculationNode const> create(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `pow()`
2023-05-28 11:26:42 +02:00
~PowCalculationNode();
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
virtual bool contains_percentage() const override { return false; }
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `pow()`
2023-05-28 11:26:42 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_x, m_y } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `pow()`
2023-05-28 11:26:42 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
PowCalculationNode(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_x;
NonnullRefPtr<CalculationNode const> m_y;
LibWeb: Implement CSS `pow()`
2023-05-28 11:26:42 +02:00
};
LibWeb: Implement CSS `sqrt()`
2023-05-28 11:31:50 +02:00
class SqrtCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<SqrtCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `sqrt()`
2023-05-28 11:31:50 +02:00
~SqrtCalculationNode();
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
virtual bool contains_percentage() const override { return false; }
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `sqrt()`
2023-05-28 11:31:50 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `sqrt()`
2023-05-28 11:31:50 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit SqrtCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `sqrt()`
2023-05-28 11:31:50 +02:00
};
LibWeb: Implement CSS `hypot()`
2023-05-28 11:43:04 +02:00
class HypotCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<HypotCalculationNode const> create(Vector<NonnullRefPtr<CalculationNode const>>);
LibWeb: Implement CSS `hypot()`
2023-05-28 11:43:04 +02:00
~HypotCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return m_values; }
LibWeb: Implement CSS `hypot()`
2023-05-28 11:43:04 +02:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `hypot()`
2023-05-28 11:43:04 +02:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
HypotCalculationNode(Vector<NonnullRefPtr<CalculationNode const>>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
Vector<NonnullRefPtr<CalculationNode const>> m_values;
LibWeb: Implement CSS `hypot()`
2023-05-28 11:43:04 +02:00
};
LibWeb: Implement CSS `log()`
2023-05-28 11:53:57 +02:00
class LogCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<LogCalculationNode const> create(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `log()`
2023-05-28 11:53:57 +02:00
~LogCalculationNode();
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
virtual bool contains_percentage() const override { return false; }
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `log()`
2023-05-28 11:53:57 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_x, m_y } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `log()`
2023-05-28 11:53:57 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
LogCalculationNode(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_x;
NonnullRefPtr<CalculationNode const> m_y;
LibWeb: Implement CSS `log()`
2023-05-28 11:53:57 +02:00
};
LibWeb: Implement CSS `exp()`
2023-05-28 11:58:30 +02:00
class ExpCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<ExpCalculationNode const> create(NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `exp()`
2023-05-28 11:58:30 +02:00
~ExpCalculationNode();
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
virtual bool contains_percentage() const override { return false; }
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `exp()`
2023-05-28 11:58:30 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_value } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `exp()`
2023-05-28 11:58:30 +02:00
private:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
explicit ExpCalculationNode(NonnullRefPtr<CalculationNode const>);
NonnullRefPtr<CalculationNode const> m_value;
LibWeb: Implement CSS `exp()`
2023-05-28 11:58:30 +02:00
};
LibWeb: Implement CSS `round()`
2023-05-27 16:07:50 +02:00
class RoundCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<RoundCalculationNode const> create(RoundingStrategy, NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `round()`
2023-05-27 16:07:50 +02:00
~RoundCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `round()`
2023-05-27 16:07:50 +02:00
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
// NOTE: This excludes the rounding strategy!
RoundingStrategy rounding_strategy() const { return m_strategy; }
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_x, m_y } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `round()`
2023-05-27 16:07:50 +02:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
RoundCalculationNode(RoundingStrategy, NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>, Optional<NumericType>);
LibWeb: Move RoundingMode to Enums.json In the spec this is a `<rounding-strategy>`, so let's use that name. This also fixes a bug where we were serializing `to-zero` as `toward-zero`.
2023-07-13 14:51:11 +01:00
RoundingStrategy m_strategy;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<CalculationNode const> m_x;
NonnullRefPtr<CalculationNode const> m_y;
LibWeb: Implement CSS `round()`
2023-05-27 16:07:50 +02:00
};
LibWeb: Implement CSS `mod()`
2023-05-27 19:03:07 +02:00
class ModCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<ModCalculationNode const> create(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `mod()`
2023-05-27 19:03:07 +02:00
~ModCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `mod()`
2023-05-27 19:03:07 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_x, m_y } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `mod()`
2023-05-27 19:03:07 +02:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
ModCalculationNode(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<CalculationNode const> m_x;
NonnullRefPtr<CalculationNode const> m_y;
LibWeb: Implement CSS `mod()`
2023-05-27 19:03:07 +02:00
};
LibWeb: Implement CSS `rem()`
2023-05-27 19:08:07 +02:00
class RemCalculationNode final : public CalculationNode {
public:
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
static NonnullRefPtr<RemCalculationNode const> create(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>);
LibWeb: Implement CSS `rem()`
2023-05-27 19:08:07 +02:00
~RemCalculationNode();
virtual bool contains_percentage() const override;
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
virtual CalculatedStyleValue::CalculationResult resolve(CalculationResolutionContext const&) const override;
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual NonnullRefPtr<CalculationNode const> with_simplified_children(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
virtual Optional<CalculatedStyleValue::CalculationResult> run_operation_if_possible(CalculationContext const&, CalculationResolutionContext const&) const override;
LibWeb: Implement CSS `rem()`
2023-05-27 19:08:07 +02:00
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
virtual Vector<NonnullRefPtr<CalculationNode const>> children() const override { return { { m_x, m_y } }; }
LibWeb/CSS: Implement calc-serialization spec algorithms This gets us 37 new subtest passes in css/css-values, and 13 passes in our other in-tree tests (and probably some random other ones!) As noted in comments, a few parts of this algorithm have ad-hoc behaviour to handle some issues in the spec.
2025-02-26 14:08:20 +00:00
LibWeb: Make CalculatedStyleValue::dump() infallible
2023-08-22 14:13:22 +01:00
virtual void dump(StringBuilder&, int indent) const override;
LibWeb: Implement calc() value equality check in a more efficient way 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.
2024-01-09 12:41:43 +01:00
virtual bool equals(CalculationNode const&) const override;
LibWeb: Implement CSS `rem()`
2023-05-27 19:08:07 +02:00
private:
LibWeb/CSS: Rename CSSNumericType to NumericType The CSSNumericType defined in the spec is a simple dictionary which is only used for OM purposes. This NumericType class is used internally and matches the more abstract definition of a "type".
2025-08-15 12:55:58 +01:00
RemCalculationNode(NonnullRefPtr<CalculationNode const>, NonnullRefPtr<CalculationNode const>, Optional<NumericType>);
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<CalculationNode const> m_x;
NonnullRefPtr<CalculationNode const> m_y;
LibWeb: Implement CSS `rem()`
2023-05-27 19:08:07 +02:00
};
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
// https://drafts.csswg.org/css-values-4/#calc-simplification
LibWeb: Make storage of CSS::CalculationNodes const-correct Now we consistently use `RefPtr<CalculationNode const>` for all CalculationNodes.
2025-04-15 15:21:37 -06:00
NonnullRefPtr<CalculationNode const> simplify_a_calculation_tree(CalculationNode const& root, CalculationContext const& context, CalculationResolutionContext const& resolution_context);
LibWeb/CSS: Implement "simplify a calculation" algorithm This is not yet called anywhere.
2025-01-23 17:02:32 +00:00
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 17:34:14 +01:00
}
Reference in a new issue Copy permalink