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/Parser/DescriptorParsing.cpp

243 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
*/
LibWeb/CSS: Use ErrorReporter for property/descriptor parsing errors
2025-07-23 11:05:39 +01:00
#include <LibWeb/CSS/Parser/ErrorReporter.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/Parser/Parser.h>
#include <LibWeb/CSS/StyleValues/FontSourceStyleValue.h>
LibWeb/CSS: Rename CSSKeywordValue -> KeywordStyleValue The typed-om CSSKeywordValue will need to be a separate class.
2025-08-08 10:28:41 +01:00
#include <LibWeb/CSS/StyleValues/KeywordStyleValue.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: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
Parser::ParseErrorOr<NonnullRefPtr<StyleValue 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)) {
LibWeb/CSS: Use ErrorReporter for property/descriptor parsing errors
2025-07-23 11:05:39 +01:00
ErrorReporter::the().report(UnknownPropertyError {
.rule_name = to_string(at_rule_id),
.property_name = to_string(descriptor_id),
});
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 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: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
[&](PropertyID property_id) -> RefPtr<StyleValue 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
// - Arbitrary substitution functions (so, UnresolvedStyleValue)
LibWeb: Add generic logic for parsing "positional-value-list-shorthands" Continues the work started in #5386 to simplify handling of positional value list shorthand properties. Previously we would parse these as `StyleValueList`s and then rely on `StyleComputer::for_each_property_expanding_shorthands` to expand them into longhands. This required a bit of work to handle `ShorthandStyleValue`s for the `@page` `margin` descriptor.
2025-09-09 20:47:11 +12:00
if (value_for_property->is_css_wide_keyword() || value_for_property->is_unresolved())
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
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: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
[&](DescriptorMetadata::ValueType value_type) -> RefPtr<StyleValue 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;
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
RefPtr<StyleValue const> crop;
RefPtr<StyleValue const> cross;
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
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)) {
LibWeb/CSS: Replace CSSUnitValue with DimensionStyleValue CSSUnitValue is a typed-om type which we will implement separately in the future. However, it still seems useful to give our dimension values a base class. (Maybe they could be templated in the future?) So instead of deleting it entirely, rename it to DimensionStyleValue and make its API match our style better.
2025-08-08 11:08:54 +01:00
if (first_length->is_length() && first_length->as_length().raw_value() < 0)
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
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)) {
LibWeb/CSS: Replace CSSUnitValue with DimensionStyleValue CSSUnitValue is a typed-om type which we will implement separately in the future. However, it still seems useful to give our dimension values a base class. (Maybe they could be templated in the future?) So instead of deleting it entirely, rename it to DimensionStyleValue and make its API match our style better.
2025-08-08 11:08:54 +01:00
if (second_length->is_length() && second_length->as_length().raw_value() < 0)
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
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 ] ]
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
RefPtr<StyleValue const> page_size;
RefPtr<StyleValue const> orientation;
LibWeb/CSS: Parse `@page size` descriptor
2025-05-14 15:07:58 +01:00
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()) {
LibWeb/CSS: Replace CSSUnitValue with DimensionStyleValue CSSUnitValue is a typed-om type which we will implement separately in the future. However, it still seems useful to give our dimension values a base class. (Maybe they could be templated in the future?) So instead of deleting it entirely, rename it to DimensionStyleValue and make its API match our style better.
2025-08-08 11:08:54 +01:00
if (percentage_value->as_percentage().raw_value() < 0)
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;
return percentage_value.release_nonnull();
}
// All calculations in descriptors must be resolvable at parse-time.
if (percentage_value->is_calculated()) {
LibWeb/CSS: Replace resolve_percentage_deprecated() with undeprecated
2025-09-24 14:25:03 +01:00
auto percentage = percentage_value->as_calculated().resolve_percentage({});
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: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
return parse_comma_separated_value_list(tokens, [this](auto& tokens) -> RefPtr<StyleValue 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();
}
LibWeb/CSS: Use ErrorReporter for property/descriptor parsing errors
2025-07-23 11:05:39 +01:00
ErrorReporter::the().report(InvalidPropertyError {
.rule_name = to_string(at_rule_id),
.property_name = to_string(descriptor_id),
.value_string = tokens.dump_string(),
.description = "Failed to parse."_string,
});
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 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);
LibWeb/CSS: Remove duplicate error reporting for invalid descriptors parse_descriptor_value() already logs this.
2025-07-21 13:13:05 +01:00
if (value.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 {};
return Descriptor { *descriptor_id, value.release_value() };
}
}
Reference in a new issue Copy permalink