2023-03-30 17:34:14 +01:00
|
|
|
|
/*
|
2024-10-04 13:19:50 +02:00
|
|
|
|
* Copyright (c) 2018-2020, Andreas Kling <andreas@ladybird.org>
|
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>
|
2023-03-30 17:34:14 +01:00
|
|
|
|
* Copyright (c) 2022-2023, MacDue <macdue@dueutil.tech>
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
|
|
|
*/
|
|
|
|
|
|
2024-12-11 15:05:56 +00:00
|
|
|
|
#include "CalculatedStyleValue.h"
|
2023-03-30 17:34:14 +01:00
|
|
|
|
#include <LibWeb/CSS/Percentage.h>
|
2023-07-05 19:58:13 +01:00
|
|
|
|
#include <LibWeb/CSS/PropertyID.h>
|
2023-03-30 17:34:14 +01:00
|
|
|
|
|
|
|
|
|
namespace Web::CSS {
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
static Optional<CSSNumericType> add_the_types(Vector<NonnullRefPtr<CalculationNode>> const& nodes)
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
Optional<CSSNumericType> left_type;
|
|
|
|
|
for (auto const& value : nodes) {
|
|
|
|
|
auto right_type = value->numeric_type();
|
|
|
|
|
if (!right_type.has_value())
|
|
|
|
|
return {};
|
2023-04-11 15:48:06 +01:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
if (left_type.has_value()) {
|
|
|
|
|
left_type = left_type->added_to(right_type.value());
|
|
|
|
|
} else {
|
|
|
|
|
left_type = right_type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!left_type.has_value())
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return left_type;
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
static Optional<CSSNumericType> add_the_types(CalculationNode const& a, CalculationNode const& b)
|
2023-05-27 23:50:33 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto a_type = a.numeric_type();
|
|
|
|
|
auto b_type = b.numeric_type();
|
|
|
|
|
if (!a_type.has_value() || !b_type.has_value())
|
|
|
|
|
return {};
|
|
|
|
|
return a_type->added_to(*b_type);
|
2023-07-07 22:48:11 -04:00
|
|
|
|
}
|
2023-05-27 23:50:33 +02:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
static Optional<CSSNumericType> add_the_types(CalculationNode const& a, CalculationNode const& b, CalculationNode const& c)
|
2023-05-26 11:21:49 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto a_type = a.numeric_type();
|
|
|
|
|
auto b_type = b.numeric_type();
|
|
|
|
|
auto c_type = c.numeric_type();
|
|
|
|
|
if (!a_type.has_value() || !b_type.has_value() || !c_type.has_value())
|
|
|
|
|
return {};
|
2024-10-16 15:00:25 +02:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto a_and_b_type = a_type->added_to(*b_type);
|
|
|
|
|
if (!a_and_b_type.has_value())
|
|
|
|
|
return {};
|
2024-10-16 15:00:25 +02:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return a_and_b_type->added_to(*c_type);
|
2023-07-07 22:48:11 -04:00
|
|
|
|
}
|
2023-05-26 11:21:49 +02:00
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
static Optional<CSSNumericType> multiply_the_types(Vector<NonnullRefPtr<CalculationNode>> const& nodes)
|
2023-07-05 19:58:13 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// At a * sub-expression, multiply the types of the left and right arguments.
|
|
|
|
|
// The sub-expression’s type is the returned result.
|
2023-07-05 19:58:13 +01:00
|
|
|
|
Optional<CSSNumericType> left_type;
|
|
|
|
|
for (auto const& value : nodes) {
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto right_type = value->numeric_type();
|
2023-07-05 19:58:13 +01:00
|
|
|
|
if (!right_type.has_value())
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
if (left_type.has_value()) {
|
2024-12-18 13:15:26 +00:00
|
|
|
|
left_type = left_type->multiplied_by(right_type.value());
|
2023-07-05 19:58:13 +01:00
|
|
|
|
} else {
|
|
|
|
|
left_type = right_type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!left_type.has_value())
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return left_type;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-08 16:55:06 +01:00
|
|
|
|
Optional<CalculationNode::ConstantType> CalculationNode::constant_type_from_string(StringView string)
|
|
|
|
|
{
|
|
|
|
|
if (string.equals_ignoring_ascii_case("e"sv))
|
|
|
|
|
return CalculationNode::ConstantType::E;
|
|
|
|
|
|
|
|
|
|
if (string.equals_ignoring_ascii_case("pi"sv))
|
|
|
|
|
return CalculationNode::ConstantType::Pi;
|
|
|
|
|
|
|
|
|
|
if (string.equals_ignoring_ascii_case("infinity"sv))
|
|
|
|
|
return CalculationNode::ConstantType::Infinity;
|
|
|
|
|
|
|
|
|
|
if (string.equals_ignoring_ascii_case("-infinity"sv))
|
|
|
|
|
return CalculationNode::ConstantType::MinusInfinity;
|
|
|
|
|
|
|
|
|
|
if (string.equals_ignoring_ascii_case("NaN"sv))
|
|
|
|
|
return CalculationNode::ConstantType::NaN;
|
|
|
|
|
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
CalculationNode::CalculationNode(Type type, Optional<CSSNumericType> numeric_type)
|
2023-04-11 15:48:06 +01:00
|
|
|
|
: m_type(type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
, m_numeric_type(move(numeric_type))
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CalculationNode::~CalculationNode() = default;
|
|
|
|
|
|
2025-01-08 16:14:17 +00:00
|
|
|
|
static CSSNumericType numeric_type_from_calculated_style_value(CalculatedStyleValue::CalculationResult::Value const& value, CalculationContext const& context)
|
2023-07-05 19:58:13 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// Anything else is a terminal value, whose type is determined based on its CSS type.
|
|
|
|
|
// (Unless otherwise specified, the type’s associated percent hint is null.)
|
2024-12-22 23:27:36 +10:00
|
|
|
|
return value.visit(
|
2023-07-05 19:58:13 +01:00
|
|
|
|
[](Number const&) {
|
|
|
|
|
// -> <number>
|
|
|
|
|
// -> <integer>
|
|
|
|
|
// the type is «[ ]» (empty map)
|
|
|
|
|
return CSSNumericType {};
|
|
|
|
|
},
|
|
|
|
|
[](Length const&) {
|
|
|
|
|
// -> <length>
|
|
|
|
|
// the type is «[ "length" → 1 ]»
|
|
|
|
|
return CSSNumericType { CSSNumericType::BaseType::Length, 1 };
|
|
|
|
|
},
|
|
|
|
|
[](Angle const&) {
|
|
|
|
|
// -> <angle>
|
|
|
|
|
// the type is «[ "angle" → 1 ]»
|
|
|
|
|
return CSSNumericType { CSSNumericType::BaseType::Angle, 1 };
|
|
|
|
|
},
|
|
|
|
|
[](Time const&) {
|
|
|
|
|
// -> <time>
|
|
|
|
|
// the type is «[ "time" → 1 ]»
|
|
|
|
|
return CSSNumericType { CSSNumericType::BaseType::Time, 1 };
|
|
|
|
|
},
|
|
|
|
|
[](Frequency const&) {
|
|
|
|
|
// -> <frequency>
|
|
|
|
|
// the type is «[ "frequency" → 1 ]»
|
|
|
|
|
return CSSNumericType { CSSNumericType::BaseType::Frequency, 1 };
|
|
|
|
|
},
|
2023-12-30 17:05:23 +00:00
|
|
|
|
[](Resolution const&) {
|
|
|
|
|
// -> <resolution>
|
|
|
|
|
// the type is «[ "resolution" → 1 ]»
|
|
|
|
|
return CSSNumericType { CSSNumericType::BaseType::Resolution, 1 };
|
|
|
|
|
},
|
2023-09-28 15:18:14 +01:00
|
|
|
|
[](Flex const&) {
|
|
|
|
|
// -> <flex>
|
|
|
|
|
// the type is «[ "flex" → 1 ]»
|
|
|
|
|
return CSSNumericType { CSSNumericType::BaseType::Flex, 1 };
|
|
|
|
|
},
|
2023-07-05 19:58:13 +01:00
|
|
|
|
// NOTE: <calc-constant> is a separate node type. (FIXME: Should it be?)
|
2025-01-08 16:14:17 +00:00
|
|
|
|
[&context](Percentage const&) {
|
2023-07-05 19:58:13 +01:00
|
|
|
|
// -> <percentage>
|
|
|
|
|
// If, in the context in which the math function containing this calculation is placed,
|
|
|
|
|
// <percentage>s are resolved relative to another type of value (such as in width,
|
|
|
|
|
// where <percentage> is resolved against a <length>), and that other type is not <number>,
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// the type is determined as the other type, but with a percent hint set to that other type.
|
2025-01-08 16:14:17 +00:00
|
|
|
|
if (context.percentages_resolve_as.has_value() && context.percentages_resolve_as != ValueType::Number && context.percentages_resolve_as != ValueType::Percentage) {
|
|
|
|
|
auto base_type = CSSNumericType::base_type_from_value_type(*context.percentages_resolve_as);
|
2023-07-05 19:58:13 +01:00
|
|
|
|
VERIFY(base_type.has_value());
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = CSSNumericType { base_type.value(), 1 };
|
|
|
|
|
result.set_percent_hint(base_type);
|
|
|
|
|
return result;
|
2023-07-05 19:58:13 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// Otherwise, the type is «[ "percent" → 1 ]», with a percent hint of "percent".
|
|
|
|
|
auto result = CSSNumericType { CSSNumericType::BaseType::Percent, 1 };
|
|
|
|
|
// FIXME: Setting the percent hint to "percent" causes us to fail tests.
|
|
|
|
|
// result.set_percent_hint(CSSNumericType::BaseType::Percent);
|
|
|
|
|
return result;
|
2023-07-05 19:58:13 +01:00
|
|
|
|
});
|
2024-12-22 23:27:36 +10:00
|
|
|
|
}
|
2024-12-18 13:15:26 +00:00
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<NumericCalculationNode> NumericCalculationNode::create(NumericValue value, CalculationContext const& context)
|
2024-12-22 23:27:36 +10:00
|
|
|
|
{
|
2025-01-08 16:14:17 +00:00
|
|
|
|
auto numeric_type = numeric_type_from_calculated_style_value(value, context);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) NumericCalculationNode(move(value), numeric_type));
|
2024-12-18 13:15:26 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NumericCalculationNode::NumericCalculationNode(NumericValue value, CSSNumericType numeric_type)
|
|
|
|
|
: CalculationNode(Type::Numeric, move(numeric_type))
|
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NumericCalculationNode::~NumericCalculationNode() = default;
|
|
|
|
|
|
|
|
|
|
String NumericCalculationNode::to_string() const
|
|
|
|
|
{
|
|
|
|
|
return m_value.visit([](auto& value) { return value.to_string(); });
|
2023-07-05 19:58:13 +01:00
|
|
|
|
}
|
|
|
|
|
|
2023-04-11 15:48:06 +01:00
|
|
|
|
bool NumericCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value.has<Percentage>();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult NumericCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2024-01-08 15:11:55 +01:00
|
|
|
|
{
|
|
|
|
|
if (m_value.has<Percentage>()) {
|
2024-01-11 06:49:07 +01:00
|
|
|
|
// NOTE: Depending on whether percentage_basis is set, the caller of resolve() is expecting a raw percentage or
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// resolved type.
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
return context.percentage_basis.visit(
|
2024-12-22 23:27:36 +10:00
|
|
|
|
[&](Empty const&) {
|
|
|
|
|
VERIFY(numeric_type_from_calculated_style_value(m_value, {}) == numeric_type());
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
return CalculatedStyleValue::CalculationResult::from_value(m_value, context, numeric_type());
|
2024-01-08 15:11:55 +01:00
|
|
|
|
},
|
|
|
|
|
[&](auto const& value) {
|
2024-12-22 23:27:36 +10:00
|
|
|
|
auto const calculated_value = value.percentage_of(m_value.get<Percentage>());
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
return CalculatedStyleValue::CalculationResult::from_value(calculated_value, context, numeric_type_from_calculated_style_value(calculated_value, {}));
|
2024-01-08 15:11:55 +01: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
|
|
|
|
return CalculatedStyleValue::CalculationResult::from_value(m_value, context, numeric_type());
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void NumericCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2023-08-22 14:13:22 +01:00
|
|
|
|
builder.appendff("{: >{}}NUMERIC({})\n", "", indent, m_value.visit([](auto& it) { return it.to_string(); }));
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool NumericCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value == static_cast<NumericCalculationNode const&>(other).m_value;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<SumCalculationNode> SumCalculationNode::create(Vector<NonnullRefPtr<CalculationNode>> values)
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// At a + or - sub-expression, attempt to add the types of the left and right arguments.
|
|
|
|
|
// If this returns failure, the entire calculation’s type is failure.
|
|
|
|
|
// Otherwise, the sub-expression’s type is the returned type.
|
|
|
|
|
auto numeric_type = add_the_types(values);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) SumCalculationNode(move(values), move(numeric_type)));
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
SumCalculationNode::SumCalculationNode(Vector<NonnullRefPtr<CalculationNode>> values, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Sum, move(numeric_type))
|
2023-04-11 15:48:06 +01:00
|
|
|
|
, m_values(move(values))
|
|
|
|
|
{
|
|
|
|
|
VERIFY(!m_values.is_empty());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SumCalculationNode::~SumCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String SumCalculationNode::to_string() const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
|
|
|
|
bool first = true;
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
for (auto& value : m_values) {
|
|
|
|
|
if (!first)
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(" + "sv);
|
|
|
|
|
builder.append(value->to_string());
|
2023-04-11 15:48:06 +01:00
|
|
|
|
first = false;
|
|
|
|
|
}
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool SumCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
for (auto const& value : m_values) {
|
|
|
|
|
if (value->contains_percentage())
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
CalculatedStyleValue::CalculationResult SumCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2024-12-11 15:05:56 +00:00
|
|
|
|
Optional<CalculatedStyleValue::CalculationResult> total;
|
2023-04-11 15:48:06 +01:00
|
|
|
|
|
|
|
|
|
for (auto& additional_product : m_values) {
|
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
|
|
|
|
auto additional_value = additional_product->resolve(context);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
if (!total.has_value()) {
|
|
|
|
|
total = additional_value;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
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
|
|
|
|
total->add(additional_value);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return total.value();
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void SumCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}SUM:\n", "", indent);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
for (auto const& item : m_values)
|
2023-08-22 14:13:22 +01:00
|
|
|
|
item->dump(builder, indent + 2);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool SumCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
2024-01-27 16:13:47 +01:00
|
|
|
|
if (m_values.size() != static_cast<SumCalculationNode const&>(other).m_values.size())
|
|
|
|
|
return false;
|
2024-01-09 12:41:43 +01:00
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (!m_values[i]->equals(*static_cast<SumCalculationNode const&>(other).m_values[i]))
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<ProductCalculationNode> ProductCalculationNode::create(Vector<NonnullRefPtr<CalculationNode>> values)
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// At a * sub-expression, multiply the types of the left and right arguments.
|
|
|
|
|
// The sub-expression’s type is the returned result.
|
|
|
|
|
auto numeric_type = multiply_the_types(values);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) ProductCalculationNode(move(values), move(numeric_type)));
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
ProductCalculationNode::ProductCalculationNode(Vector<NonnullRefPtr<CalculationNode>> values, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Product, move(numeric_type))
|
2023-04-11 15:48:06 +01:00
|
|
|
|
, m_values(move(values))
|
|
|
|
|
{
|
|
|
|
|
VERIFY(!m_values.is_empty());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ProductCalculationNode::~ProductCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String ProductCalculationNode::to_string() const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
|
|
|
|
bool first = true;
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
for (auto& value : m_values) {
|
|
|
|
|
if (!first)
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(" * "sv);
|
|
|
|
|
builder.append(value->to_string());
|
2023-04-11 15:48:06 +01:00
|
|
|
|
first = false;
|
|
|
|
|
}
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ProductCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
for (auto const& value : m_values) {
|
|
|
|
|
if (value->contains_percentage())
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
CalculatedStyleValue::CalculationResult ProductCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2024-12-11 15:05:56 +00:00
|
|
|
|
Optional<CalculatedStyleValue::CalculationResult> total;
|
2023-04-11 15:48:06 +01:00
|
|
|
|
|
|
|
|
|
for (auto& additional_product : m_values) {
|
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
|
|
|
|
auto additional_value = additional_product->resolve(context);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
if (!total.has_value()) {
|
|
|
|
|
total = additional_value;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
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
|
|
|
|
total->multiply_by(additional_value);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return total.value();
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void ProductCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}PRODUCT:\n", "", indent);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
for (auto const& item : m_values)
|
2023-08-22 14:13:22 +01:00
|
|
|
|
item->dump(builder, indent + 2);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool ProductCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
2024-01-27 16:13:47 +01:00
|
|
|
|
if (m_values.size() != static_cast<ProductCalculationNode const&>(other).m_values.size())
|
|
|
|
|
return false;
|
2024-01-09 12:41:43 +01:00
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (!m_values[i]->equals(*static_cast<ProductCalculationNode const&>(other).m_values[i]))
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<NegateCalculationNode> NegateCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) NegateCalculationNode(move(value)));
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NegateCalculationNode::NegateCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// NOTE: `- foo` doesn't change the type
|
|
|
|
|
: CalculationNode(Type::Negate, value->numeric_type())
|
2023-04-11 15:48:06 +01:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NegateCalculationNode::~NegateCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String NegateCalculationNode::to_string() const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(String::formatted("(0 - {})", m_value->to_string()));
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool NegateCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult NegateCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-04-11 15:48:06 +01: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
|
|
|
|
auto child_value = m_value->resolve(context);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
child_value.negate();
|
|
|
|
|
return child_value;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void NegateCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}NEGATE:\n", "", indent);
|
2023-08-22 14:13:22 +01:00
|
|
|
|
m_value->dump(builder, indent + 2);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool NegateCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<NegateCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<InvertCalculationNode> InvertCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// At a / sub-expression, let left type be the result of finding the types of its left argument,
|
|
|
|
|
// and right type be the result of finding the types of its right argument and then inverting it.
|
|
|
|
|
// The sub-expression’s type is the result of multiplying the left type and right type.
|
|
|
|
|
// NOTE: An InvertCalculationNode only represents the right argument here, and the multiplication
|
|
|
|
|
// is handled in the parent ProductCalculationNode.
|
|
|
|
|
auto numeric_type = value->numeric_type().map([](auto& it) { return it.inverted(); });
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) InvertCalculationNode(move(value), move(numeric_type)));
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
InvertCalculationNode::InvertCalculationNode(NonnullRefPtr<CalculationNode> value, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Invert, move(numeric_type))
|
2023-04-11 15:48:06 +01:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
InvertCalculationNode::~InvertCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String InvertCalculationNode::to_string() const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(String::formatted("(1 / {})", m_value->to_string()));
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool InvertCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult InvertCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-04-11 15:48:06 +01: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
|
|
|
|
auto child_value = m_value->resolve(context);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
child_value.invert();
|
|
|
|
|
return child_value;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void InvertCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-04-11 15:48:06 +01:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}INVERT:\n", "", indent);
|
2023-08-22 14:13:22 +01:00
|
|
|
|
m_value->dump(builder, indent + 2);
|
2023-04-11 15:48:06 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool InvertCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<InvertCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<MinCalculationNode> MinCalculationNode::create(Vector<NonnullRefPtr<CalculationNode>> values)
|
2023-05-26 11:21:49 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The result of adding the types of its comma-separated calculations.
|
|
|
|
|
auto numeric_type = add_the_types(values);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) MinCalculationNode(move(values), move(numeric_type)));
|
2023-05-26 11:21:49 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
MinCalculationNode::MinCalculationNode(Vector<NonnullRefPtr<CalculationNode>> values, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Min, move(numeric_type))
|
2023-05-26 11:21:49 +02:00
|
|
|
|
, m_values(move(values))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MinCalculationNode::~MinCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String MinCalculationNode::to_string() const
|
2023-05-26 11:21:49 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append("min("sv);
|
2023-05-26 11:21:49 +02:00
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (i != 0)
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(", "sv);
|
|
|
|
|
builder.append(m_values[i]->to_string());
|
2023-05-26 11:21:49 +02:00
|
|
|
|
}
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(")"sv);
|
|
|
|
|
return MUST(builder.to_string());
|
2023-05-26 11:21:49 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool MinCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
for (auto const& value : m_values) {
|
|
|
|
|
if (value->contains_percentage())
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
CalculatedStyleValue::CalculationResult MinCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-26 11:21:49 +02: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
|
|
|
|
CalculatedStyleValue::CalculationResult smallest_node = m_values.first()->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto smallest_value = smallest_node.value();
|
2023-05-26 11:21:49 +02:00
|
|
|
|
|
|
|
|
|
for (size_t i = 1; i < m_values.size(); i++) {
|
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
|
|
|
|
auto child_resolved = m_values[i]->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto child_value = child_resolved.value();
|
2023-05-26 11:21:49 +02:00
|
|
|
|
|
|
|
|
|
if (child_value < smallest_value) {
|
|
|
|
|
smallest_value = child_value;
|
|
|
|
|
smallest_node = child_resolved;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return smallest_node;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void MinCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-26 11:21:49 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}MIN:\n", "", indent);
|
2023-05-26 11:21:49 +02:00
|
|
|
|
for (auto const& value : m_values)
|
2023-08-22 14:13:22 +01:00
|
|
|
|
value->dump(builder, indent + 2);
|
2023-05-26 11:21:49 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool MinCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
2024-01-27 16:13:47 +01:00
|
|
|
|
if (m_values.size() != static_cast<MinCalculationNode const&>(other).m_values.size())
|
|
|
|
|
return false;
|
2024-01-09 12:41:43 +01:00
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (!m_values[i]->equals(*static_cast<MinCalculationNode const&>(other).m_values[i]))
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<MaxCalculationNode> MaxCalculationNode::create(Vector<NonnullRefPtr<CalculationNode>> values)
|
2023-05-26 15:00:22 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The result of adding the types of its comma-separated calculations.
|
|
|
|
|
auto numeric_type = add_the_types(values);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) MaxCalculationNode(move(values), move(numeric_type)));
|
2023-05-26 15:00:22 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
MaxCalculationNode::MaxCalculationNode(Vector<NonnullRefPtr<CalculationNode>> values, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Max, move(numeric_type))
|
2023-05-26 15:00:22 +02:00
|
|
|
|
, m_values(move(values))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MaxCalculationNode::~MaxCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String MaxCalculationNode::to_string() const
|
2023-05-26 15:00:22 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append("max("sv);
|
2023-05-26 15:00:22 +02:00
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (i != 0)
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(", "sv);
|
|
|
|
|
builder.append(m_values[i]->to_string());
|
2023-05-26 15:00:22 +02:00
|
|
|
|
}
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(")"sv);
|
|
|
|
|
return MUST(builder.to_string());
|
2023-05-26 15:00:22 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool MaxCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
for (auto const& value : m_values) {
|
|
|
|
|
if (value->contains_percentage())
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
CalculatedStyleValue::CalculationResult MaxCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-26 15:00:22 +02: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
|
|
|
|
CalculatedStyleValue::CalculationResult largest_node = m_values.first()->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto largest_value = largest_node.value();
|
2023-05-26 15:00:22 +02:00
|
|
|
|
|
|
|
|
|
for (size_t i = 1; i < m_values.size(); i++) {
|
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
|
|
|
|
auto child_resolved = m_values[i]->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto child_value = child_resolved.value();
|
2023-05-26 15:00:22 +02:00
|
|
|
|
|
|
|
|
|
if (child_value > largest_value) {
|
|
|
|
|
largest_value = child_value;
|
|
|
|
|
largest_node = child_resolved;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return largest_node;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void MaxCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-26 15:00:22 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}MAX:\n", "", indent);
|
2023-05-26 15:00:22 +02:00
|
|
|
|
for (auto const& value : m_values)
|
2023-08-22 14:13:22 +01:00
|
|
|
|
value->dump(builder, indent + 2);
|
2023-05-26 15:00:22 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool MaxCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
2024-01-27 16:13:47 +01:00
|
|
|
|
if (m_values.size() != static_cast<MaxCalculationNode const&>(other).m_values.size())
|
|
|
|
|
return false;
|
2024-01-09 12:41:43 +01:00
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (!m_values[i]->equals(*static_cast<MaxCalculationNode const&>(other).m_values[i]))
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<ClampCalculationNode> ClampCalculationNode::create(NonnullRefPtr<CalculationNode> min, NonnullRefPtr<CalculationNode> center, NonnullRefPtr<CalculationNode> max)
|
2023-05-26 15:40:39 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The result of adding the types of its comma-separated calculations.
|
|
|
|
|
auto numeric_type = add_the_types(*min, *center, *max);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) ClampCalculationNode(move(min), move(center), move(max), move(numeric_type)));
|
2023-05-26 15:40:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
ClampCalculationNode::ClampCalculationNode(NonnullRefPtr<CalculationNode> min, NonnullRefPtr<CalculationNode> center, NonnullRefPtr<CalculationNode> max, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Clamp, move(numeric_type))
|
2023-05-26 15:40:39 +02:00
|
|
|
|
, m_min_value(move(min))
|
|
|
|
|
, m_center_value(move(center))
|
|
|
|
|
, m_max_value(move(max))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ClampCalculationNode::~ClampCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String ClampCalculationNode::to_string() const
|
2023-05-26 15:40:39 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append("clamp("sv);
|
|
|
|
|
builder.append(m_min_value->to_string());
|
|
|
|
|
builder.append(", "sv);
|
|
|
|
|
builder.append(m_center_value->to_string());
|
|
|
|
|
builder.append(", "sv);
|
|
|
|
|
builder.append(m_max_value->to_string());
|
|
|
|
|
builder.append(")"sv);
|
|
|
|
|
return MUST(builder.to_string());
|
2023-05-26 15:40:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ClampCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_min_value->contains_percentage() || m_center_value->contains_percentage() || m_max_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult ClampCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-26 15:40:39 +02: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
|
|
|
|
auto min_node = m_min_value->resolve(context);
|
|
|
|
|
auto center_node = m_center_value->resolve(context);
|
|
|
|
|
auto max_node = m_max_value->resolve(context);
|
2023-05-26 15:40:39 +02:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto min_value = min_node.value();
|
|
|
|
|
auto center_value = center_node.value();
|
|
|
|
|
auto max_value = max_node.value();
|
2023-05-26 15:40:39 +02:00
|
|
|
|
|
|
|
|
|
// NOTE: The value should be returned as "max(MIN, min(VAL, MAX))"
|
|
|
|
|
auto chosen_value = max(min_value, min(center_value, max_value));
|
|
|
|
|
if (chosen_value == min_value)
|
|
|
|
|
return min_node;
|
|
|
|
|
if (chosen_value == center_value)
|
|
|
|
|
return center_node;
|
|
|
|
|
if (chosen_value == max_value)
|
|
|
|
|
return max_node;
|
|
|
|
|
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void ClampCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-26 15:40:39 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}CLAMP:\n", "", indent);
|
2023-08-22 14:13:22 +01:00
|
|
|
|
m_min_value->dump(builder, indent + 2);
|
|
|
|
|
m_center_value->dump(builder, indent + 2);
|
|
|
|
|
m_max_value->dump(builder, indent + 2);
|
2023-05-26 15:40:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool ClampCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_min_value->equals(*static_cast<ClampCalculationNode const&>(other).m_min_value)
|
|
|
|
|
&& m_center_value->equals(*static_cast<ClampCalculationNode const&>(other).m_center_value)
|
|
|
|
|
&& m_max_value->equals(*static_cast<ClampCalculationNode const&>(other).m_max_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<AbsCalculationNode> AbsCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-27 22:56:41 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) AbsCalculationNode(move(value)));
|
2023-05-27 22:56:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
AbsCalculationNode::AbsCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The type of its contained calculation.
|
|
|
|
|
: CalculationNode(Type::Abs, value->numeric_type())
|
2023-05-27 22:56:41 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AbsCalculationNode::~AbsCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String AbsCalculationNode::to_string() const
|
2023-05-27 22:56:41 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("abs("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-27 22:56:41 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-27 22:56:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool AbsCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult AbsCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-27 22:56:41 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
if (node_a.value() < 0)
|
|
|
|
|
node_a.negate();
|
2023-05-27 22:56:41 +02:00
|
|
|
|
return node_a;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void AbsCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-27 22:56:41 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}ABS: {}\n", "", indent, to_string());
|
2023-05-27 22:56:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool AbsCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<AbsCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<SignCalculationNode> SignCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-27 23:02:39 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) SignCalculationNode(move(value)));
|
2023-05-27 23:02:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
SignCalculationNode::SignCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Sign, CSSNumericType {})
|
2023-05-27 23:02:39 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SignCalculationNode::~SignCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String SignCalculationNode::to_string() const
|
2023-05-27 23:02:39 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("sign("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-27 23:02:39 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-27 23:02:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool SignCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult SignCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-27 23:02:39 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto node_a_value = node_a.value();
|
2023-05-27 23:02:39 +02:00
|
|
|
|
|
|
|
|
|
if (node_a_value < 0)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { -1, CSSNumericType {} };
|
2023-05-27 23:02:39 +02:00
|
|
|
|
|
|
|
|
|
if (node_a_value > 0)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { 1, CSSNumericType {} };
|
2023-05-27 23:02:39 +02:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { 0, CSSNumericType {} };
|
2023-05-27 23:02:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void SignCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-27 23:02:39 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}SIGN: {}\n", "", indent, to_string());
|
2023-05-27 23:02:39 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool SignCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<SignCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<ConstantCalculationNode> ConstantCalculationNode::create(ConstantType constant)
|
2023-05-26 21:24:31 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) ConstantCalculationNode(constant));
|
2023-05-26 21:24:31 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ConstantCalculationNode::ConstantCalculationNode(ConstantType constant)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// Anything else is a terminal value, whose type is determined based on its CSS type:
|
|
|
|
|
// -> <calc-constant>
|
|
|
|
|
// the type is «[ ]» (empty map)
|
|
|
|
|
: CalculationNode(Type::Constant, CSSNumericType {})
|
2023-05-26 21:24:31 +02:00
|
|
|
|
, m_constant(constant)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ConstantCalculationNode::~ConstantCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String ConstantCalculationNode::to_string() const
|
2023-05-26 21:24:31 +02:00
|
|
|
|
{
|
|
|
|
|
switch (m_constant) {
|
|
|
|
|
case CalculationNode::ConstantType::E:
|
2023-08-07 22:26:17 -04:00
|
|
|
|
return "e"_string;
|
2023-07-08 16:55:06 +01:00
|
|
|
|
case CalculationNode::ConstantType::Pi:
|
2023-08-07 22:26:17 -04:00
|
|
|
|
return "pi"_string;
|
2023-05-26 21:24:31 +02:00
|
|
|
|
case CalculationNode::ConstantType::Infinity:
|
|
|
|
|
return "infinity"_string;
|
|
|
|
|
case CalculationNode::ConstantType::MinusInfinity:
|
|
|
|
|
return "-infinity"_string;
|
|
|
|
|
case CalculationNode::ConstantType::NaN:
|
|
|
|
|
return "NaN"_string;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
2023-07-05 19:58:13 +01: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
|
|
|
|
CalculatedStyleValue::CalculationResult ConstantCalculationNode::resolve(CalculationResolutionContext const&) const
|
2023-05-26 21:24:31 +02:00
|
|
|
|
{
|
|
|
|
|
switch (m_constant) {
|
2024-12-18 13:15:26 +00:00
|
|
|
|
case ConstantType::E:
|
|
|
|
|
return { AK::E<double>, CSSNumericType {} };
|
|
|
|
|
case ConstantType::Pi:
|
|
|
|
|
return { AK::Pi<double>, CSSNumericType {} };
|
2023-05-26 21:24:31 +02:00
|
|
|
|
// FIXME: We need to keep track of Infinity and NaN across all nodes, since they require special handling.
|
2024-12-18 13:15:26 +00:00
|
|
|
|
case ConstantType::Infinity:
|
|
|
|
|
return { NumericLimits<double>::max(), CSSNumericType {} };
|
|
|
|
|
case ConstantType::MinusInfinity:
|
|
|
|
|
return { NumericLimits<double>::lowest(), CSSNumericType {} };
|
|
|
|
|
case ConstantType::NaN:
|
|
|
|
|
return { AK::NaN<double>, CSSNumericType {} };
|
2023-05-26 21:24:31 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void ConstantCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-26 21:24:31 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}CONSTANT: {}\n", "", indent, to_string());
|
2023-05-26 21:24:31 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool ConstantCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_constant == static_cast<ConstantCalculationNode const&>(other).m_constant;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<SinCalculationNode> SinCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-27 23:50:33 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) SinCalculationNode(move(value)));
|
2023-05-27 23:50:33 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
SinCalculationNode::SinCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Sin, CSSNumericType {})
|
2023-05-27 23:50:33 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SinCalculationNode::~SinCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String SinCalculationNode::to_string() const
|
2023-05-27 23:50:33 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("sin("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-27 23:50:33 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-27 23:50:33 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool SinCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult SinCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-27 23:50:33 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto node_a_value = AK::to_radians(node_a.value());
|
2023-05-27 23:50:33 +02:00
|
|
|
|
auto result = sin(node_a_value);
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { result, CSSNumericType {} };
|
2023-05-27 23:50:33 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void SinCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-27 23:50:33 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}SIN: {}\n", "", indent, to_string());
|
2023-05-27 23:50:33 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool SinCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<SinCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<CosCalculationNode> CosCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-27 23:57:01 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) CosCalculationNode(move(value)));
|
2023-05-27 23:57:01 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
CosCalculationNode::CosCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Cos, CSSNumericType {})
|
2023-05-27 23:57:01 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CosCalculationNode::~CosCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String CosCalculationNode::to_string() const
|
2023-05-27 23:57:01 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("cos("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-27 23:57:01 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-27 23:57:01 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool CosCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult CosCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-27 23:57:01 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto node_a_value = AK::to_radians(node_a.value());
|
2023-05-27 23:57:01 +02:00
|
|
|
|
auto result = cos(node_a_value);
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { result, CSSNumericType {} };
|
2023-05-27 23:57:01 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void CosCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-27 23:57:01 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}COS: {}\n", "", indent, to_string());
|
2023-05-27 23:57:01 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool CosCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<CosCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<TanCalculationNode> TanCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-28 00:02:43 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) TanCalculationNode(move(value)));
|
2023-05-28 00:02:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
TanCalculationNode::TanCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Tan, CSSNumericType {})
|
2023-05-28 00:02:43 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TanCalculationNode::~TanCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String TanCalculationNode::to_string() const
|
2023-05-28 00:02:43 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("tan("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-28 00:02:43 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 00:02:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool TanCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult TanCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 00:02:43 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto node_a_value = AK::to_radians(node_a.value());
|
2023-05-28 00:02:43 +02:00
|
|
|
|
auto result = tan(node_a_value);
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { result, CSSNumericType {} };
|
2023-05-28 00:02:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void TanCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 00:02:43 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}TAN: {}\n", "", indent, to_string());
|
2023-05-28 00:02:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool TanCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<TanCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<AsinCalculationNode> AsinCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-28 10:55:52 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) AsinCalculationNode(move(value)));
|
2023-05-28 10:55:52 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
AsinCalculationNode::AsinCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ "angle" → 1 ]».
|
|
|
|
|
: CalculationNode(Type::Asin, CSSNumericType { CSSNumericType::BaseType::Angle, 1 })
|
2023-05-28 10:55:52 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AsinCalculationNode::~AsinCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String AsinCalculationNode::to_string() const
|
2023-05-28 10:55:52 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("asin("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-28 10:55:52 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 10:55:52 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool AsinCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult AsinCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 10:55:52 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = AK::to_degrees(asin(node_a.value()));
|
|
|
|
|
return { result, CSSNumericType { CSSNumericType::BaseType::Angle, 1 } };
|
2023-05-28 10:55:52 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void AsinCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 10:55:52 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}ASIN: {}\n", "", indent, to_string());
|
2023-05-28 10:55:52 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool AsinCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<AsinCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<AcosCalculationNode> AcosCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-28 11:00:35 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) AcosCalculationNode(move(value)));
|
2023-05-28 11:00:35 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
AcosCalculationNode::AcosCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ "angle" → 1 ]».
|
|
|
|
|
: CalculationNode(Type::Acos, CSSNumericType { CSSNumericType::BaseType::Angle, 1 })
|
2023-05-28 11:00:35 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AcosCalculationNode::~AcosCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String AcosCalculationNode::to_string() const
|
2023-05-28 11:00:35 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("acos("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-28 11:00:35 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:00:35 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool AcosCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult AcosCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:00:35 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = AK::to_degrees(acos(node_a.value()));
|
|
|
|
|
return { result, CSSNumericType { CSSNumericType::BaseType::Angle, 1 } };
|
2023-05-28 11:00:35 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void AcosCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:00:35 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}ACOS: {}\n", "", indent, to_string());
|
2023-05-28 11:00:35 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool AcosCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<AcosCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<AtanCalculationNode> AtanCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-28 11:04:57 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) AtanCalculationNode(move(value)));
|
2023-05-28 11:04:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
AtanCalculationNode::AtanCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ "angle" → 1 ]».
|
|
|
|
|
: CalculationNode(Type::Atan, CSSNumericType { CSSNumericType::BaseType::Angle, 1 })
|
2023-05-28 11:04:57 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AtanCalculationNode::~AtanCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String AtanCalculationNode::to_string() const
|
2023-05-28 11:04:57 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("atan("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-28 11:04:57 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:04:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool AtanCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_value->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult AtanCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:04:57 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = AK::to_degrees(atan(node_a.value()));
|
|
|
|
|
return { result, CSSNumericType { CSSNumericType::BaseType::Angle, 1 } };
|
2023-05-28 11:04:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void AtanCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:04:57 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}ATAN: {}\n", "", indent, to_string());
|
2023-05-28 11:04:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool AtanCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<AtanCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<Atan2CalculationNode> Atan2CalculationNode::create(NonnullRefPtr<CalculationNode> y, NonnullRefPtr<CalculationNode> x)
|
2023-05-28 11:19:10 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) Atan2CalculationNode(move(y), move(x)));
|
2023-05-28 11:19:10 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
Atan2CalculationNode::Atan2CalculationNode(NonnullRefPtr<CalculationNode> y, NonnullRefPtr<CalculationNode> x)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ "angle" → 1 ]».
|
|
|
|
|
: CalculationNode(Type::Atan2, CSSNumericType { CSSNumericType::BaseType::Angle, 1 })
|
2023-05-28 11:19:10 +02:00
|
|
|
|
, m_y(move(y))
|
|
|
|
|
, m_x(move(x))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Atan2CalculationNode::~Atan2CalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String Atan2CalculationNode::to_string() const
|
2023-05-28 11:19:10 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("atan2("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_y->to_string());
|
2023-05-28 11:19:10 +02:00
|
|
|
|
builder.append(", "sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_x->to_string());
|
2023-05-28 11:19:10 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:19:10 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool Atan2CalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_y->contains_percentage() || m_x->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult Atan2CalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:19:10 +02: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
|
|
|
|
auto node_a = m_y->resolve(context);
|
|
|
|
|
auto node_b = m_x->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = AK::to_degrees(atan2(node_a.value(), node_b.value()));
|
|
|
|
|
return { result, CSSNumericType { CSSNumericType::BaseType::Angle, 1 } };
|
2023-05-28 11:19:10 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void Atan2CalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:19:10 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}ATAN2: {}\n", "", indent, to_string());
|
2023-05-28 11:19:10 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool Atan2CalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_x->equals(*static_cast<Atan2CalculationNode const&>(other).m_x)
|
|
|
|
|
&& m_y->equals(*static_cast<Atan2CalculationNode const&>(other).m_y);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<PowCalculationNode> PowCalculationNode::create(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y)
|
2023-05-28 11:26:42 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) PowCalculationNode(move(x), move(y)));
|
2023-05-28 11:26:42 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
PowCalculationNode::PowCalculationNode(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Pow, CSSNumericType {})
|
2023-05-28 11:26:42 +02:00
|
|
|
|
, m_x(move(x))
|
|
|
|
|
, m_y(move(y))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PowCalculationNode::~PowCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String PowCalculationNode::to_string() const
|
2023-05-28 11:26:42 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("pow("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_x->to_string());
|
2023-05-28 11:26:42 +02:00
|
|
|
|
builder.append(", "sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_y->to_string());
|
2023-05-28 11:26:42 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:26:42 +02: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
|
|
|
|
CalculatedStyleValue::CalculationResult PowCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:26:42 +02: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
|
|
|
|
auto node_a = m_x->resolve(context);
|
|
|
|
|
auto node_b = m_y->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = pow(node_a.value(), node_b.value());
|
|
|
|
|
return { result, CSSNumericType {} };
|
2023-05-28 11:26:42 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void PowCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:26:42 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}POW: {}\n", "", indent, to_string());
|
2023-05-28 11:26:42 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool PowCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_x->equals(*static_cast<PowCalculationNode const&>(other).m_x)
|
|
|
|
|
&& m_y->equals(*static_cast<PowCalculationNode const&>(other).m_y);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<SqrtCalculationNode> SqrtCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-28 11:31:50 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) SqrtCalculationNode(move(value)));
|
2023-05-28 11:31:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
SqrtCalculationNode::SqrtCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Sqrt, CSSNumericType {})
|
2023-05-28 11:31:50 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SqrtCalculationNode::~SqrtCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String SqrtCalculationNode::to_string() const
|
2023-05-28 11:31:50 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("sqrt("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-28 11:31:50 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:31:50 +02: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
|
|
|
|
CalculatedStyleValue::CalculationResult SqrtCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:31:50 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = sqrt(node_a.value());
|
|
|
|
|
return { result, CSSNumericType {} };
|
2023-05-28 11:31:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void SqrtCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:31:50 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}SQRT: {}\n", "", indent, to_string());
|
2023-05-28 11:31:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool SqrtCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<SqrtCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<HypotCalculationNode> HypotCalculationNode::create(Vector<NonnullRefPtr<CalculationNode>> values)
|
2023-05-28 11:43:04 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The result of adding the types of its comma-separated calculations.
|
|
|
|
|
auto numeric_type = add_the_types(values);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) HypotCalculationNode(move(values), move(numeric_type)));
|
2023-05-28 11:43:04 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
HypotCalculationNode::HypotCalculationNode(Vector<NonnullRefPtr<CalculationNode>> values, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Hypot, move(numeric_type))
|
2023-05-28 11:43:04 +02:00
|
|
|
|
, m_values(move(values))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
HypotCalculationNode::~HypotCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String HypotCalculationNode::to_string() const
|
2023-05-28 11:43:04 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append("hypot("sv);
|
2023-05-28 11:43:04 +02:00
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (i != 0)
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(", "sv);
|
|
|
|
|
builder.append(m_values[i]->to_string());
|
2023-05-28 11:43:04 +02:00
|
|
|
|
}
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(")"sv);
|
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:43:04 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool HypotCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
for (auto const& value : m_values) {
|
|
|
|
|
if (value->contains_percentage())
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
CalculatedStyleValue::CalculationResult HypotCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:43:04 +02:00
|
|
|
|
{
|
|
|
|
|
double square_sum = 0.0;
|
2024-12-18 13:15:26 +00:00
|
|
|
|
Optional<CSSNumericType> result_type;
|
2023-05-28 11:43:04 +02:00
|
|
|
|
|
|
|
|
|
for (auto const& value : m_values) {
|
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
|
|
|
|
auto child_resolved = value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto child_value = child_resolved.value();
|
2023-05-28 11:43:04 +02:00
|
|
|
|
|
|
|
|
|
square_sum += child_value * child_value;
|
2024-12-18 13:15:26 +00:00
|
|
|
|
if (result_type.has_value()) {
|
|
|
|
|
result_type = result_type->consistent_type(*child_resolved.type());
|
|
|
|
|
} else {
|
|
|
|
|
result_type = child_resolved.type();
|
|
|
|
|
}
|
2023-05-28 11:43:04 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
auto result = sqrt(square_sum);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { result, result_type };
|
2023-05-28 11:43:04 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void HypotCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:43:04 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}HYPOT:\n", "", indent);
|
2023-05-28 11:43:04 +02:00
|
|
|
|
for (auto const& value : m_values)
|
2023-08-22 14:13:22 +01:00
|
|
|
|
value->dump(builder, indent + 2);
|
2023-05-28 11:43:04 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool HypotCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
for (size_t i = 0; i < m_values.size(); ++i) {
|
|
|
|
|
if (!m_values[i]->equals(*static_cast<HypotCalculationNode const&>(other).m_values[i]))
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<LogCalculationNode> LogCalculationNode::create(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y)
|
2023-05-28 11:53:57 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) LogCalculationNode(move(x), move(y)));
|
2023-05-28 11:53:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
LogCalculationNode::LogCalculationNode(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Log, CSSNumericType {})
|
2023-05-28 11:53:57 +02:00
|
|
|
|
, m_x(move(x))
|
|
|
|
|
, m_y(move(y))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LogCalculationNode::~LogCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String LogCalculationNode::to_string() const
|
2023-05-28 11:53:57 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("log("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_x->to_string());
|
2023-05-28 11:53:57 +02:00
|
|
|
|
builder.append(", "sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_y->to_string());
|
2023-05-28 11:53:57 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:53:57 +02: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
|
|
|
|
CalculatedStyleValue::CalculationResult LogCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:53:57 +02: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
|
|
|
|
auto node_a = m_x->resolve(context);
|
|
|
|
|
auto node_b = m_y->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = log2(node_a.value()) / log2(node_b.value());
|
|
|
|
|
return { result, CSSNumericType {} };
|
2023-05-28 11:53:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void LogCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:53:57 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}LOG: {}\n", "", indent, to_string());
|
2023-05-28 11:53:57 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool LogCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_x->equals(*static_cast<LogCalculationNode const&>(other).m_x)
|
|
|
|
|
&& m_y->equals(*static_cast<LogCalculationNode const&>(other).m_y);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<ExpCalculationNode> ExpCalculationNode::create(NonnullRefPtr<CalculationNode> value)
|
2023-05-28 11:58:30 +02:00
|
|
|
|
{
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) ExpCalculationNode(move(value)));
|
2023-05-28 11:58:30 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
ExpCalculationNode::ExpCalculationNode(NonnullRefPtr<CalculationNode> value)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// «[ ]» (empty map).
|
|
|
|
|
: CalculationNode(Type::Exp, CSSNumericType {})
|
2023-05-28 11:58:30 +02:00
|
|
|
|
, m_value(move(value))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ExpCalculationNode::~ExpCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String ExpCalculationNode::to_string() const
|
2023-05-28 11:58:30 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("exp("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_value->to_string());
|
2023-05-28 11:58:30 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-28 11:58:30 +02: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
|
|
|
|
CalculatedStyleValue::CalculationResult ExpCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-28 11:58:30 +02: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
|
|
|
|
auto node_a = m_value->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto result = exp(node_a.value());
|
|
|
|
|
return { result, CSSNumericType {} };
|
2023-05-28 11:58:30 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void ExpCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-28 11:58:30 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}EXP: {}\n", "", indent, to_string());
|
2023-05-28 11:58:30 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool ExpCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_value->equals(*static_cast<ExpCalculationNode const&>(other).m_value);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<RoundCalculationNode> RoundCalculationNode::create(RoundingStrategy strategy, NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y)
|
2023-05-27 16:07:50 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The result of adding the types of its comma-separated calculations.
|
|
|
|
|
auto numeric_type = add_the_types(*x, *y);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) RoundCalculationNode(strategy, move(x), move(y), move(numeric_type)));
|
2023-05-27 16:07:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
RoundCalculationNode::RoundCalculationNode(RoundingStrategy mode, NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Round, move(numeric_type))
|
2023-07-13 14:51:11 +01:00
|
|
|
|
, m_strategy(mode)
|
2023-05-27 16:07:50 +02:00
|
|
|
|
, m_x(move(x))
|
|
|
|
|
, m_y(move(y))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
RoundCalculationNode::~RoundCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String RoundCalculationNode::to_string() const
|
2023-05-27 16:07:50 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("round("sv);
|
2023-07-13 14:51:11 +01:00
|
|
|
|
builder.append(CSS::to_string(m_strategy));
|
2023-05-27 16:07:50 +02:00
|
|
|
|
builder.append(", "sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_x->to_string());
|
2023-05-27 16:07:50 +02:00
|
|
|
|
builder.append(", "sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_y->to_string());
|
2023-05-27 16:07:50 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-27 16:07:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool RoundCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_x->contains_percentage() || m_y->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult RoundCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-27 16:07:50 +02: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
|
|
|
|
auto node_a = m_x->resolve(context);
|
|
|
|
|
auto node_b = m_y->resolve(context);
|
2023-05-27 16:07:50 +02:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto node_a_value = node_a.value();
|
|
|
|
|
auto node_b_value = node_b.value();
|
2023-05-27 16:07:50 +02:00
|
|
|
|
|
|
|
|
|
auto upper_b = ceil(node_a_value / node_b_value) * node_b_value;
|
|
|
|
|
auto lower_b = floor(node_a_value / node_b_value) * node_b_value;
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto resolved_type = node_a.type()->consistent_type(*node_b.type());
|
2024-09-17 17:51:48 +02:00
|
|
|
|
|
2023-07-13 14:51:11 +01:00
|
|
|
|
if (m_strategy == RoundingStrategy::Nearest) {
|
2023-05-27 16:07:50 +02:00
|
|
|
|
auto upper_diff = fabs(upper_b - node_a_value);
|
|
|
|
|
auto lower_diff = fabs(node_a_value - lower_b);
|
|
|
|
|
auto rounded_value = upper_diff < lower_diff ? upper_b : lower_b;
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { rounded_value, resolved_type };
|
2023-05-27 16:07:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 14:51:11 +01:00
|
|
|
|
if (m_strategy == RoundingStrategy::Up) {
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { upper_b, resolved_type };
|
2023-05-27 16:07:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 14:51:11 +01:00
|
|
|
|
if (m_strategy == RoundingStrategy::Down) {
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { lower_b, resolved_type };
|
2023-05-27 16:07:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 14:51:11 +01:00
|
|
|
|
if (m_strategy == RoundingStrategy::ToZero) {
|
2023-05-27 16:07:50 +02:00
|
|
|
|
auto upper_diff = fabs(upper_b);
|
|
|
|
|
auto lower_diff = fabs(lower_b);
|
|
|
|
|
auto rounded_value = upper_diff < lower_diff ? upper_b : lower_b;
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { rounded_value, resolved_type };
|
2023-05-27 16:07:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void RoundCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-27 16:07:50 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}ROUND: {}\n", "", indent, to_string());
|
2023-05-27 16:07:50 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool RoundCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_strategy == static_cast<RoundCalculationNode const&>(other).m_strategy
|
|
|
|
|
&& m_x->equals(*static_cast<RoundCalculationNode const&>(other).m_x)
|
|
|
|
|
&& m_y->equals(*static_cast<RoundCalculationNode const&>(other).m_y);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<ModCalculationNode> ModCalculationNode::create(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y)
|
2023-05-27 19:03:07 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The result of adding the types of its comma-separated calculations.
|
|
|
|
|
auto numeric_type = add_the_types(*x, *y);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) ModCalculationNode(move(x), move(y), move(numeric_type)));
|
2023-05-27 19:03:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
ModCalculationNode::ModCalculationNode(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Mod, move(numeric_type))
|
2023-05-27 19:03:07 +02:00
|
|
|
|
, m_x(move(x))
|
|
|
|
|
, m_y(move(y))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ModCalculationNode::~ModCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String ModCalculationNode::to_string() const
|
2023-05-27 19:03:07 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("mod("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_x->to_string());
|
2023-05-27 19:03:07 +02:00
|
|
|
|
builder.append(", "sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_y->to_string());
|
2023-05-27 19:03:07 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-27 19:03:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ModCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_x->contains_percentage() || m_y->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult ModCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-27 19:03:07 +02: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
|
|
|
|
auto node_a = m_x->resolve(context);
|
|
|
|
|
auto node_b = m_y->resolve(context);
|
2023-05-27 19:03:07 +02:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto node_a_value = node_a.value();
|
|
|
|
|
auto node_b_value = node_b.value();
|
2023-05-27 19:03:07 +02:00
|
|
|
|
|
|
|
|
|
auto quotient = floor(node_a_value / node_b_value);
|
|
|
|
|
auto value = node_a_value - (node_b_value * quotient);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return { value, node_a.type() };
|
2023-05-27 19:03:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void ModCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-27 19:03:07 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}MOD: {}\n", "", indent, to_string());
|
2023-05-27 19:03:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool ModCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_x->equals(*static_cast<ModCalculationNode const&>(other).m_x)
|
|
|
|
|
&& m_y->equals(*static_cast<ModCalculationNode const&>(other).m_y);
|
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
NonnullRefPtr<RemCalculationNode> RemCalculationNode::create(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y)
|
2023-05-27 19:08:07 +02:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// https://www.w3.org/TR/css-values-4/#determine-the-type-of-a-calculation
|
|
|
|
|
// The result of adding the types of its comma-separated calculations.
|
|
|
|
|
auto numeric_type = add_the_types(*x, *y);
|
2025-01-22 16:50:54 +00:00
|
|
|
|
return adopt_ref(*new (nothrow) RemCalculationNode(move(x), move(y), move(numeric_type)));
|
2023-05-27 19:08:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
2025-01-22 16:50:54 +00:00
|
|
|
|
RemCalculationNode::RemCalculationNode(NonnullRefPtr<CalculationNode> x, NonnullRefPtr<CalculationNode> y, Optional<CSSNumericType> numeric_type)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
: CalculationNode(Type::Rem, move(numeric_type))
|
2023-05-27 19:08:07 +02:00
|
|
|
|
, m_x(move(x))
|
|
|
|
|
, m_y(move(y))
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
RemCalculationNode::~RemCalculationNode() = default;
|
|
|
|
|
|
2023-08-22 14:08:15 +01:00
|
|
|
|
String RemCalculationNode::to_string() const
|
2023-05-27 19:08:07 +02:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("rem("sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_x->to_string());
|
2023-05-27 19:08:07 +02:00
|
|
|
|
builder.append(", "sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.append(m_y->to_string());
|
2023-05-27 19:08:07 +02:00
|
|
|
|
builder.append(")"sv);
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(builder.to_string());
|
2023-05-27 19:08:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool RemCalculationNode::contains_percentage() const
|
|
|
|
|
{
|
|
|
|
|
return m_x->contains_percentage() || m_y->contains_percentage();
|
|
|
|
|
}
|
|
|
|
|
|
LibWeb/CSS: Wrap calc()-resolution data in a struct
Initially I added this to the existing CalculationContext, but in
reality, we have some data at parse-time and different data at
resolve-time, so it made more sense to keep those separate.
Instead of needing a variety of methods for resolving a Foo, depending
on whether we have a Layout::Node available, or a percentage basis, or
a length resolution context... put those in a
CalculationResolutionContext, and just pass that one thing to these
methods. This also removes the need for separate resolve_*_percentage()
methods, because we can just pass the percentage basis in to the regular
resolve_foo() method.
This also corrects the issue that *any* calculation may need to resolve
lengths, but we previously only passed a length resolution context to
specific types in some situations. Now, they can all have one available,
though it's up to the caller to provide it.
2025-01-22 16:05:32 +00:00
|
|
|
|
CalculatedStyleValue::CalculationResult RemCalculationNode::resolve(CalculationResolutionContext const& context) const
|
2023-05-27 19:08:07 +02: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
|
|
|
|
auto node_a = m_x->resolve(context);
|
|
|
|
|
auto node_b = m_y->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto value = fmod(node_a.value(), node_b.value());
|
|
|
|
|
return { value, node_a.type() };
|
2023-05-27 19:08:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
2023-08-22 14:13:22 +01:00
|
|
|
|
void RemCalculationNode::dump(StringBuilder& builder, int indent) const
|
2023-05-27 19:08:07 +02:00
|
|
|
|
{
|
2023-08-22 14:08:15 +01:00
|
|
|
|
builder.appendff("{: >{}}REM: {}\n", "", indent, to_string());
|
2023-05-27 19:08:07 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-01-09 12:41:43 +01:00
|
|
|
|
bool RemCalculationNode::equals(CalculationNode const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (this == &other)
|
|
|
|
|
return true;
|
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
|
|
|
|
return m_x->equals(*static_cast<RemCalculationNode const&>(other).m_x)
|
|
|
|
|
&& m_y->equals(*static_cast<RemCalculationNode const&>(other).m_y);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
CalculatedStyleValue::CalculationResult CalculatedStyleValue::CalculationResult::from_value(Value const& value, CalculationResolutionContext const& context, Optional<CSSNumericType> numeric_type)
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2024-12-22 23:27:36 +10:00
|
|
|
|
auto const expected_numeric_type = numeric_type_from_calculated_style_value(value, {});
|
|
|
|
|
if (numeric_type.has_value()) {
|
|
|
|
|
VERIFY(numeric_type.value() == expected_numeric_type);
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
auto number = value.visit(
|
|
|
|
|
[](Number const& number) { return number.value(); },
|
|
|
|
|
[](Angle const& angle) { return angle.to_degrees(); },
|
|
|
|
|
[](Flex const& flex) { return flex.to_fr(); },
|
|
|
|
|
[](Frequency const& frequency) { return frequency.to_hertz(); },
|
|
|
|
|
[&context](Length const& length) {
|
|
|
|
|
// Handle some common cases first, so we can resolve more without a context
|
|
|
|
|
if (length.is_auto())
|
|
|
|
|
return 0.0;
|
2023-03-30 17:34:14 +01:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
if (length.is_absolute())
|
|
|
|
|
return length.absolute_length_to_px().to_double();
|
2023-03-30 17:34:14 +01:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
// If we don't have a context, we cant resolve the length, so return NAN
|
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
|
|
|
|
if (!context.length_resolution_context.has_value()) {
|
2024-12-18 13:15:26 +00:00
|
|
|
|
dbgln("Failed to resolve length, likely due to calc() being used with relative units and a property not taking it into account");
|
|
|
|
|
return AK::NaN<double>;
|
2024-10-16 15:00:25 +02: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
|
|
|
|
return length.to_px(context.length_resolution_context.value()).to_double();
|
2023-03-30 17:34:14 +01:00
|
|
|
|
},
|
2024-12-18 13:15:26 +00:00
|
|
|
|
[](Resolution const& resolution) { return resolution.to_dots_per_pixel(); },
|
|
|
|
|
[](Time const& time) { return time.to_seconds(); },
|
|
|
|
|
[](Percentage const& percentage) { return percentage.value(); });
|
2023-03-30 17:34:14 +01:00
|
|
|
|
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return CalculationResult { number, numeric_type };
|
2023-03-30 17:34:14 +01: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 CalculatedStyleValue::CalculationResult::add(CalculationResult const& other)
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
m_value = m_value + other.m_value;
|
|
|
|
|
m_type = m_type.has_value() && other.m_type.has_value() ? m_type->added_to(*other.m_type) : OptionalNone {};
|
|
|
|
|
}
|
2023-03-30 17:34:14 +01: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 CalculatedStyleValue::CalculationResult::subtract(CalculationResult const& other)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
{
|
|
|
|
|
m_value = m_value - other.m_value;
|
|
|
|
|
m_type = m_type.has_value() && other.m_type.has_value() ? m_type->added_to(*other.m_type) : OptionalNone {};
|
2023-03-30 17:34:14 +01: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 CalculatedStyleValue::CalculationResult::multiply_by(CalculationResult const& other)
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
m_value = m_value * other.m_value;
|
|
|
|
|
m_type = m_type.has_value() && other.m_type.has_value() ? m_type->multiplied_by(*other.m_type) : OptionalNone {};
|
|
|
|
|
}
|
2023-03-30 17:34:14 +01: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 CalculatedStyleValue::CalculationResult::divide_by(CalculationResult const& other)
|
2024-12-18 13:15:26 +00:00
|
|
|
|
{
|
|
|
|
|
auto other_copy = other;
|
|
|
|
|
other_copy.invert();
|
|
|
|
|
m_value = m_value * other_copy.m_value;
|
|
|
|
|
m_type = m_type.has_value() && other.m_type.has_value() ? m_type->multiplied_by(*other.m_type) : OptionalNone {};
|
2023-03-30 17:34:14 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-12-11 15:05:56 +00:00
|
|
|
|
void CalculatedStyleValue::CalculationResult::negate()
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2024-12-18 13:15:26 +00:00
|
|
|
|
m_value = 0 - m_value;
|
2023-03-30 17:34:14 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-12-11 15:05:56 +00:00
|
|
|
|
void CalculatedStyleValue::CalculationResult::invert()
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2023-04-11 15:48:06 +01:00
|
|
|
|
// FIXME: Correctly handle division by zero.
|
2024-12-18 13:15:26 +00:00
|
|
|
|
m_value = 1.0 / m_value;
|
|
|
|
|
if (m_type.has_value())
|
|
|
|
|
m_type = m_type->inverted();
|
2024-09-17 17:51:48 +02:00
|
|
|
|
}
|
|
|
|
|
|
2024-12-11 15:05:56 +00:00
|
|
|
|
String CalculatedStyleValue::to_string(SerializationMode) const
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2023-04-11 15:48:06 +01:00
|
|
|
|
// FIXME: Implement this according to https://www.w3.org/TR/css-values-4/#calc-serialize once that stabilizes.
|
2023-08-22 14:08:15 +01:00
|
|
|
|
return MUST(String::formatted("calc({})", m_calculation->to_string()));
|
2023-03-30 17:34:14 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-12-11 15:05:56 +00:00
|
|
|
|
bool CalculatedStyleValue::equals(CSSStyleValue const& other) const
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2023-04-11 15:48:06 +01:00
|
|
|
|
if (type() != other.type())
|
|
|
|
|
return false;
|
2024-01-09 12:41:43 +01:00
|
|
|
|
|
2024-12-11 15:16:34 +00:00
|
|
|
|
return m_calculation->equals(*other.as_calculated().m_calculation);
|
2023-03-30 17:34:14 +01: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
|
|
|
|
Optional<Angle> CalculatedStyleValue::resolve_angle(CalculationResolutionContext const& context) const
|
2023-03-30 17:34:14 +01: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_angle(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return Angle::make_degrees(result.value());
|
2023-03-30 17:34:14 +01:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
Optional<Flex> CalculatedStyleValue::resolve_flex(CalculationResolutionContext const& context) const
|
2024-10-16 08:50:35 +02: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_flex(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return Flex::make_fr(result.value());
|
2023-09-28 15:18:14 +01:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
Optional<Frequency> CalculatedStyleValue::resolve_frequency(CalculationResolutionContext const& context) const
|
2023-03-30 17:34:14 +01: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_frequency(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return Frequency::make_hertz(result.value());
|
2023-03-30 17:34:14 +01:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
Optional<Length> CalculatedStyleValue::resolve_length(CalculationResolutionContext const& context) const
|
2023-03-30 17:34:14 +01: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_length(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return Length::make_px(CSSPixels { result.value() });
|
|
|
|
|
return {};
|
2023-08-29 18:57:09 +02: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
|
|
|
|
Optional<Percentage> CalculatedStyleValue::resolve_percentage(CalculationResolutionContext const& context) const
|
2023-03-30 17:34:14 +01: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2024-12-18 13:15:26 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_percentage())
|
|
|
|
|
return Percentage { result.value() };
|
2023-03-30 17:34:14 +01:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
Optional<Resolution> CalculatedStyleValue::resolve_resolution(CalculationResolutionContext const& context) const
|
2023-12-30 17:05:23 +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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_resolution(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return Resolution::make_dots_per_pixel(result.value());
|
2023-12-30 17:05:23 +00:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
Optional<Time> CalculatedStyleValue::resolve_time(CalculationResolutionContext const& context) const
|
2023-03-30 17:34:14 +01: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_time(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return Time::make_seconds(result.value());
|
2023-03-30 17:34:14 +01:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
Optional<double> CalculatedStyleValue::resolve_number(CalculationResolutionContext const& context) const
|
2024-11-29 16:41:40 +01: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_number(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return result.value();
|
2023-03-30 17:34:14 +01:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
Optional<i64> CalculatedStyleValue::resolve_integer(CalculationResolutionContext const& context) const
|
2023-03-30 17:34:14 +01: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
|
|
|
|
auto result = m_calculation->resolve(context);
|
2025-01-09 17:23:20 +00:00
|
|
|
|
if (result.type().has_value() && result.type()->matches_number(m_context.percentages_resolve_as))
|
2024-12-18 13:15:26 +00:00
|
|
|
|
return llround(result.value());
|
2024-11-29 16:41:40 +01:00
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
2024-12-11 15:05:56 +00:00
|
|
|
|
bool CalculatedStyleValue::contains_percentage() const
|
2023-03-30 17:34:14 +01:00
|
|
|
|
{
|
2023-04-11 15:48:06 +01:00
|
|
|
|
return m_calculation->contains_percentage();
|
2023-03-30 17:34:14 +01:00
|
|
|
|
}
|
|
|
|
|
|
2024-12-11 15:05:56 +00:00
|
|
|
|
String CalculatedStyleValue::dump() const
|
2024-08-16 16:42:58 +01:00
|
|
|
|
{
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
m_calculation->dump(builder, 0);
|
|
|
|
|
return builder.to_string_without_validation();
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-30 17:34:14 +01:00
|
|
|
|
}
|