Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/CSS/CalculatedOr.cpp

111 lines
3.8 KiB
C++
Raw Normal View History

LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
/*
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
* Copyright (c) 2023-2025, Sam Atkins <sam@ladybird.org>
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include "CalculatedOr.h"
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
#include <LibWeb/CSS/StyleValues/AngleStyleValue.h>
#include <LibWeb/CSS/StyleValues/FlexStyleValue.h>
#include <LibWeb/CSS/StyleValues/FrequencyStyleValue.h>
#include <LibWeb/CSS/StyleValues/IntegerStyleValue.h>
#include <LibWeb/CSS/StyleValues/LengthStyleValue.h>
#include <LibWeb/CSS/StyleValues/NumberStyleValue.h>
#include <LibWeb/CSS/StyleValues/PercentageStyleValue.h>
#include <LibWeb/CSS/StyleValues/ResolutionStyleValue.h>
#include <LibWeb/CSS/StyleValues/TimeStyleValue.h>
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
namespace Web::CSS {
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<Angle> AngleOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_angle(context);
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> AngleOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return AngleStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<Flex> FlexOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Fill in some missing FooOrCalculated types
2023-12-27 12:56:00 +00:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_flex(context);
LibWeb: Fill in some missing FooOrCalculated types
2023-12-27 12:56:00 +00:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> FlexOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return FlexStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<Frequency> FrequencyOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_frequency(context);
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> FrequencyOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return FrequencyStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<i64> IntegerOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Fill in some missing FooOrCalculated types
2023-12-27 12:56:00 +00:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_integer(context);
LibWeb/CSS: Allow calc() values in media queries It was initially thought that the spec disallows them, but this turned out to be incorrect. This fixes several WPT tests.
2024-11-29 13:16:15 +01:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> IntegerOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return IntegerStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<Length> LengthOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_length(context);
LibWeb: Allow calc() values in image `sizes` attribute Note that we currently can't resolve calc() values without a layout node, so when normalizing an image's source set, we'll flush any pending layout updates and hope that gives us an up-to-date layout node. I've left a FIXME about implementing this in a more elegant and less layout-thrashy way, as that will require more architectural work.
2023-07-28 15:52:06 +02:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> LengthOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return LengthStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<double> NumberOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Fill in some missing FooOrCalculated types
2023-12-27 12:56:00 +00:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_number(context);
LibWeb: Fill in some missing FooOrCalculated types
2023-12-27 12:56:00 +00:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> NumberOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return NumberStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<Percentage> PercentageOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_percentage(context);
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> PercentageOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return PercentageStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<Resolution> ResolutionOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb/CSS: Allow calc() values in media queries It was initially thought that the spec disallows them, but this turned out to be incorrect. This fixes several WPT tests.
2024-11-29 13:16:15 +01:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_resolution(context);
LibWeb/CSS: Allow calc() values in media queries It was initially thought that the spec disallows them, but this turned out to be incorrect. This fixes several WPT tests.
2024-11-29 13:16:15 +01:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> ResolutionOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return ResolutionStyleValue::create(value());
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
Optional<Time> TimeOrCalculated::resolve_calculated(NonnullRefPtr<CalculatedStyleValue const> const& calculated, CalculationResolutionContext const& context) const
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
{
LibWeb/CSS: Update CalculatedOr API to use CalculationResolutionContext To be properly compatible with calc(), the resolved() methods all need: - A length resolution context - To return an Optional, as the calculation might not be resolvable A bonus of this is that we can get rid of the overloads of `resolved()` as they now all behave the same way. A downside is a scattering of `value_or()` wherever these are used. It might be the case that all unresolvable calculations have been rejected before this point, but I'm not confident, and so I'll leave it like this for now.
2025-01-22 15:00:13 +00:00
return calculated->resolve_time(context);
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
}
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
NonnullRefPtr<CSSStyleValue const> TimeOrCalculated::create_style_value() const
LibWeb: Add method for converting a FooOrCalculated to a StyleValue
2023-12-28 17:37:37 +00:00
{
return TimeStyleValue::create(value());
}
LibWeb: Introduce CalculatedOr type This is intended as a replacement for Length and friends each holding a `RefPtr<CalculatedStyleValue>`. Instead, let's make the types explicit about whether they are calculated or not. This then means a Length is always a Length, and won't require including `StyleValue.h`. As noted, it's probably nicer for LengthOrCalculated to live in `Length.h`, but we can't do that until Length stops including `StyleValue.h`.
2023-03-30 16:57:49 +01:00
}
Reference in a new issue Copy permalink