Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/CSS/Supports.cpp

93 lines
2.2 KiB
C++
Raw 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 15:40:19 +01:00
/*
LibWeb/CSS: Evaluate Supports query components during parsing Instead of parsing the parts of a `@supports` query, then only evaluating them when constructing the Supports itself, we can instead evaluate them as we parse them. This simplifies things as we no longer need to pass a Realm around, and don't have to re-parse the conditions again with a new Parser instance.
2025-03-13 16:04:48 +00:00
* Copyright (c) 2021-2025, 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 15:40:19 +01: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 16:54:25 +00:00
#include <LibJS/Runtime/Realm.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 15:40:19 +01:00
#include <LibWeb/CSS/Supports.h>
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 10:31:27 +00: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 15:40:19 +01:00
: m_condition(move(condition))
{
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 10:31:27 +00:00
m_matches = m_condition->evaluate_to_boolean(nullptr);
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 15:40:19 +01: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 10:31:27 +00:00
MatchResult Supports::Declaration::evaluate(HTML::Window 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 17:22:05 +00: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 10:31:27 +00: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 17:22:05 +00:00
}
LibWeb: Make serializing Supports rules infallible
2023-08-22 12:47:38 +01:00
String Supports::Declaration::to_string() const
LibWeb: Implement `@supports` serialization
2022-04-22 15:18:47 +01:00
{
LibWeb: Implement `CSSImportRule.supportsText` Returns the supports condition specified by the given import at-rule.
2025-03-19 11:32:34 +00:00
return m_declaration;
LibWeb: Implement `@supports` serialization
2022-04-22 15:18:47 +01: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 19:55:31 +00: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 10:31:27 +00: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 19:55:31 +00: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 10:31:27 +00:00
MatchResult Supports::Selector::evaluate(HTML::Window 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 19:55:31 +00: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 10:31:27 +00: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 19:55:31 +00: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 10:31:27 +00: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 19:55:31 +00: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 10:31:27 +00: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 19:55:31 +00: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 10:31:27 +00: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 19:55:31 +00: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 10:31:27 +00: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 19:55:31 +00:00
}
LibWeb/CSS: Implement `@supports font-format()` and `font-tech()` These let authors query whether we support font formats and features.
2025-03-14 11:36:15 +00:00
MatchResult Supports::FontTech::evaluate(HTML::Window const*) const
{
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);
}
MatchResult Supports::FontFormat::evaluate(HTML::Window const*) const
{
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: 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 10:31:27 +00: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 19:55:31 +00: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 10:31:27 +00: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 19:55:31 +00:00
}
void Supports::dump(StringBuilder& builder, int indent_levels) const
{
m_condition->dump(builder, indent_levels);
}
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 15:40:19 +01:00
}
Reference in a new issue Copy permalink