dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/CSS/Supports.cpp

133 lines
3.4 KiB
C++
Raw Permalink Normal View History

LibWeb: Add CSS 'Supports' class The name is a little awkward, but this corresponds to the condition of a `@supports` rule or the `CSS.supports("")` function. A supports query only gets evaluated once, since its condition cannot change during runtime. (We either support something or we don't, and the spec specifically mentions that user preferences that disable features do not affect the result here.) We keep a representation of it around though, so that it can be serialized if needed. This is a little awkward since we hold onto a `StyleDeclarationRule` which should be an internal Parser class. This means making some Parser functions more public. Potentially we could evaluate the Supports inside the Parser, and have it only store a String representation of itself. But this works for now. :^)
2021-10-08 11:40:19 -03:00
/*
LibWeb/CSS: Add the env() function to `@supports` conditions This was just added to the spec and doesn't yet have WPT coverage, but it's also pretty trivial.
2026-03-27 12:11:16 -03:00
* Copyright (c) 2021-2026, Sam Atkins <sam@ladybird.org>
LibWeb: Add CSS 'Supports' class The name is a little awkward, but this corresponds to the condition of a `@supports` rule or the `CSS.supports("")` function. A supports query only gets evaluated once, since its condition cannot change during runtime. (We either support something or we don't, and the spec specifically mentions that user preferences that disable features do not affect the result here.) We keep a representation of it around though, so that it can be serialized if needed. This is a little awkward since we hold onto a `StyleDeclarationRule` which should be an internal Parser class. This means making some Parser functions more public. Potentially we could evaluate the Supports inside the Parser, and have it only store a String representation of itself. But this works for now. :^)
2021-10-08 11:40:19 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Remove CSS::Parser::ParsingContext's default constructor This relied on pulling the current realm from the main thread VM, which requires an execution context to be on the VM's stack. This heavily relied on the dummy execution context that is always on the stack, for example, when parsing the UA style sheets where no JavaScript is running.
2023-02-28 13:54:25 -03:00
#include <LibJS/Runtime/Realm.h>
LibWeb/CSS: Add the env() function to `@supports` conditions This was just added to the spec and doesn't yet have WPT coverage, but it's also pretty trivial.
2026-03-27 12:11:16 -03:00
#include <LibWeb/CSS/Serialize.h>
LibWeb: Add CSS 'Supports' class The name is a little awkward, but this corresponds to the condition of a `@supports` rule or the `CSS.supports("")` function. A supports query only gets evaluated once, since its condition cannot change during runtime. (We either support something or we don't, and the spec specifically mentions that user preferences that disable features do not affect the result here.) We keep a representation of it around though, so that it can be serialized if needed. This is a little awkward since we hold onto a `StyleDeclarationRule` which should be an internal Parser class. This means making some Parser functions more public. Potentially we could evaluate the Supports inside the Parser, and have it only store a String representation of itself. But this works for now. :^)
2021-10-08 11:40:19 -03:00
#include <LibWeb/CSS/Supports.h>
LibWeb/CSS: Make Supports responsible for dumping itself entirely This will reduce the boilerplate for other things that want to dump a Supports, such as `@import`.
2025-12-04 09:23:20 -03:00
#include <LibWeb/Dump.h>
LibWeb: Add CSS 'Supports' class The name is a little awkward, but this corresponds to the condition of a `@supports` rule or the `CSS.supports("")` function. A supports query only gets evaluated once, since its condition cannot change during runtime. (We either support something or we don't, and the spec specifically mentions that user preferences that disable features do not affect the result here.) We keep a representation of it around though, so that it can be serialized if needed. This is a little awkward since we hold onto a `StyleDeclarationRule` which should be an internal Parser class. This means making some Parser functions more public. Potentially we could evaluate the Supports inside the Parser, and have it only store a String representation of itself. But this works for now. :^)
2021-10-08 11:40:19 -03:00
namespace Web::CSS {
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
Supports::Supports(NonnullOwnPtr<BooleanExpression>&& condition)
LibWeb: Add CSS 'Supports' class The name is a little awkward, but this corresponds to the condition of a `@supports` rule or the `CSS.supports("")` function. A supports query only gets evaluated once, since its condition cannot change during runtime. (We either support something or we don't, and the spec specifically mentions that user preferences that disable features do not affect the result here.) We keep a representation of it around though, so that it can be serialized if needed. This is a little awkward since we hold onto a `StyleDeclarationRule` which should be an internal Parser class. This means making some Parser functions more public. Potentially we could evaluate the Supports inside the Parser, and have it only store a String representation of itself. But this works for now. :^)
2021-10-08 11:40:19 -03:00
: m_condition(move(condition))
{
LibWeb: Give BooleanExpression an evaluation context Different users of BooleanExpression have different requirements for evaluation: - `@media` needs a Document - `@supports` doesn't need anything - `@container` needs a container Element To support these without expanding the API, replace the Document* parameter with a BooleanExpressionEvaluationContext type which contains these different values. No behaviour changes.
2026-05-08 10:50:13 -03:00
m_matches = m_condition->evaluate_to_boolean({});
LibWeb: Add CSS 'Supports' class The name is a little awkward, but this corresponds to the condition of a `@supports` rule or the `CSS.supports("")` function. A supports query only gets evaluated once, since its condition cannot change during runtime. (We either support something or we don't, and the spec specifically mentions that user preferences that disable features do not affect the result here.) We keep a representation of it around though, so that it can be serialized if needed. This is a little awkward since we hold onto a `StyleDeclarationRule` which should be an internal Parser class. This means making some Parser functions more public. Potentially we could evaluate the Supports inside the Parser, and have it only store a String representation of itself. But this works for now. :^)
2021-10-08 11:40:19 -03:00
}
LibWeb: Give BooleanExpression an evaluation context Different users of BooleanExpression have different requirements for evaluation: - `@media` needs a Document - `@supports` doesn't need anything - `@container` needs a container Element To support these without expanding the API, replace the Document* parameter with a BooleanExpressionEvaluationContext type which contains these different values. No behaviour changes.
2026-05-08 10:50:13 -03:00
MatchResult Supports::Declaration::evaluate(BooleanExpressionEvaluationContext const&) const
LibWeb: Implement `@supports selector(.foo)` This is defined in https://www.w3.org/TR/css-conditional-4/#at-supports-ext which just became a CR. :^)
2022-02-19 14:22:05 -03:00
{
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
return as_match_result(m_matches);
LibWeb: Implement `@supports selector(.foo)` This is defined in https://www.w3.org/TR/css-conditional-4/#at-supports-ext which just became a CR. :^)
2022-02-19 14:22:05 -03:00
}
LibWeb: Make serializing Supports rules infallible
2023-08-22 08:47:38 -03:00
String Supports::Declaration::to_string() const
LibWeb: Implement `@supports` serialization
2022-04-22 11:18:47 -03:00
{
LibWeb: Implement `CSSImportRule.supportsText` Returns the supports condition specified by the given import at-rule.
2025-03-19 08:32:34 -03:00
return m_declaration;
LibWeb: Implement `@supports` serialization
2022-04-22 11:18:47 -03:00
}
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
void Supports::Declaration::dump(StringBuilder& builder, int indent_levels) const
{
indent(builder, indent_levels);
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
builder.appendff("Declaration: `{}`, matches={}\n", m_declaration, m_matches);
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
}
LibWeb: Give BooleanExpression an evaluation context Different users of BooleanExpression have different requirements for evaluation: - `@media` needs a Document - `@supports` doesn't need anything - `@container` needs a container Element To support these without expanding the API, replace the Document* parameter with a BooleanExpressionEvaluationContext type which contains these different values. No behaviour changes.
2026-05-08 10:50:13 -03:00
MatchResult Supports::Selector::evaluate(BooleanExpressionEvaluationContext const&) const
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
{
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
return as_match_result(m_matches);
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
}
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
String Supports::Selector::to_string() const
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
{
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
return MUST(String::formatted("selector({})", m_selector));
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
}
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
void Supports::Selector::dump(StringBuilder& builder, int indent_levels) const
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
{
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
indent(builder, indent_levels);
builder.appendff("Selector: `{}` matches={}\n", m_selector, m_matches);
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
}
LibWeb: Give BooleanExpression an evaluation context Different users of BooleanExpression have different requirements for evaluation: - `@media` needs a Document - `@supports` doesn't need anything - `@container` needs a container Element To support these without expanding the API, replace the Document* parameter with a BooleanExpressionEvaluationContext type which contains these different values. No behaviour changes.
2026-05-08 10:50:13 -03:00
MatchResult Supports::FontTech::evaluate(BooleanExpressionEvaluationContext const&) const
LibWeb/CSS: Implement `@supports font-format()` and `font-tech()` These let authors query whether we support font formats and features.
2025-03-14 08:36:15 -03:00
{
return as_match_result(m_matches);
}
String Supports::FontTech::to_string() const
{
return MUST(String::formatted("font-tech({})", m_tech));
}
void Supports::FontTech::dump(StringBuilder& builder, int indent_levels) const
{
indent(builder, indent_levels);
builder.appendff("FontTech: `{}` matches={}\n", m_tech, m_matches);
}
LibWeb: Give BooleanExpression an evaluation context Different users of BooleanExpression have different requirements for evaluation: - `@media` needs a Document - `@supports` doesn't need anything - `@container` needs a container Element To support these without expanding the API, replace the Document* parameter with a BooleanExpressionEvaluationContext type which contains these different values. No behaviour changes.
2026-05-08 10:50:13 -03:00
MatchResult Supports::FontFormat::evaluate(BooleanExpressionEvaluationContext const&) const
LibWeb/CSS: Implement `@supports font-format()` and `font-tech()` These let authors query whether we support font formats and features.
2025-03-14 08:36:15 -03:00
{
return as_match_result(m_matches);
}
String Supports::FontFormat::to_string() const
{
return MUST(String::formatted("font-format({})", m_format));
}
void Supports::FontFormat::dump(StringBuilder& builder, int indent_levels) const
{
indent(builder, indent_levels);
builder.appendff("FontFormat: `{}` matches={}\n", m_format, m_matches);
}
LibWeb: Give BooleanExpression an evaluation context Different users of BooleanExpression have different requirements for evaluation: - `@media` needs a Document - `@supports` doesn't need anything - `@container` needs a container Element To support these without expanding the API, replace the Document* parameter with a BooleanExpressionEvaluationContext type which contains these different values. No behaviour changes.
2026-05-08 10:50:13 -03:00
MatchResult Supports::Env::evaluate(BooleanExpressionEvaluationContext const&) const
LibWeb/CSS: Add the env() function to `@supports` conditions This was just added to the spec and doesn't yet have WPT coverage, but it's also pretty trivial.
2026-03-27 12:11:16 -03:00
{
return as_match_result(m_matches);
}
String Supports::Env::to_string() const
{
return MUST(String::formatted("font-format({})", serialize_an_identifier(m_variable_name)));
}
void Supports::Env::dump(StringBuilder& builder, int indent_levels) const
{
indent(builder, indent_levels);
builder.appendff("Env: `{}` matches={}\n", m_variable_name, m_matches);
}
LibWeb/CSS: Implement `@supports at-rule(@foo)` Matches if we support the at-rule in some form. Keeping this list up to date is a bit awkward, but we don't add at-rules too often, and having all at-rules defined in JSON would just move the awkward-to-maintain list somewhere else.
2026-05-21 11:54:44 -03:00
MatchResult Supports::AtRule::evaluate(BooleanExpressionEvaluationContext const&) const
{
return as_match_result(m_matches);
}
String Supports::AtRule::to_string() const
{
StringBuilder builder;
builder.append("at-rule(@"sv);
serialize_an_identifier(builder, m_name);
builder.append(')');
return builder.to_string_without_validation();
}
void Supports::AtRule::dump(StringBuilder& builder, int indent_levels) const
{
indent(builder, indent_levels);
builder.appendff("AtRule: `@{}` matches={}\n", m_name, m_matches);
}
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
String Supports::to_string() const
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
{
LibWeb: Implement generic boolean logic for media/supports queries CSS Values 5 now defines a `<boolean-expr[]>` type that is used in place of the bespoke grammar that previously existed for `@media` and `@supports` queries. This commit implements some BooleanExpression types to represent the nodes in a `<boolean-expr[]>`, and reimplements `@media` and `@supports` queries using this. The one part of this implementation I'm not convinced on is that the `evaluate()` methods take a `HTML::Window*`. This is a compromise because `@media` requires a Window, and `@supports` does not require anything at all. As more users of `<boolean-expr[]>` get implemented in the future, it will become clear if this is sufficient, or if we need to do something smarter. As a bonus, this actually improves our serialization of media queries!
2025-03-14 07:31:27 -03:00
return m_condition->to_string();
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
}
void Supports::dump(StringBuilder& builder, int indent_levels) const
{
LibWeb/CSS: Make Supports responsible for dumping itself entirely This will reduce the boilerplate for other things that want to dump a Supports, such as `@import`.
2025-12-04 09:23:20 -03:00
dump_indent(builder, indent_levels);
builder.appendff("Supports condition: (matches = {})\n", m_matches);
m_condition->dump(builder, indent_levels + 1);
LibWeb: Make dumping of `@supports` more useful The string representation doesn't tell you what the internals look like, which is what you want when dumping.
2024-11-01 16:55:31 -03:00
}
LibWeb: Add CSS 'Supports' class The name is a little awkward, but this corresponds to the condition of a `@supports` rule or the `CSS.supports("")` function. A supports query only gets evaluated once, since its condition cannot change during runtime. (We either support something or we don't, and the spec specifically mentions that user preferences that disable features do not affect the result here.) We keep a representation of it around though, so that it can be serialized if needed. This is a little awkward since we hold onto a `StyleDeclarationRule` which should be an internal Parser class. This means making some Parser functions more public. Potentially we could evaluate the Supports inside the Parser, and have it only store a String representation of itself. But this works for now. :^)
2021-10-08 11:40:19 -03:00
}
Reference in a new issue Copy permalink