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

245 lines
12 KiB
C++
Raw Normal View History

LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
/*
* Copyright (c) 2025, Sam Atkins <sam@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibWeb/CSS/Parser/Parser.h>
#include <LibWeb/CSS/StyleValues/CSSKeywordValue.h>
#include <LibWeb/CSS/StyleValues/FontSourceStyleValue.h>
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
#include <LibWeb/CSS/StyleValues/LengthStyleValue.h>
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
#include <LibWeb/CSS/StyleValues/PercentageStyleValue.h>
#include <LibWeb/CSS/StyleValues/StringStyleValue.h>
LibWeb/CSS: Make `@font-face src` parsing more forgiving As noted in the spec, an invalid (or unsupported) font source should not make the `src` declaration invalid.
2025-04-15 10:58:14 +01:00
#include <LibWeb/CSS/StyleValues/StyleValueList.h>
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
#include <LibWeb/CSS/StyleValues/UnicodeRangeStyleValue.h>
#include <LibWeb/CSS/StyleValues/UnresolvedStyleValue.h>
namespace Web::CSS::Parser {
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
Parser::ParseErrorOr<NonnullRefPtr<CSSStyleValue const>> Parser::parse_descriptor_value(AtRuleID at_rule_id, DescriptorID descriptor_id, TokenStream<ComponentValue>& unprocessed_tokens)
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
{
if (!at_rule_supports_descriptor(at_rule_id, descriptor_id)) {
dbgln_if(CSS_PARSER_DEBUG, "Unsupported descriptor '{}' in '{}'", to_string(descriptor_id), to_string(at_rule_id));
return ParseError::SyntaxError;
}
auto context_guard = push_temporary_value_parsing_context(DescriptorContext { at_rule_id, descriptor_id });
Vector<ComponentValue> component_values;
while (unprocessed_tokens.has_next_token()) {
if (unprocessed_tokens.peek_token().is(Token::Type::Semicolon))
break;
auto const& token = unprocessed_tokens.consume_a_token();
component_values.append(token);
}
TokenStream tokens { component_values };
auto metadata = get_descriptor_metadata(at_rule_id, descriptor_id);
for (auto const& option : metadata.syntax) {
auto transaction = tokens.begin_transaction();
auto parsed_style_value = option.visit(
[&](Keyword keyword) {
return parse_all_as_single_keyword_value(tokens, keyword);
},
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
[&](PropertyID property_id) -> RefPtr<CSSStyleValue const> {
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 12:05:49 +01:00
auto value_or_error = parse_css_value(property_id, tokens);
if (value_or_error.is_error())
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
return nullptr;
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 12:05:49 +01:00
auto value_for_property = value_or_error.release_value();
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
// Descriptors don't accept the following, which properties do:
// - CSS-wide keywords
// - Shorthands
// - Arbitrary substitution functions (so, UnresolvedStyleValue)
if (value_for_property->is_css_wide_keyword() || value_for_property->is_shorthand() || value_for_property->is_unresolved())
return nullptr;
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 12:05:49 +01:00
return value_for_property;
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +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
[&](DescriptorMetadata::ValueType value_type) -> RefPtr<CSSStyleValue const> {
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
switch (value_type) {
LibWeb/CSS: Parse `@page bleed, marks, page-orientation` descriptors These don't have WPT tests so I've added some myself.
2025-05-14 16:05:53 +01:00
case DescriptorMetadata::ValueType::CropOrCross: {
// crop || cross
auto first = parse_keyword_value(tokens);
LibWeb/CSS: Don't remove whitespace early when parsing descriptor values
2025-07-03 06:21:50 +01:00
tokens.discard_whitespace();
LibWeb/CSS: Parse `@page bleed, marks, page-orientation` descriptors These don't have WPT tests so I've added some myself.
2025-05-14 16:05:53 +01:00
auto second = parse_keyword_value(tokens);
if (!first)
return nullptr;
RefPtr<CSSStyleValue const> crop;
RefPtr<CSSStyleValue const> cross;
if (first->to_keyword() == Keyword::Crop)
crop = first;
else if (first->to_keyword() == Keyword::Cross)
cross = first;
else
return nullptr;
if (!second)
return first.release_nonnull();
if (crop.is_null() && second->to_keyword() == Keyword::Crop)
crop = second.release_nonnull();
else if (cross.is_null() && second->to_keyword() == Keyword::Cross)
cross = second.release_nonnull();
else
return nullptr;
return StyleValueList::create(StyleValueVector { crop.release_nonnull(), cross.release_nonnull() }, StyleValueList::Separator::Space);
}
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
case DescriptorMetadata::ValueType::FamilyName:
return parse_family_name_value(tokens);
LibWeb/CSS: Make `@font-face src` parsing more forgiving As noted in the spec, an invalid (or unsupported) font source should not make the `src` declaration invalid.
2025-04-15 10:58:14 +01:00
case DescriptorMetadata::ValueType::FontSrcList: {
// "If a component value is parsed correctly and is of a font format or font tech that the UA
// supports, add it to the list of supported sources. If parsing a component value results in a
// parsing error or its format or tech are unsupported, do not add it to the list of supported
// sources.
// If there are no supported entries at the end of this process, the value for the src descriptor
// is a parse error.
// These parsing rules allow for graceful fallback of fonts for user agents which don’t support a
// particular font tech or font format."
// https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing
auto source_lists = parse_a_comma_separated_list_of_component_values(tokens);
StyleValueVector valid_sources;
for (auto const& source_list : source_lists) {
TokenStream source_tokens { source_list };
if (auto font_source = parse_font_source_value(source_tokens); font_source && !source_tokens.has_next_token())
valid_sources.append(font_source.release_nonnull());
}
if (valid_sources.is_empty())
return nullptr;
return StyleValueList::create(move(valid_sources), StyleValueList::Separator::Comma);
}
LibWeb/CSS: Parse `@page bleed, marks, page-orientation` descriptors These don't have WPT tests so I've added some myself.
2025-05-14 16:05:53 +01:00
case DescriptorMetadata::ValueType::Length:
return parse_length_value(tokens);
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
case DescriptorMetadata::ValueType::OptionalDeclarationValue: {
LibWeb/CSS: Store `@property` initial value as a style value For now, it's the "raw" UnresolvedStyleValue. Later, we'll need to try to parse it into a "real" style value using the property's syntax.
2025-04-07 11:54:51 +01:00
// `component_values` already has what we want. Just skip through its tokens so code below knows we consumed them.
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
while (tokens.has_next_token())
LibWeb/CSS: Store `@property` initial value as a style value For now, it's the "raw" UnresolvedStyleValue. Later, we'll need to try to parse it into a "real" style value using the property's syntax.
2025-04-07 11:54:51 +01:00
tokens.discard_a_token();
LibWeb/CSS: Make UnresolvedStyleValue figure out if it contains ASFs UnresolvedStyleValue::create() has one user where we know if there are any arbitrary substitution functions in the list of CVs, and two users where we don't know and just hope there aren't any. I'm about to add another user that also doesn't know, and so it seems worth just making UnresolvedStyleValue::create() do that work instead. We keep the parameter, now Optional<>, so that we save some redundant work in that one place where we do already know.
2025-07-10 14:19:24 +01:00
return UnresolvedStyleValue::create(move(component_values));
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
}
case DescriptorMetadata::ValueType::PageSize: {
// https://drafts.csswg.org/css-page-3/#page-size-prop
// <length [0,∞]>{1,2} | auto | [ <page-size> || [ portrait | landscape ] ]
// auto
if (auto value = parse_all_as_single_keyword_value(tokens, Keyword::Auto))
return value.release_nonnull();
// <length [0,∞]>{1,2}
if (auto first_length = parse_length_value(tokens)) {
if (first_length->is_length() && first_length->as_length().length().raw_value() < 0)
return nullptr;
LibWeb/CSS: Don't remove whitespace early when parsing descriptor values
2025-07-03 06:21:50 +01:00
tokens.discard_whitespace();
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
if (auto second_length = parse_length_value(tokens)) {
if (second_length->is_length() && second_length->as_length().length().raw_value() < 0)
return nullptr;
return StyleValueList::create(StyleValueVector { first_length.release_nonnull(), second_length.release_nonnull() }, StyleValueList::Separator::Space);
}
return first_length.release_nonnull();
}
// [ <page-size> || [ portrait | landscape ] ]
RefPtr<CSSStyleValue const> page_size;
RefPtr<CSSStyleValue const> orientation;
if (auto first_keyword = parse_keyword_value(tokens)) {
if (first_is_one_of(first_keyword->to_keyword(), Keyword::Landscape, Keyword::Portrait)) {
orientation = first_keyword.release_nonnull();
} else if (keyword_to_page_size(first_keyword->to_keyword()).has_value()) {
page_size = first_keyword.release_nonnull();
} else {
return nullptr;
}
} else {
return nullptr;
}
LibWeb/CSS: Don't remove whitespace early when parsing descriptor values
2025-07-03 06:21:50 +01:00
tokens.discard_whitespace();
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
if (auto second_keyword = parse_keyword_value(tokens)) {
if (orientation.is_null() && first_is_one_of(second_keyword->to_keyword(), Keyword::Landscape, Keyword::Portrait)) {
orientation = second_keyword.release_nonnull();
} else if (page_size.is_null() && keyword_to_page_size(second_keyword->to_keyword()).has_value()) {
page_size = second_keyword.release_nonnull();
} else {
return nullptr;
}
// Portrait is considered the default orientation, so don't include it.
if (orientation->to_keyword() == Keyword::Portrait)
return page_size.release_nonnull();
return StyleValueList::create(StyleValueVector { page_size.release_nonnull(), orientation.release_nonnull() }, StyleValueList::Separator::Space);
}
return page_size ? page_size.release_nonnull() : orientation.release_nonnull();
}
case DescriptorMetadata::ValueType::PositivePercentage: {
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
if (auto percentage_value = parse_percentage_value(tokens)) {
if (percentage_value->is_percentage()) {
if (percentage_value->as_percentage().value() < 0)
return nullptr;
return percentage_value.release_nonnull();
}
// All calculations in descriptors must be resolvable at parse-time.
if (percentage_value->is_calculated()) {
LibWeb: Mark `CalculatedStyleValue::resolve_*` methods as deprecated The existing resolve methods are not to spec and we are working to replace them with new ones based on the `simplify_a_calculation_tree` method. These are marked as deprecated rather than replaced outright as work will need to be done on the caller side to be made compatible with the new methods, for instance the new methods can fail to resolve (e.g. if we are missing required context), where the existing methods will always resolve (albeit sometimes with an incorrect value). No functionality changes.
2025-07-02 19:12:33 +12:00
auto percentage = percentage_value->as_calculated().resolve_percentage_deprecated({});
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
if (percentage.has_value() && percentage->value() >= 0)
return PercentageStyleValue::create(percentage.release_value());
return nullptr;
}
}
return nullptr;
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
}
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
case DescriptorMetadata::ValueType::String:
return parse_string_value(tokens);
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
case DescriptorMetadata::ValueType::UnicodeRangeTokens: {
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
return parse_comma_separated_value_list(tokens, [this](auto& tokens) -> RefPtr<CSSStyleValue const> {
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
return parse_unicode_range_value(tokens);
});
}
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
}
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way.
2025-04-02 17:05:48 +01:00
return nullptr;
});
if (!parsed_style_value || tokens.has_next_token())
continue;
transaction.commit();
return parsed_style_value.release_nonnull();
}
if constexpr (CSS_PARSER_DEBUG) {
dbgln("Failed to parse descriptor '{}' in '{}'", to_string(descriptor_id), to_string(at_rule_id));
tokens.dump_all_tokens();
}
return ParseError::SyntaxError;
}
Optional<Descriptor> Parser::convert_to_descriptor(AtRuleID at_rule_id, Declaration const& declaration)
{
auto descriptor_id = descriptor_id_from_string(at_rule_id, declaration.name);
if (!descriptor_id.has_value())
return {};
auto value_token_stream = TokenStream(declaration.value);
auto value = parse_descriptor_value(at_rule_id, descriptor_id.value(), value_token_stream);
if (value.is_error()) {
if (value.error() == ParseError::SyntaxError) {
if constexpr (CSS_PARSER_DEBUG) {
dbgln("Unable to parse value for CSS @{} descriptor '{}'.", to_string(at_rule_id), declaration.name);
value_token_stream.dump_all_tokens();
}
}
return {};
}
return Descriptor { *descriptor_id, value.release_value() };
}
}
Reference in a new issue Copy permalink