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

528 lines
28 KiB
C
Raw Normal View History

LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
/*
Everywhere: Use "the SerenityOS developers." in copyright headers We had some inconsistencies before: - Sometimes "The", sometimes "the" - Sometimes trailing ".", sometimes no trailing "." I picked the most common one (lowecase "the", trailing ".") and applied it to all copyright headers. By using the exact same string everywhere we can ensure nothing gets missed during a global search (and replace), and that these inconsistencies are not spread any further (as copyright headers are commonly copied to new files).
2021-04-28 22:46:44 +02:00
* Copyright (c) 2020-2021, the SerenityOS developers.
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
* Copyright (c) 2021-2025, Sam Atkins <sam@ladybird.org>
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
*/
#pragma once
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
#include <AK/Error.h>
LibWeb/CSS: Parse calc() as intermediate types instead of UnparsedCN Previously we created a tree of CalculationNodes with dummy UnparsedCalculationNode children, and then swapped those with the real children. This matched the spec closely but had the unfortunate downside that CalculationNodes couldn't be immutable, and couldn't know their properties at construct-time. UnparsedCalculationNode is also a footgun, as if it gets left in the tree accidentally we would VERIFY(). So instead, let's parse the calc() tree into an intermediate format, and then convert each node in that tree, depth-first, into its corresponding CalculationNode. This means each CalculationNode knows what its children are when it is constructed, and they never change. Apart from deleting UnparsedCalculationNode, we can also get rid of the for_each_child_node() method that was only used by this "replace the children" code.
2024-12-17 14:00:41 +00:00
#include <AK/NonnullRawPtr.h>
LibWeb: Make CSS::Selector reference counted The end goal is to make the PseudoClass::not_selector be a Selector instead of a String that is repeatedly re-parsed. But since Selector contains a Vector of ComplexSelectors, which each have a Vector of SimpleSelectors, it's probably a good idea to not be passing them around by value anyway. :^)
2021-07-12 17:30:40 +01:00
#include <AK/RefPtr.h>
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
#include <AK/Vector.h>
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
#include <LibGC/Ptr.h>
LibWeb+LibGfx: Move UnicodeRange from LibWeb to LibGfx In upcoming changes UnicodeRange is going to be used in LibGfx in a class that represents font cascade list.
2023-12-09 23:30:01 +01:00
#include <LibGfx/Font/UnicodeRange.h>
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
#include <LibWeb/CSS/BooleanExpression.h>
LibWeb: Parse CSS `Supports` ... according to https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition This works very similarly to `@media`, but is different enough to require its own parsing. (Though, the draft of Conditional-4 currently mentions combining the two into a `@when` rule.) Made some small changes to parsing code to make this work. Notably, making `consume_a_declaration()` fail gracefully instead of `VERIFY()`ing.
2021-10-08 15:54:16 +01:00
#include <LibWeb/CSS/CSSStyleDeclaration.h>
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
#include <LibWeb/CSS/CSSStyleValue.h>
LibWeb: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 12:56:37 +01:00
#include <LibWeb/CSS/MediaQuery.h>
LibWeb: Rename CSS::FontFace to CSS::ParsedFontFace This implementation detail of CSSFontFaceRule is hogging the name of a Web API from CSS Font Loading Module Level 3.
2024-05-07 09:18:37 -06:00
#include <LibWeb/CSS/ParsedFontFace.h>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
#include <LibWeb/CSS/Parser/ComponentValue.h>
LibWeb: Move CSS::Parser::Dimension class to a separate file
2023-08-17 15:43:30 +01:00
#include <LibWeb/CSS/Parser/Dimension.h>
LibWeb: Move CSS TokenStream to its own file This lets us use TokenStream in StyleComputer without every user of StyleComputer pulling in the entire CSS Parser.
2022-09-27 16:05:57 +01:00
#include <LibWeb/CSS/Parser/TokenStream.h>
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
#include <LibWeb/CSS/Parser/Tokenizer.h>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
#include <LibWeb/CSS/Parser/Types.h>
LibWeb: Remove now-unused includes from StyleValue.cpp And add them to all the places that relied on getting them transitively.
2023-03-25 14:11:11 +00:00
#include <LibWeb/CSS/PropertyID.h>
LibWeb: Introduce and parse CSS Ratio type This is only used by media-queries, so for now we can skip adding/parsing a StyleValue for these.
2022-03-06 13:48:32 +00:00
#include <LibWeb/CSS/Ratio.h>
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
#include <LibWeb/CSS/Selector.h>
LibWeb: Split AbstractImageStyleValue out of StyleValue.{h,cpp}
2023-03-24 16:42:50 +00:00
#include <LibWeb/CSS/StyleValues/AbstractImageStyleValue.h>
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
#include <LibWeb/CSS/StyleValues/BasicShapeStyleValue.h>
Revert "LibWeb/CSS: Rename CalculatedStyleValue -> CSSMathValue" This reverts commit 76daba3069de4c184c6b2317d0c89b50f81a8c00. We're going to need separate types for the JS-exposed style values, so it doesn't make sense for us to match their names with our internal types.
2024-12-11 15:05:56 +00:00
#include <LibWeb/CSS/StyleValues/CalculatedStyleValue.h>
LibWeb: Parse CSS `Supports` ... according to https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition This works very similarly to `@media`, but is different enough to require its own parsing. (Though, the draft of Conditional-4 currently mentions combining the two into a `@when` rule.) Made some small changes to parsing code to make this work. Notably, making `consume_a_declaration()` fail gracefully instead of `VERIFY()`ing.
2021-10-08 15:54:16 +01:00
#include <LibWeb/CSS/Supports.h>
LibWeb: Stop manually forward-declaring types in CSS Parser.h
2022-04-12 11:32:18 +01:00
#include <LibWeb/Forward.h>
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
LibWeb: Move CSS Parser into new Web::CSS::Parser namespace The goal here is to move the parser-internal classes into this namespace so they can have more convenient names without causing collisions. The Parser itself won't collide, and would be more convenient to just remain `CSS::Parser`, but having a namespace and a class with the same name makes C++ unhappy.
2022-04-12 12:00:07 +01:00
namespace Web::CSS::Parser {
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
LibWeb: Move UnresolvedStyleValue resolution into the CSS Parser Resolving typed `attr()` functions is going to involve using more internal Parser methods, so this is the simplest solution for that. Also... resolving these is basically parsing them, so it makes more sense for that process to live here. This is just moving code, with minimal changes so it still works.
2023-09-04 11:16:49 +01:00
class PropertyDependencyNode;
LibWeb/CSS: Parse calc() as intermediate types instead of UnparsedCN Previously we created a tree of CalculationNodes with dummy UnparsedCalculationNode children, and then swapped those with the real children. This matched the spec closely but had the unfortunate downside that CalculationNodes couldn't be immutable, and couldn't know their properties at construct-time. UnparsedCalculationNode is also a footgun, as if it gets left in the tree accidentally we would VERIFY(). So instead, let's parse the calc() tree into an intermediate format, and then convert each node in that tree, depth-first, into its corresponding CalculationNode. This means each CalculationNode knows what its children are when it is constructed, and they never change. Apart from deleting UnparsedCalculationNode, we can also get rid of the for_each_child_node() method that was only used by this "replace the children" code.
2024-12-17 14:00:41 +00:00
namespace CalcParsing {
struct Operator {
char delim;
};
struct ProductNode;
struct SumNode;
struct InvertNode;
struct NegateNode;
LibWeb/CSS: Remove use of Dimension in calc() parsing Rather than partly-converting number, dimension, and ident tokens at the start of parsing a calculation, and then later finishing it off, we can just do the whole step in convert_to_calculation_node(). This is a little less code, but mainly means we are left with only a single use of the Dimension type in the codebase, so that can be removed soon.
2025-01-07 12:10:40 +00:00
using Node = Variant<Operator, NonnullOwnPtr<ProductNode>, NonnullOwnPtr<SumNode>, NonnullOwnPtr<InvertNode>, NonnullOwnPtr<NegateNode>, NonnullRawPtr<ComponentValue const>>;
LibWeb/CSS: Parse calc() as intermediate types instead of UnparsedCN Previously we created a tree of CalculationNodes with dummy UnparsedCalculationNode children, and then swapped those with the real children. This matched the spec closely but had the unfortunate downside that CalculationNodes couldn't be immutable, and couldn't know their properties at construct-time. UnparsedCalculationNode is also a footgun, as if it gets left in the tree accidentally we would VERIFY(). So instead, let's parse the calc() tree into an intermediate format, and then convert each node in that tree, depth-first, into its corresponding CalculationNode. This means each CalculationNode knows what its children are when it is constructed, and they never change. Apart from deleting UnparsedCalculationNode, we can also get rid of the for_each_child_node() method that was only used by this "replace the children" code.
2024-12-17 14:00:41 +00:00
struct ProductNode {
Vector<Node> children;
};
struct SumNode {
Vector<Node> children;
};
struct InvertNode {
Node child;
};
struct NegateNode {
Node child;
};
}
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
enum class ParsingMode {
Normal,
SVGPresentationAttribute, // See https://svgwg.org/svg2-draft/types.html#presentation-attribute-css-value
};
struct ParsingParams {
explicit ParsingParams(ParsingMode = ParsingMode::Normal);
explicit ParsingParams(JS::Realm&, ParsingMode = ParsingMode::Normal);
explicit ParsingParams(JS::Realm&, URL::URL, ParsingMode = ParsingMode::Normal);
explicit ParsingParams(DOM::Document const&, URL::URL, ParsingMode = ParsingMode::Normal);
explicit ParsingParams(DOM::Document const&, ParsingMode = ParsingMode::Normal);
GC::Ptr<JS::Realm> realm;
GC::Ptr<DOM::Document const> document;
URL::URL url;
ParsingMode mode { ParsingMode::Normal };
};
// The very large CSS Parser implementation code is broken up among several .cpp files:
// Parser.cpp contains the core parser algorithms, defined in https://drafts.csswg.org/css-syntax
// Everything else is in different *Parsing.cpp files
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
class Parser {
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
AK_MAKE_NONCOPYABLE(Parser);
AK_MAKE_NONMOVABLE(Parser);
LibWeb: Propagate errors from CSS Parser construction This requires Parser to be movable, so we remove the `default` destructors from Parser and TokenStream, and give them both move constructors. Since TokenStream only holds a reference to its tokens, (and it needs to, to avoid copying when given eg a function's contents,) we add a manual move constructor for Parser which creates a new TokenStream from the new Parser's tokens, and then manually copies the old TokenStream's state.
2023-03-06 17:17:08 +00:00
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
public:
static Parser create(ParsingParams const&, StringView input, StringView encoding = "utf-8"sv);
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
CSSStyleSheet* parse_as_css_stylesheet(Optional<URL::URL> location);
LibWeb: Stop constructing temporary ElementInlineCSSStyleDeclarations Previously, parse_css_style_attribute() would parse the string, extract the properties, add them to a newly-created ElementInlineCSSStyleDeclarations, and then user code would take the properties back out of it again and throw it away. Instead, just return the list of properties, and the caller can create an EICSD if it needs one.
2025-03-17 12:55:21 +00:00
struct PropertiesAndCustomProperties {
Vector<StyleProperty> properties;
HashMap<FlyString, StyleProperty> custom_properties;
};
PropertiesAndCustomProperties parse_as_style_attribute();
LibWeb: Make CSSRule and all its subclasses GC-allocated
2022-08-07 15:46:44 +02:00
CSSRule* parse_as_css_rule();
LibWeb: Bring `parse_a_declaration()` to spec and add comments User code now calls `parse_as_supports_condition()` which actually does the conversion to a StyleProperty.
2022-03-30 12:05:16 +01:00
Optional<StyleProperty> parse_as_supports_condition();
LibWeb: Bring "parse a list of declarations" closer to spec The work to create a PropertyOwningCSSStyleDeclaration is now moved to convert_to_style_declaration() instead.
2022-03-28 16:37:54 +01:00
LibWeb: Parse forgiving selector-lists `<forgiving-selector-list>` and `<forgiving-relative-selector-list>` are the same as regular selector-lists, except that an invalid selector does not make the whole list invalid. The former is used by the `:is()` pseudo-class. For example: ```css /* This entire selector-list is invalid */ .foo, .bar, !?invalid { } /* This is valid, but the "!?invalid" selector is removed */ :is(.foo, .bar, !?invalid) { } ``` Also as part of this, I've removed the `parse_a_selector(TokenStream)` and `parse_a_relative_selector(TokenStream)` methods as they don't add anything useful.
2022-03-17 15:14:01 +00:00
enum class SelectorParsingMode {
Standard,
// `<forgiving-selector-list>` and `<forgiving-relative-selector-list>`
// are handled with this parameter, not as separate functions.
// https://drafts.csswg.org/selectors/#forgiving-selector
Forgiving
};
LibWeb: Implement CSS selector parsing entry points They're still using the same parsing code, so there's a lot of room for improvement, but it's good for now.
2021-07-03 12:34:25 +01:00
// Contrary to the name, these parse a comma-separated list of selectors, according to the spec.
LibWeb: Parse forgiving selector-lists `<forgiving-selector-list>` and `<forgiving-relative-selector-list>` are the same as regular selector-lists, except that an invalid selector does not make the whole list invalid. The former is used by the `:is()` pseudo-class. For example: ```css /* This entire selector-list is invalid */ .foo, .bar, !?invalid { } /* This is valid, but the "!?invalid" selector is removed */ :is(.foo, .bar, !?invalid) { } ``` Also as part of this, I've removed the `parse_a_selector(TokenStream)` and `parse_a_relative_selector(TokenStream)` methods as they don't add anything useful.
2022-03-17 15:14:01 +00:00
Optional<SelectorList> parse_as_selector(SelectorParsingMode = SelectorParsingMode::Standard);
Optional<SelectorList> parse_as_relative_selector(SelectorParsingMode = SelectorParsingMode::Standard);
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
Optional<Selector::PseudoElementSelector> parse_as_pseudo_element_selector();
LibWeb/CSS: Add quick-and-dirty parsing for pseudo-element selectors As noted, this is hacky because the parser wasn't written to allow parsing an individual component of a selector. (Fox example, the convenient-sounding `parse_pseudo_simple_selector()` assumes the first colon has already been consumed...) So until that changes, this parses the input as an entire selector-list, and then throws it away if it's not a single pseudo-element selector. It's only temporary though, I promise. 😅
2024-08-06 12:44:43 +01:00
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<MediaQuery>> parse_as_media_query_list();
LibWeb: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 12:56:37 +01:00
RefPtr<MediaQuery> parse_as_media_query();
LibWeb: Parse CSS `Supports` ... according to https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition This works very similarly to `@media`, but is different enough to require its own parsing. (Though, the draft of Conditional-4 currently mentions combining the two into a `@when` rule.) Made some small changes to parsing code to make this work. Notably, making `consume_a_declaration()` fail gracefully instead of `VERIFY()`ing.
2021-10-08 15:54:16 +01:00
RefPtr<Supports> parse_as_supports();
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_as_css_value(PropertyID);
LibWeb: Implement CSS parsing convenience functions These mostly match the API in `DeprecatedCSSParser.h`. The exception is that `parse_selector()` returns a `SelectorList` instead of just one `Selector`. The only uses of that are in `ParentNode::query_selector[_all]()` which should be matching against a list, according to the spec. `parse_html_length()` is an odd case. It's used for `width="200"` cases in HTML, so is not really CSS related, but does produce a StyleValue. The values allowed in `width/height` in HTML vary per element, but they are a lot more restricted than in CSS, so it's slightly inappropriate to use the CSS parser for them, even though it's convenient. We also ignore a few functions: - `parse_line_width()` - `parse_line_style()` - `parse_color()` These are all only used in `StyleResolver`, when it is given a property value as a String. That won't happen once the old parser is removed.
2021-07-30 17:48:23 +01:00
LibWeb: Implement attr() types :^) Support the optional `<attr-type>` parameter to the `attr()` function, which allows parsing the attribute's value as a variety of types, instead of always as a string.
2023-09-04 12:57:12 +01:00
Optional<ComponentValue> parse_as_component_value();
LibWeb: Support loading FontFaces constructed with binary data
2024-05-13 12:02:38 -06:00
Vector<ParsedFontFace::Source> parse_as_font_face_src();
LibWeb: Implement more IntersectionObserver attributes
2024-11-22 12:01:42 +01:00
Vector<ComponentValue> parse_as_list_of_component_values();
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
static NonnullRefPtr<CSSStyleValue> resolve_unresolved_style_value(ParsingParams const&, DOM::Element&, Optional<PseudoElement>, PropertyID, UnresolvedStyleValue const&);
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
LibWeb: Bring parse_as_sizes_attribute() up to date with the spec The following spec algorithms had changed since we implemented them: - "parse a sizes attribute" - "update the source set" - "create a source set" This commit brings them up to date, as well as adding some additional logging when parsing the sizes attribute fails in some way.
2024-09-11 16:41:18 +01:00
[[nodiscard]] LengthOrCalculated parse_as_sizes_attribute(DOM::Element const& element, HTML::HTMLImageElement const* img = nullptr);
LibWeb: Add a class to represent the "source set" concept from HTML Also comes with a little extra CSS parser helper for parsing "sizes" attributes in images.
2023-05-11 16:56:01 +02:00
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
private:
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
Parser(ParsingParams const&, Vector<Token>);
LibWeb: Propagate errors from CSS Parser construction This requires Parser to be movable, so we remove the `default` destructors from Parser and TokenStream, and give them both move constructors. Since TokenStream only holds a reference to its tokens, (and it needs to, to avoid copying when given eg a function's contents,) we add a manual move constructor for Parser which creates a new TokenStream from the new Parser's tokens, and then manually copies the old TokenStream's state.
2023-03-06 17:17:08 +00:00
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
enum class ParseError {
LibWeb: Ignore vendor-prefixed pseudo-element/classes in selectors Our debug logging when we fail to parse a legitimate selector, is less useful when it's hidden among selectors that don't parse because they contain vendor-prefixed pseudo-elements and classes. So, now we specifically ignore these and don't produce a log message.
2021-09-12 17:47:58 +01:00
IncludesIgnoredVendorPrefix,
LibWeb: Propagate errors when parsing StyleValues This necessitated returning `nullptr` instead of just `{}` in a lot of places. Also, some temporary hackiness in `parse_css_value()`: That returns a special `ParseError` type already, so we now have a `FIXME_TRY()` macro which logs the error and then returns a generic `ParseError::InternalError` value. Eventually this macro will go away, once I figure out how to deal with this more nicely.
2023-05-02 13:03:51 +01:00
InternalError,
LibWeb: Return SelectorParsingResult from all selector parsing functions This will allow us to know why a selector failed to parse, in situations where that matters. (Like, when a selector includes vendor prefixes...)
2021-09-12 17:42:11 +01:00
SyntaxError,
};
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
template<typename T>
using ParseErrorOr = ErrorOr<T, ParseError>;
LibWeb: Return SelectorParsingResult from all selector parsing functions This will allow us to know why a selector failed to parse, in situations where that matters. (Like, when a selector includes vendor prefixes...)
2021-09-12 17:42:11 +01:00
LibWeb: Implement and use "parse a CSS stylesheet" algorithm `parse_a_stylesheet()` should not do any conversion on its rules. This change corrects that. There are other places where we get this wrong, but one thing at a time. :^)
2022-03-29 14:13:39 +01:00
// "Parse a stylesheet" is intended to be the normal parser entry point, for parsing stylesheets.
struct ParsedStyleSheet {
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
Optional<URL::URL> location;
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Vector<Rule> rules;
LibWeb: Implement and use "parse a CSS stylesheet" algorithm `parse_a_stylesheet()` should not do any conversion on its rules. This change corrects that. There are other places where we get this wrong, but one thing at a time. :^)
2022-03-29 14:13:39 +01:00
};
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
ParsedStyleSheet parse_a_stylesheet(TokenStream<T>&, Optional<URL::URL> location);
LibWeb: Implement and use "parse a CSS stylesheet" algorithm `parse_a_stylesheet()` should not do any conversion on its rules. This change corrects that. There are other places where we get this wrong, but one thing at a time. :^)
2022-03-29 14:13:39 +01:00
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
// "Parse a stylesheet’s contents" is intended for use by the CSSStyleSheet replace() method, and similar, which parse text into the contents of an existing stylesheet.
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Vector<Rule> parse_a_stylesheets_contents(TokenStream<T>&);
// "Parse a block’s contents" is intended for parsing the contents of any block in CSS (including things like the style attribute),
// and APIs such as the CSSStyleDeclaration cssText attribute.
template<typename T>
Vector<RuleOrListOfDeclarations> parse_a_blocks_contents(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_rule()` We now correctly call convert_to_rule() outside of this function. As before, I've renamed `parse_as_rule()` -> `parse_as_css_rule()` to match the free function that calls it.
2022-03-30 11:48:54 +01:00
// "Parse a rule" is intended for use by the CSSStyleSheet#insertRule method, and similar functions which might exist, which parse text into a single rule.
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Optional<Rule> parse_a_rule(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_rule()` We now correctly call convert_to_rule() outside of this function. As before, I've renamed `parse_as_rule()` -> `parse_as_css_rule()` to match the free function that calls it.
2022-03-30 11:48:54 +01:00
LibWeb: Bring `parse_a_declaration()` to spec and add comments User code now calls `parse_as_supports_condition()` which actually does the conversion to a StyleProperty.
2022-03-30 12:05:16 +01:00
// "Parse a declaration" is used in @supports conditions. [CSS3-CONDITIONAL]
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 14:36:12 +01:00
Optional<Declaration> parse_a_declaration(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_declarations()` The `parse_as_list_of_declarations()` public method is unused and will not be used by any user code so has been removed.
2022-03-30 12:23:07 +01:00
LibWeb: Spec-comment `parse_a_component_value()`
2022-03-30 12:32:42 +01:00
// "Parse a component value" is for things that need to consume a single value, like the parsing rules for attr().
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<ComponentValue> parse_a_component_value(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_component_values()`
2022-03-30 12:39:36 +01:00
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
// "Parse a list of component values" is for the contents of presentational attributes, which parse text into a single declaration’s value,
// or for parsing a stand-alone selector [SELECT] or list of Media Queries [MEDIAQ], as in Selectors API or the media HTML attribute.
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Vector<ComponentValue> parse_a_list_of_component_values(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_component_values()`
2022-03-30 12:39:36 +01:00
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Vector<Vector<ComponentValue>> parse_a_comma_separated_list_of_component_values(TokenStream<T>&);
LibWeb: Combine identical relative/regular selector parsing functions
2022-03-17 19:29:40 +00:00
enum class SelectorType {
Standalone,
Relative
};
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
ParseErrorOr<SelectorList> parse_a_selector_list(TokenStream<T>&, SelectorType, SelectorParsingMode = SelectorParsingMode::Standard);
LibWeb: Combine identical relative/regular selector parsing functions
2022-03-17 19:29:40 +00:00
LibWeb: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 12:56:37 +01:00
template<typename T>
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<MediaQuery>> parse_a_media_query_list(TokenStream<T>&);
LibWeb: Parse CSS `Supports` ... according to https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition This works very similarly to `@media`, but is different enough to require its own parsing. (Though, the draft of Conditional-4 currently mentions combining the two into a `@when` rule.) Made some small changes to parsing code to make this work. Notably, making `consume_a_declaration()` fail gracefully instead of `VERIFY()`ing.
2021-10-08 15:54:16 +01:00
template<typename T>
RefPtr<Supports> parse_a_supports(TokenStream<T>&);
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
LibWeb: Handle trailing tokens outside of parse_a_n_plus_b_pattern() parse_a_n_plus_b_pattern()'s job is to parse as much of the TokenStream as it can as a An+B, and then stop. The caller can then deal with any trailing tokens as it wishes.
2022-04-27 12:03:42 +01:00
Optional<Selector::SimpleSelector::ANPlusBPattern> parse_a_n_plus_b_pattern(TokenStream<ComponentValue>&);
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
template<typename T>
[[nodiscard]] Vector<Rule> consume_a_stylesheets_contents(TokenStream<T>&);
enum class Nested {
LibWeb: Use an enum class for the "top-level flag"
2022-03-29 13:46:16 +01:00
No,
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Yes,
LibWeb: Use an enum class for the "top-level flag"
2022-03-29 13:46:16 +01:00
};
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Optional<AtRule> consume_an_at_rule(TokenStream<T>&, Nested nested = Nested::No);
struct InvalidRuleError { };
template<typename T>
Variant<Empty, QualifiedRule, InvalidRuleError> consume_a_qualified_rule(TokenStream<T>&, Optional<Token::Type> stop_token = {}, Nested = Nested::No);
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Vector<RuleOrListOfDeclarations> consume_a_block(TokenStream<T>&);
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Vector<RuleOrListOfDeclarations> consume_a_blocks_contents(TokenStream<T>&);
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
Optional<Declaration> consume_a_declaration(TokenStream<T>&, Nested = Nested::No);
LibWeb: Implement and use `parse_a_style_blocks_contents()`
2022-03-30 16:44:13 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
void consume_the_remnants_of_a_bad_declaration(TokenStream<T>&, Nested);
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
[[nodiscard]] Vector<ComponentValue> consume_a_list_of_component_values(TokenStream<T>&, Optional<Token::Type> stop_token = {}, Nested = Nested::No);
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
[[nodiscard]] ComponentValue consume_a_component_value(TokenStream<T>&);
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb: Stop allocating `Token`s and `ComponentValue`s unnecessarily When the "Consume a component value from input, and do nothing." step in `Parser::consume_the_remnants_of_a_bad_declaration` was executed, it would allocate a `ComponentValue` that was then immediately discarded. Add explicitly `{}_and_do_nothing` functions for this case that never allocate a `ComponentValue` in the first place. Also remove a `(Token)` cast, which was unnecessarily copying a `Token` as well.
2024-11-30 18:31:04 +01:00
void consume_a_component_value_and_do_nothing(TokenStream<T>&);
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
SimpleBlock consume_a_simple_block(TokenStream<Token>&);
void consume_a_simple_block_and_do_nothing(TokenStream<Token>&);
Function consume_a_function(TokenStream<Token>&);
void consume_a_function_and_do_nothing(TokenStream<Token>&);
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
// TODO: consume_a_unicode_range_value()
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +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
OwnPtr<GeneralEnclosed> parse_general_enclosed(TokenStream<ComponentValue>&, MatchResult);
LibWeb: Parse CSS `Supports` ... according to https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition This works very similarly to `@media`, but is different enough to require its own parsing. (Though, the draft of Conditional-4 currently mentions combining the two into a `@when` rule.) Made some small changes to parsing code to make this work. Notably, making `consume_a_declaration()` fail gracefully instead of `VERIFY()`ing.
2021-10-08 15:54:16 +01:00
LibWeb: Support loading FontFaces constructed with binary data
2024-05-13 12:02:38 -06:00
template<typename T>
Vector<ParsedFontFace::Source> parse_font_face_src(TokenStream<T>&);
LibWeb: Parse `@font-face` rules This is very limited for now, only caring about `font-family` and `src`.
2022-03-28 20:32:28 +01:00
LibWeb/CSS: Parse `@layer` rules This causes us to pass all of http://wpt.live/css/css-cascade/parsing/layer.html :^)
2024-09-03 13:18:18 +01:00
enum class AllowBlankLayerName {
No,
Yes,
};
Optional<FlyString> parse_layer_name(TokenStream<ComponentValue>&, AllowBlankLayerName);
LibWeb/CSS: Reject invalid rules and declarations during parsing This implements the `is_valid_in_the_current_context()` methods by maintaining a stack of contexts, such as whether we're inside a style rule, or an `@media` block, or the condition of a `@supports` rule.
2024-11-01 14:46:35 +00:00
bool is_valid_in_the_current_context(Declaration const&) const;
bool is_valid_in_the_current_context(AtRule const&) const;
bool is_valid_in_the_current_context(QualifiedRule const&) const;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<CSSRule> convert_to_rule(Rule const&, Nested);
GC::Ptr<CSSStyleRule> convert_to_style_rule(QualifiedRule const&, Nested);
GC::Ptr<CSSFontFaceRule> convert_to_font_face_rule(AtRule const&);
GC::Ptr<CSSKeyframesRule> convert_to_keyframes_rule(AtRule const&);
GC::Ptr<CSSImportRule> convert_to_import_rule(AtRule const&);
GC::Ptr<CSSRule> convert_to_layer_rule(AtRule const&, Nested);
GC::Ptr<CSSMediaRule> convert_to_media_rule(AtRule const&, Nested);
GC::Ptr<CSSNamespaceRule> convert_to_namespace_rule(AtRule const&);
GC::Ptr<CSSSupportsRule> convert_to_supports_rule(AtRule const&, Nested);
GC::Ptr<CSSPropertyRule> convert_to_property_rule(AtRule const& rule);
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
LibWeb/CSS: Return GC::Ref from Parser::convert_to_style_declaration()
2025-03-18 13:41:46 +00:00
GC::Ref<CSSStyleProperties> convert_to_style_declaration(Vector<Declaration> const&);
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 14:36:12 +01:00
Optional<StyleProperty> convert_to_style_property(Declaration const&);
LibWeb: Convert CSS::Parser methods to return desired types This is very much stubbed out for now. Most notably is Parser::convert_rule() where most of the conversion will happen from the parser's internal rule classes to CSSRule and its children.
2021-07-09 16:34:29 +01:00
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<Dimension> parse_dimension(ComponentValue const&);
LibWeb: Implement helpers for parsing CSS numeric types Frequently we want to parse "anything that's a `<length-percentage>`" or similar, which could be a constant value or a calculation, but didn't have a nice way of doing so. That meant repeating the same "try and parse a dimension, see if it's the right type, then maybe try and parse a calculation and see if that's the right type" boilerplate code. Or more often, forgetting about calculations entirely. These helpers should make that a lot more convenient to do. And they also use TokenStream, so we can eventually drop the old `parse_length()` method.
2023-12-28 12:43:38 +00:00
Optional<AngleOrCalculated> parse_angle(TokenStream<ComponentValue>&);
Optional<AnglePercentage> parse_angle_percentage(TokenStream<ComponentValue>&);
Optional<FlexOrCalculated> parse_flex(TokenStream<ComponentValue>&);
Optional<FrequencyOrCalculated> parse_frequency(TokenStream<ComponentValue>&);
Optional<FrequencyPercentage> parse_frequency_percentage(TokenStream<ComponentValue>&);
Optional<IntegerOrCalculated> parse_integer(TokenStream<ComponentValue>&);
Optional<LengthOrCalculated> parse_length(TokenStream<ComponentValue>&);
Optional<LengthPercentage> parse_length_percentage(TokenStream<ComponentValue>&);
Optional<NumberOrCalculated> parse_number(TokenStream<ComponentValue>&);
LibWeb: Allow calculated values in css filters
2024-10-31 12:29:03 +11:00
Optional<NumberPercentage> parse_number_percentage(TokenStream<ComponentValue>&);
LibWeb: Implement helpers for parsing CSS numeric types Frequently we want to parse "anything that's a `<length-percentage>`" or similar, which could be a constant value or a calculation, but didn't have a nice way of doing so. That meant repeating the same "try and parse a dimension, see if it's the right type, then maybe try and parse a calculation and see if that's the right type" boilerplate code. Or more often, forgetting about calculations entirely. These helpers should make that a lot more convenient to do. And they also use TokenStream, so we can eventually drop the old `parse_length()` method.
2023-12-28 12:43:38 +00:00
Optional<ResolutionOrCalculated> parse_resolution(TokenStream<ComponentValue>&);
Optional<TimeOrCalculated> parse_time(TokenStream<ComponentValue>&);
Optional<TimePercentage> parse_time_percentage(TokenStream<ComponentValue>&);
LibWeb: Convert parse_source_size_value() to TokenStream
2023-12-30 17:06:14 +00:00
Optional<LengthOrCalculated> parse_source_size_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<Ratio> parse_ratio(TokenStream<ComponentValue>&);
LibWeb+LibGfx: Move UnicodeRange from LibWeb to LibGfx In upcoming changes UnicodeRange is going to be used in LibGfx in a class that represents font cascade list.
2023-12-09 23:30:01 +01:00
Optional<Gfx::UnicodeRange> parse_unicode_range(TokenStream<ComponentValue>&);
Optional<Gfx::UnicodeRange> parse_unicode_range(StringView);
LibWeb: Move CSS unicode-ranges parsing code into a common helper
2024-05-09 14:02:52 -06:00
Vector<Gfx::UnicodeRange> parse_unicode_ranges(TokenStream<ComponentValue>&);
LibWeb/CSS: Implement UnicodeRangeStyleValue This is preparation for storing at-rule descriptors as style values.
2025-03-27 17:35:06 +00:00
RefPtr<UnicodeRangeStyleValue> parse_unicode_range_value(TokenStream<ComponentValue>&);
LibWeb: Refactor GridTrackSize classes Refactor various classes in the GridTrackSize file for the incoming named_tracks feature. Previously the ExplicitTrackSizing had mixed responsiblities with the newly-named GridRepeat class. This made it so it was not possible to have multiple repeats within a single 'GridTrackSizeList' definition. The MetaGridTrackSize class had both the responsibilities of being a container for minmax values as well as for simple GridSizes. By uniting the different possible values (repeat, minmax, default) into the ExplicitGridTrack class are able to be more expressive as to the different grid size modalities. The GridTrackSizeList will be useful as compared to a Vector<ExplicitGridTrack> since this way can keep track of the declared line names. These same line names are able to be declared within the values of a repeat function, hence the presence of a GridTrackSizeList inside the GridRepeat class.
2022-10-30 13:27:57 +01:00
Optional<GridSize> parse_grid_size(ComponentValue const&);
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 18:16:36 +01:00
Optional<GridFitContent> parse_grid_fit_content(Vector<ComponentValue> const&);
LibWeb: Refactor GridTrackSize classes Refactor various classes in the GridTrackSize file for the incoming named_tracks feature. Previously the ExplicitTrackSizing had mixed responsiblities with the newly-named GridRepeat class. This made it so it was not possible to have multiple repeats within a single 'GridTrackSizeList' definition. The MetaGridTrackSize class had both the responsibilities of being a container for minmax values as well as for simple GridSizes. By uniting the different possible values (repeat, minmax, default) into the ExplicitGridTrack class are able to be more expressive as to the different grid size modalities. The GridTrackSizeList will be useful as compared to a Vector<ExplicitGridTrack> since this way can keep track of the declared line names. These same line names are able to be declared within the values of a repeat function, hence the presence of a GridTrackSizeList inside the GridRepeat class.
2022-10-30 13:27:57 +01:00
Optional<GridMinMax> parse_min_max(Vector<ComponentValue> const&);
Optional<GridRepeat> parse_repeat(Vector<ComponentValue> const&);
Optional<ExplicitGridTrack> parse_track_sizing_function(ComponentValue const&);
LibWeb: Support parsing some data: URLs in CSS For now, data URLs are explicitly limited to expected MIME types. For example, image-related styles accept image MIME types.
2021-10-29 08:38:50 -04:00
LibWeb/CSS: Parse url() functions with TokenStream
2024-08-09 13:36:11 +01:00
Optional<URL::URL> parse_url_function(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_url_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
LibWeb: Implement missing basic shapes
2024-10-27 11:58:52 +11:00
Optional<ShapeRadius> parse_shape_radius(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_basic_shape_value(TokenStream<ComponentValue>&);
LibWeb: Parse the `polygon()` basic shape function
2024-05-26 00:20:09 +01:00
LibWeb: Parse CSS fit-content(<length-percentage>) values Before this change, we only parsed fit-content as a standalone keyword, but CSS-SIZING-3 added it as a function as well. I don't know of anything else in CSS that is overloaded like this, so it ends up looking a little awkward in the implementation. Note that a lot of code had already been prepped for fit-content values to have an argument, we just weren't parsing it.
2025-02-26 18:16:36 +01:00
RefPtr<FitContentStyleValue> parse_fit_content_value(TokenStream<ComponentValue>&);
LibWeb: Make parse_color_stop_list() a CSS Parser method This lets us remove the color/dimension-parsing lambdas, since these always forwarded to the same methods. This will make it easier to later convert those methods to take a TokenStream.
2023-12-27 11:48:36 +00:00
template<typename TElement>
LibWeb/CSS: Parse gradient color stop positions directly Rather than parsing a generic dimension and then converting it, just parse the one we want to begin with.
2025-01-06 16:30:33 +00:00
Optional<Vector<TElement>> parse_color_stop_list(TokenStream<ComponentValue>& tokens, auto parse_position);
LibWeb: Move color stop list parsing to standalone functions This makes these slightly less clunky to use for other gradient types.
2022-11-08 21:33:00 +01:00
Optional<Vector<LinearColorStopListElement>> parse_linear_color_stop_list(TokenStream<ComponentValue>&);
Optional<Vector<AngularColorStopListElement>> parse_angular_color_stop_list(TokenStream<ComponentValue>&);
LibWeb: Implement css gradient-interpolation-method
2025-02-19 21:02:12 +11:00
Optional<InterpolationMethod> parse_interpolation_method(TokenStream<ComponentValue>&);
LibWeb: Move color stop list parsing to standalone functions This makes these slightly less clunky to use for other gradient types.
2022-11-08 21:33:00 +01:00
LibWeb/CSS: Clarify types of image-parsing methods parse_image_value() always returns some kind of AbstractImageStyleValue.
2025-02-17 17:11:02 +00:00
RefPtr<LinearGradientStyleValue> parse_linear_gradient_function(TokenStream<ComponentValue>&);
RefPtr<ConicGradientStyleValue> parse_conic_gradient_function(TokenStream<ComponentValue>&);
RefPtr<RadialGradientStyleValue> parse_radial_gradient_function(TokenStream<ComponentValue>&);
LibWeb: Parse the linear-gradient() CSS function This should parse linear-gradient()s as defined in the W3 spec https://drafts.csswg.org/css-images/#linear-gradients. Note: This currently cannot parse multi-position color stops, these are shown on MDN and work in Firefox and Chrome, though do not seem to be defined in the spec. See: https://developer.mozilla.org/en-US/docs/Web/CSS/gradient/linear-gradient#gradient_with_multi-position_color_stops P.s. This also allows -webkit-linear-gradient for compatibility.
2022-07-12 00:15:05 +01:00
LibWeb/CSS: Preserve whitespace and comments in custom properties A couple of parts of this: - Store the source text for Declarations of custom properties. - Then save that in the UnresolvedStyleValue. - Serialize UnresolvedStyleValue using the saved source when available - that is, for custom properties but not for regular properties that include var() or attr().
2024-10-14 16:23:35 +01:00
ParseErrorOr<NonnullRefPtr<CSSStyleValue>> parse_css_value(PropertyID, TokenStream<ComponentValue>&, Optional<String> original_source_text = {});
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_css_value_for_property(PropertyID, TokenStream<ComponentValue>&);
LibWeb: Implement smarter CSS StyleValue parsing We know what types and identifiers a property can accept, so we can use that information to only parse things that can be accepted. This solves some awkward ambiguity problems that we have now or will face in the future, including: - Is `0` a number or a length with no unit? - Is `3.5` a number or a ratio? - Is `bottom` an identifier, or a custom-ident? Two CSS Parser methods are introduced here: `parse_css_value_for_property()` attempts to parse a StyleValue that the property can accept, skipping any types that it doesn't want. `parse_css_value_for_properties()` does the same, but takes multiple PropertyIDs and additionally returns which one the parsed StyleValue is for. This is intended for parsing shorthands, so you can give it a list of longhands you haven't yet parsed. Subsequent commits will actually use these new methods.
2023-05-17 17:23:42 +01:00
struct PropertyAndValue {
PropertyID property;
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> style_value;
LibWeb: Implement smarter CSS StyleValue parsing We know what types and identifiers a property can accept, so we can use that information to only parse things that can be accepted. This solves some awkward ambiguity problems that we have now or will face in the future, including: - Is `0` a number or a length with no unit? - Is `3.5` a number or a ratio? - Is `bottom` an identifier, or a custom-ident? Two CSS Parser methods are introduced here: `parse_css_value_for_property()` attempts to parse a StyleValue that the property can accept, skipping any types that it doesn't want. `parse_css_value_for_properties()` does the same, but takes multiple PropertyIDs and additionally returns which one the parsed StyleValue is for. This is intended for parsing shorthands, so you can give it a list of longhands you haven't yet parsed. Subsequent commits will actually use these new methods.
2023-05-17 17:23:42 +01:00
};
LibWeb: Make parse_css_value_for_properties() return Optional Signalling failure with a null `PropertyAndValue::style_value` is weird.
2023-08-19 15:26:57 +01:00
Optional<PropertyAndValue> parse_css_value_for_properties(ReadonlySpan<PropertyID>, TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_builtin_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Simplify calculations after parsing them If a calculation was simplified down to a single numeric node, then most of the time we can instead return a regular StyleValue, for example `calc(2px + 3px)` would be simplified down to a `5px` LengthStyleValue. This means that parse_calculated_value() can't return a CalculatedStyleValue directly, and its callers all have to handle non-calculated values as well as calculated ones. This simplification is reflected in the new test results. Serialization is not yet correct in all cases but we're closer than we were. :^)
2025-01-28 16:24:39 +00:00
RefPtr<CSSStyleValue> parse_calculated_value(ComponentValue const&);
LibWeb/CSS: Add method for parsing `<custom-ident>` directly We specifically want to parse one inside a selector, where we only care about the string itself and don't want a whole style value.
2025-03-24 13:44:05 +00:00
Optional<FlyString> parse_custom_ident(TokenStream<ComponentValue>&, ReadonlySpan<StringView> blacklist);
LibWeb/CSS: Take custom-ident blacklist as a Span Using std::initializer_list here was a bit of a hack, and makes it awkward to pass those blacklists around.
2025-02-25 11:46:52 +00:00
RefPtr<CustomIdentStyleValue> parse_custom_ident_value(TokenStream<ComponentValue>&, ReadonlySpan<StringView> blacklist);
LibWeb: Generate parsing code for CSS math functions
2023-07-13 14:59:31 +01:00
// NOTE: Implemented in generated code. (GenerateCSSMathFunctions.cpp)
LibWeb/CSS: Make CalculationNodes ref-counted Calc simplification (which I'm working towards) involves repeatedly deriving a new calculation tree from an existing one, and in many cases, either the whole result or a portion of it will be identical to that of the original. Using RefPtr lets us avoid making unnecessary copies. As a bonus it will also make it easier to return either `this` or a new node. In future we could also cache commonly-used nodes, similar to how we do so for 1px and 0px LengthStyleValues and various keywords.
2025-01-22 16:50:54 +00:00
RefPtr<CalculationNode> parse_math_function(Function const&, CalculationContext const&);
RefPtr<CalculationNode> parse_a_calc_function_node(Function const&, CalculationContext const&);
LibWeb: Rename "identifier" and "ValueID" to "Keyword" where correct For a long time, we've used two terms, inconsistently: - "Identifier" is a spec term, but refers to a sequence of alphanumeric characters, which may or may not be a keyword. (Keywords are a subset of all identifiers.) - "ValueID" is entirely non-spec, and is directly called a "keyword" in the CSS specs. So to avoid confusion as much as possible, let's align with the spec terminology. I've attempted to change variable names as well, but obviously we use Keywords in a lot of places in LibWeb and so I may have missed some. One exception is that I've not renamed "valid-identifiers" in Properties.json... I'd like to combine that and the "valid-types" array together eventually, so there's no benefit to doing an extra rename now.
2024-08-14 14:06:03 +01:00
RefPtr<CSSStyleValue> parse_keyword_value(TokenStream<ComponentValue>&);
LibWeb: Parse the keyword 'none' in the CSS4 color functions This updates the CSS parser to support the keyword 'none' in the CSS4 color functions. The underlying CSSColorValue already supports this keyword, meaning the parser can instantiate the color directly.
2024-11-03 11:46:05 +01:00
RefPtr<CSSStyleValue> parse_hue_none_value(TokenStream<ComponentValue>&);
LibWeb: Introduce color-function-specific style values Instead of CSSColorValue holding a Gfx::Color, make it an abstract class with subclasses for each different color function, to match the Typed-OM spec. This means moving the color calculations from the parsing code to the `to_color()` method on the style value. This lets us have calc() inside a color function, instead of having to fully resolve the color at parse time. The canvas fillStyle tests have been updated to reflect this. The other test change is Screenshot/css-color-functions.html: previously we produced slightly different colors for an alpha of 0.5 and one of 50%, and this incorrect behavior was baked into the test. So now it's more correct. :^)
2024-08-16 16:42:16 +01:00
RefPtr<CSSStyleValue> parse_solidus_and_alpha_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_rgb_color_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_hsl_color_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_hwb_color_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Extract code to parse a lab-like color value This is currently only used for `oklab()` but will soon be also used for `lab()` as well.
2024-10-26 15:42:03 -04:00
Optional<Array<RefPtr<CSSStyleValue>, 4>> parse_lab_like_color_value(TokenStream<ComponentValue>&, StringView);
LibGfx+LibWeb/CSS: Add support for the `lab()` color function The support in LibWeb is quite easy as the previous commits introduced helpers to support lab-like colors. Now for the methods in Color: - The formulas in `from_lab()` are derived from the CIEXYZ to CIELAB formulas the "Colorimetry" paper published by the CIE. - The conversion in `from_xyz50()` can be decomposed in multiple steps XYZ D50 -> XYZ D65 -> Linear sRGB -> sRGB. The two first conversion are done with a singular matrix operation. This matrix was generated with a Python script [1]. This commit makes us pass all the `css/css-color/lab-00*.html` WPT tests (0 to 7 at the time of writing). [1] Python script used to generate the XYZ D50 -> Linear sRGB conversion: ```python import numpy as np # http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html # First let's convert from D50 to D65 using the Bradford method. m_a = np.array([ [0.8951000, 0.2664000, -0.1614000], [-0.7502000, 1.7135000, 0.0367000], [0.0389000, -0.0685000, 1.0296000] ]) # D50 chromaticities_source = np.array([0.96422, 1, 0.82521]) # D65 chromaticities_destination = np.array([0.9505, 1, 1.0890]) cone_response_source = m_a @ chromaticities_source cone_response_destination = m_a @ chromaticities_destination cone_response_ratio = cone_response_destination / cone_response_source m = np.linalg.inv(m_a) @ np.diagflat(cone_response_ratio) @ m_a D50_to_D65 = m # https://en.wikipedia.org/wiki/SRGB#From_CIE_XYZ_to_sRGB # Then, the matrix to convert to linear sRGB. xyz_65_to_srgb = np.array([ [3.2406, - 1.5372, - 0.4986], [-0.9689, + 1.8758, 0.0415], [0.0557, - 0.2040, 1.0570] ]) # Finally, let's retrieve the final transformation. xyz_50_to_srgb = xyz_65_to_srgb @ D50_to_D65 print(xyz_50_to_srgb) ```
2024-10-26 17:16:13 -04:00
RefPtr<CSSStyleValue> parse_lab_color_value(TokenStream<ComponentValue>&);
LibWeb: Introduce color-function-specific style values Instead of CSSColorValue holding a Gfx::Color, make it an abstract class with subclasses for each different color function, to match the Typed-OM spec. This means moving the color calculations from the parsing code to the `to_color()` method on the style value. This lets us have calc() inside a color function, instead of having to fully resolve the color at parse time. The canvas fillStyle tests have been updated to reflect this. The other test change is Screenshot/css-color-functions.html: previously we produced slightly different colors for an alpha of 0.5 and one of 50%, and this incorrect behavior was baked into the test. So now it's more correct. :^)
2024-08-16 16:42:16 +01:00
RefPtr<CSSStyleValue> parse_oklab_color_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Factorize the parsing code for lch-like color functions
2024-10-27 19:49:25 -04:00
Optional<Array<RefPtr<CSSStyleValue>, 4>> parse_lch_like_color_value(TokenStream<ComponentValue>&, StringView);
LibWeb/CSS: Add support for the `lch` color function This makes us pass all `css/css-color/lch-00*.html` tests.
2024-10-27 20:19:10 -04:00
RefPtr<CSSStyleValue> parse_lch_color_value(TokenStream<ComponentValue>&);
LibWeb: Introduce color-function-specific style values Instead of CSSColorValue holding a Gfx::Color, make it an abstract class with subclasses for each different color function, to match the Typed-OM spec. This means moving the color calculations from the parsing code to the `to_color()` method on the style value. This lets us have calc() inside a color function, instead of having to fully resolve the color at parse time. The canvas fillStyle tests have been updated to reflect this. The other test change is Screenshot/css-color-functions.html: previously we produced slightly different colors for an alpha of 0.5 and one of 50%, and this incorrect behavior was baked into the test. So now it's more correct. :^)
2024-08-16 16:42:16 +01:00
RefPtr<CSSStyleValue> parse_oklch_color_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Start parsing the `color()` function This is really bare bone as we only support the `xyz-d50` color space for the moment. It makes us pass the following WPT tests: - css/css-color/predefined-016.html - css/css-color/xyz-d50-001.html - css/css-color/xyz-d50-002.html
2024-10-27 00:42:13 -04:00
RefPtr<CSSStyleValue> parse_color_function(TokenStream<ComponentValue>&);
LibWeb/CSS: Implement the light-dark color function
2025-01-05 09:51:58 +11:00
RefPtr<CSSStyleValue> parse_light_dark_color_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_color_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Implement the color-scheme CSS property
2025-01-02 12:59:09 +11:00
RefPtr<CSSStyleValue> parse_color_scheme_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_counter_value(TokenStream<ComponentValue>&);
LibWeb: Implement counter-[increment,reset,set] properties These control the state of CSS counters. Parsing code for `reversed(counter-name)` is implemented, but disabled for now until we are able to resolve values for those.
2024-07-24 15:47:11 +01:00
enum class AllowReversed {
No,
Yes,
};
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_counter_definitions_value(TokenStream<ComponentValue>&, AllowReversed, i32 default_value_if_not_reversed);
RefPtr<CSSStyleValue> parse_rect_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_ratio_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Return StringStyleValue from parse_string_value() Callers already relied on this being true, so let's make it contractual.
2024-09-30 14:10:27 +01:00
RefPtr<StringStyleValue> parse_string_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Clarify types of image-parsing methods parse_image_value() always returns some kind of AbstractImageStyleValue.
2025-02-17 17:11:02 +00:00
RefPtr<AbstractImageStyleValue> parse_image_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_paint_value(TokenStream<ComponentValue>&);
LibWeb: Merge background-position parsing into position code Implemented by adding the extra 3-value syntax as its own case and only running it when parsing background-position. I'm sure it could be implemented in a smarter way but this is still a bunch less code than before. :^)
2023-11-20 15:33:21 +00:00
enum class PositionParsingMode {
Normal,
BackgroundPosition,
};
RefPtr<PositionStyleValue> parse_position_value(TokenStream<ComponentValue>&, PositionParsingMode = PositionParsingMode::Normal);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_filter_value_list_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Add parsing for `<opentype-tag>` This is a special form of `<string>` so doesn't need its own style value type. It's used in a couple of font-related properties. For completeness it's included in ValueType.
2024-09-30 14:38:17 +01:00
RefPtr<StringStyleValue> parse_opentype_tag_value(TokenStream<ComponentValue>&);
LibWeb: Parse FilterValueListStyleValue using TokenStream
2023-12-07 15:16:51 +00:00
LibWeb/CSS: Introduce helper methods for parsing numeric values "Parse a style value for <foo>", where we don't care if it's a literal <foo> or a calculated one, is a really common thing that we previously didn't have methods for. A couple of methods we had have been extended to parse calc(), and the others have been filled in. The method for parsing the `flex` property's value is renamed `parse_flex_shorthand_value()` as it conflicted.
2024-08-16 09:41:10 +01:00
RefPtr<CSSStyleValue> parse_angle_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_angle_percentage_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_flex_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_frequency_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_frequency_percentage_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_integer_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_length_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_length_percentage_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_number_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_number_percentage_value(TokenStream<ComponentValue>& tokens);
LibWeb: Parse the keyword 'none' in the CSS4 color functions This updates the CSS parser to support the keyword 'none' in the CSS4 color functions. The underlying CSSColorValue already supports this keyword, meaning the parser can instantiate the color directly.
2024-11-03 11:46:05 +01:00
RefPtr<CSSStyleValue> parse_number_percentage_none_value(TokenStream<ComponentValue>& tokens);
LibWeb/CSS: Introduce helper methods for parsing numeric values "Parse a style value for <foo>", where we don't care if it's a literal <foo> or a calculated one, is a really common thing that we previously didn't have methods for. A couple of methods we had have been extended to parse calc(), and the others have been filled in. The method for parsing the `flex` property's value is renamed `parse_flex_shorthand_value()` as it conflicted.
2024-08-16 09:41:10 +01:00
RefPtr<CSSStyleValue> parse_percentage_value(TokenStream<ComponentValue>& tokens);
RefPtr<CSSStyleValue> parse_resolution_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_time_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_time_percentage_value(TokenStream<ComponentValue>&);
LibWeb: Parse comma-separated lists for most background properties We now can parse lists of values for these properties: - `background-attachment` - `background-clip` - `background-image` - `background-origin` - `background-position` - `background-repeat` - `background-size` This uses two new Parser methods: `parse_simple_comma_separated_value_list()` for the simple case when each value is parsed from a single token; and `parse_comma_separated_value_list()` which takes a lambda for when parsing each value is more involved. This also means that any unconsumed tokens at the end will make the parsing fail as it should, where previously we just ignored them.
2021-11-08 17:19:55 +00:00
template<typename ParseFunction>
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_comma_separated_value_list(TokenStream<ComponentValue>&, ParseFunction);
RefPtr<CSSStyleValue> parse_simple_comma_separated_value_list(PropertyID, TokenStream<ComponentValue>&);
LibWeb/CSS: Expand single-none-parsing helper to parse any keyword Multiple font properties are either the `normal` keyword or some non-keyword value, so this lets us avoid some boilerplate for those, at the cost of the existing `none` users having marginally more verbose code.
2024-09-30 15:17:01 +01:00
RefPtr<CSSStyleValue> parse_all_as_single_keyword_value(TokenStream<ComponentValue>&, Keyword);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_aspect_ratio_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_background_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_single_background_position_x_or_y_value(TokenStream<ComponentValue>&, PropertyID);
RefPtr<CSSStyleValue> parse_single_background_repeat_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_single_background_size_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_border_value(PropertyID, TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_border_radius_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_border_radius_shorthand_value(TokenStream<ComponentValue>&);
LibWeb: Support parsing columns
2024-08-21 11:09:08 -04:00
RefPtr<CSSStyleValue> parse_columns_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_content_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_counter_increment_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_counter_reset_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_counter_set_value(TokenStream<ComponentValue>&);
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
RefPtr<CSSStyleValue> parse_cursor_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_display_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Introduce helper methods for parsing numeric values "Parse a style value for <foo>", where we don't care if it's a literal <foo> or a calculated one, is a really common thing that we previously didn't have methods for. A couple of methods we had have been extended to parse calc(), and the others have been filled in. The method for parsing the `flex` property's value is renamed `parse_flex_shorthand_value()` as it conflicted.
2024-08-16 09:41:10 +01:00
RefPtr<CSSStyleValue> parse_flex_shorthand_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_flex_flow_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_font_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Split out `<family-name>` parsing This type is used individually elsewhere in the spec. This also lets us separate out the `<generic-family>` type.
2025-03-24 16:43:47 +00:00
RefPtr<CSSStyleValue> parse_family_name_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_font_family_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Parse and propagate the font-language-override property
2024-09-27 17:11:05 +01:00
RefPtr<CSSStyleValue> parse_font_language_override_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Parse and propagate font-feature-settings property
2024-10-01 09:37:43 +01:00
RefPtr<CSSStyleValue> parse_font_feature_settings_value(TokenStream<ComponentValue>&);
LibWeb/CSS: Parse and propagate font-variation-settings property
2024-10-01 09:20:06 +01:00
RefPtr<CSSStyleValue> parse_font_variation_settings_value(TokenStream<ComponentValue>&);
LibWeb: Parse font-variant-* css properties
2024-12-05 01:14:56 +01:00
RefPtr<CSSStyleValue> parse_font_variant(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_font_variant_alternates_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_font_variant_east_asian_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_font_variant_emoji(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_font_variant_ligatures_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_font_variant_numeric_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_list_style_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_math_depth_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_overflow_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_place_content_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_place_items_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_place_self_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_quotes_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_scrollbar_gutter_value(TokenStream<ComponentValue>&);
LibWeb: Implement disallowing `inset` when parsing shadows `text-shadow` does not support this, so this way we can still use the same parsing code. It's OK that we still assign a ShadowPlacement value to the ShadowStyleValue, since it will just get ignored when painting text-shadows, but if it appears in the property value then that is a syntax error.
2022-03-23 16:59:44 +00:00
enum class AllowInsetKeyword {
No,
Yes,
};
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_shadow_value(TokenStream<ComponentValue>&, AllowInsetKeyword);
RefPtr<CSSStyleValue> parse_single_shadow_value(TokenStream<ComponentValue>&, AllowInsetKeyword);
RefPtr<CSSStyleValue> parse_text_decoration_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_text_decoration_line_value(TokenStream<ComponentValue>&);
LibWeb: Parse the rotate css property
2024-10-16 08:50:35 +02:00
RefPtr<CSSStyleValue> parse_rotate_value(TokenStream<ComponentValue>&);
LibWeb: Plumbing for svg stroke-dasharray
2024-11-20 19:23:10 -05:00
RefPtr<CSSStyleValue> parse_stroke_dasharray_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_easing_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_transform_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_transform_origin_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_transition_value(TokenStream<ComponentValue>&);
LibWeb: Support individual `translate` CSS property
2024-11-22 16:42:20 +01:00
RefPtr<CSSStyleValue> parse_translate_value(TokenStream<ComponentValue>&);
LibWeb: Support individual `scale` CSS property
2024-11-22 18:07:16 +01:00
RefPtr<CSSStyleValue> parse_scale_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_grid_track_size_list(TokenStream<ComponentValue>&, bool allow_separate_line_name_blocks = false);
RefPtr<CSSStyleValue> parse_grid_auto_track_sizes(TokenStream<ComponentValue>&);
LibWeb: Parse grid-auto-flow property using TokenStream RefPtr is already `[[nodiscard]]` so we can remove that extra noise from the declaration.
2023-12-07 17:42:43 +00:00
RefPtr<GridAutoFlowStyleValue> parse_grid_auto_flow_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_grid_track_size_list_shorthand_value(PropertyID, TokenStream<ComponentValue>&);
LibWeb: Set correct longhand values when using grid-placement shorthand According to https://www.w3.org/TR/css-grid-2/#placement-shorthands when setting the 'grid-row' and 'grid-column' shorthand property to a single <custom-ident> value, both 'grid-row-start'/'grid-column-start' and 'grid-row-end'/'grid-column-end' should be set to that <custom_ident>.
2024-08-28 16:47:30 +02:00
RefPtr<GridTrackPlacementStyleValue> parse_grid_track_placement(TokenStream<ComponentValue>&);
LibWeb: Rename StyleValue -> CSSStyleValue This matches the name in the CSS Typed OM spec. https://drafts.css-houdini.org/css-typed-om-1/#cssstylevalue No behaviour changes.
2024-08-14 11:10:54 +01:00
RefPtr<CSSStyleValue> parse_grid_track_placement_shorthand_value(PropertyID, TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_grid_template_areas_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_grid_area_shorthand_value(TokenStream<ComponentValue>&);
RefPtr<CSSStyleValue> parse_grid_shorthand_value(TokenStream<ComponentValue>&);
LibWeb: Generate a ValueListStyleValue when parsing CSS values We skip whitespace tokens while doing this. As far as I can tell, whitespace is not useful once we get to this point, and it legally may or may not appear between any two tokens. By not including it in the ValueListStyleValue, we make the "if it has 3 parts"-type checks a lot more straightforward.
2021-07-14 16:20:06 +01:00
LibWeb/CSS: Make CalculationNodes ref-counted Calc simplification (which I'm working towards) involves repeatedly deriving a new calculation tree from an existing one, and in many cases, either the whole result or a portion of it will be identical to that of the original. Using RefPtr lets us avoid making unnecessary copies. As a bonus it will also make it easier to return either `this` or a new node. In future we could also cache commonly-used nodes, similar to how we do so for 1px and 0px LengthStyleValues and various keywords.
2025-01-22 16:50:54 +00:00
RefPtr<CalculationNode> convert_to_calculation_node(CalcParsing::Node const&, CalculationContext const&);
RefPtr<CalculationNode> parse_a_calculation(Vector<ComponentValue> const&, CalculationContext const&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
ParseErrorOr<NonnullRefPtr<Selector>> parse_complex_selector(TokenStream<ComponentValue>&, SelectorType);
ParseErrorOr<Optional<Selector::CompoundSelector>> parse_compound_selector(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<Selector::Combinator> parse_selector_combinator(TokenStream<ComponentValue>&);
LibWeb: Add SimpleSelector::QualifiedName, with parsing This is basically a name with a namespace prefix. It will be used for adding namespaces to Universal, TagName, and Attribute selectors. For convenience, this can also optionally parse/store the `*` wildcard character as the name.
2023-08-07 16:48:44 +01:00
enum class AllowWildcardName {
No,
Yes,
};
Optional<Selector::SimpleSelector::QualifiedName> parse_selector_qualified_name(TokenStream<ComponentValue>&, AllowWildcardName);
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
ParseErrorOr<Selector::SimpleSelector> parse_attribute_simple_selector(ComponentValue const&);
ParseErrorOr<Selector::SimpleSelector> parse_pseudo_simple_selector(TokenStream<ComponentValue>&);
ParseErrorOr<Optional<Selector::SimpleSelector>> parse_simple_selector(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
NonnullRefPtr<MediaQuery> parse_media_query(TokenStream<ComponentValue>&);
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
OwnPtr<BooleanExpression> parse_media_condition(TokenStream<ComponentValue>&);
OwnPtr<MediaFeature> parse_media_feature(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<MediaQuery::MediaType> parse_media_type(TokenStream<ComponentValue>&);
Optional<MediaFeatureValue> parse_media_feature_value(MediaFeatureID, TokenStream<ComponentValue>&);
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
using ParseTest = AK::Function<OwnPtr<BooleanExpression>(TokenStream<ComponentValue>&)> const&;
OwnPtr<BooleanExpression> parse_boolean_expression(TokenStream<ComponentValue>&, MatchResult result_for_general_enclosed, ParseTest parse_test);
OwnPtr<BooleanExpression> parse_boolean_expression_group(TokenStream<ComponentValue>&, MatchResult result_for_general_enclosed, ParseTest parse_test);
OwnPtr<BooleanExpression> parse_supports_feature(TokenStream<ComponentValue>&);
LibWeb: Parse CSS `Supports` ... according to https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition This works very similarly to `@media`, but is different enough to require its own parsing. (Though, the draft of Conditional-4 currently mentions combining the two into a `@when` rule.) Made some small changes to parsing code to make this work. Notably, making `consume_a_declaration()` fail gracefully instead of `VERIFY()`ing.
2021-10-08 15:54:16 +01:00
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
NonnullRefPtr<CSSStyleValue> resolve_unresolved_style_value(DOM::Element&, Optional<PseudoElement>, PropertyID, UnresolvedStyleValue const&);
bool expand_variables(DOM::Element&, Optional<PseudoElement>, FlyString const& property_name, HashMap<FlyString, NonnullRefPtr<PropertyDependencyNode>>& dependencies, TokenStream<ComponentValue>& source, Vector<ComponentValue>& dest);
LibWeb: Make CSS::string_from_property_id() return FlyString const& This avoids costly conversions from StringView to FlyString in CSS parsing and variable expansion.
2024-03-15 20:32:45 +01:00
bool expand_unresolved_values(DOM::Element&, FlyString const& property_name, TokenStream<ComponentValue>& source, Vector<ComponentValue>& dest);
bool substitute_attr_function(DOM::Element& element, FlyString const& property_name, Function const& attr_function, Vector<ComponentValue>& dest);
LibWeb: Move UnresolvedStyleValue resolution into the CSS Parser Resolving typed `attr()` functions is going to involve using more internal Parser methods, so this is the simplest solution for that. Also... resolving these is basically parsing them, so it makes more sense for that process to live here. This is just moving code, with minimal changes so it still works.
2023-09-04 11:16:49 +01:00
Everywhere: Pass AK::StringView by value
2021-11-11 00:55:02 +01:00
static bool has_ignored_vendor_prefix(StringView);
LibWeb: Ignore CSS properties with other people's vendor prefixes This removes some `Property '-webkit-foo' has no value.` log spam. :^)
2021-09-12 16:49:09 +01:00
LibWeb/CSS: Rewrite CSS Parser core methods according to new spec CSS Syntax 3 (https://drafts.csswg.org/css-syntax) has changed significantly since we implemented it a couple of years ago. Just about every parsing algorithm has been rewritten in terms of the new token stream concept, and to support nested styles. As all of those algorithms call into each other, this is an unfortunately chonky diff. As part of this, the transitory types (Declaration, Function, AtRule...) have been rewritten. That's both because we have new requirements of what they should be and contain, and also because the spec asks us to create and then gradually modify them in place, which is easier if they are plain structs.
2024-10-11 11:17:10 +01:00
PropertiesAndCustomProperties extract_properties(Vector<RuleOrListOfDeclarations> const&);
void extract_property(Declaration const&, Parser::PropertiesAndCustomProperties&);
LibWeb: Streamline how inline CSS style declarations are constructed When parsing the "style" attribute on elements, we'd previously ask the CSS parser for a PropertyOwningCSSStyleDeclaration. Then we'd create a new ElementCSSInlineStyleDeclaration and transfer the properties from the first object to the second object. This patch teaches the parser to make ElementCSSInlineStyleDeclaration objects directly.
2022-03-29 16:01:38 +02:00
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
DOM::Document const* document() const;
HTML::Window const* window() const;
JS::Realm& realm() const;
bool in_quirks_mode() const;
bool is_parsing_svg_presentation_attribute() const;
LibURL+LibWeb: Port URL::complete_url to Optional Removing one more source of the URL::is_valid API.
2025-02-15 22:55:46 +13:00
Optional<URL::URL> complete_url(StringView) const;
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
GC::Ptr<DOM::Document const> m_document;
GC::Ptr<JS::Realm> m_realm;
URL::URL m_url;
ParsingMode m_parsing_mode { ParsingMode::Normal };
LibWeb: Add context to new CSS parser, and deprecate the old one The new one is the same as the old one, just in the new Parser's source files. This isn't the most elegant solution but it seemed like the best option. And it's all temporary, after all.
2021-07-02 20:25:13 +01:00
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
Vector<Token> m_tokens;
LibWeb: Add TokenStream class to CSS Parser The entry points for CSS parsing in the spec are defined as accepting any of a stream of Tokens, or a stream of ComponentValues, or a String. TokenStream is an attempt to reduce the duplication of code for that.
2021-07-03 14:00:41 +01:00
TokenStream<Token> m_token_stream;
LibWeb/CSS: Reject invalid rules and declarations during parsing This implements the `is_valid_in_the_current_context()` methods by maintaining a stack of contexts, such as whether we're inside a style rule, or an `@media` block, or the condition of a `@supports` rule.
2024-11-01 14:46:35 +00:00
LibWeb/CSS: Replace Parser "current property" with a stack of contexts `current_property_id()` is insufficient to determine if a quirk is allowed. For example, unitless lengths are allowed in certain properties, but NOT if they are inside a calc() or other function. It's also incorrect when we are parsing a longhand inside a shorthand. So instead, replace that with a stack of value-parsing contexts. For now, this is either properties or CSS functions, but in future can be expanded to include media features and other places. This lets us disallow quirks inside functions, like we're supposed to. It also lays the groundwork for being able to more easily determine what type a percentage inside a calculation should become, as this is based on the same stack of contexts.
2025-01-06 12:48:17 +00:00
struct FunctionContext {
StringView name;
};
using ValueParsingContext = Variant<PropertyID, FunctionContext>;
Vector<ValueParsingContext> m_value_context;
auto push_temporary_value_parsing_context(ValueParsingContext&& context)
{
m_value_context.append(context);
return ScopeGuard { [&] { m_value_context.take_last(); } };
}
bool context_allows_quirky_length() const;
LibWeb/CSS: Reject invalid rules and declarations during parsing This implements the `is_valid_in_the_current_context()` methods by maintaining a stack of contexts, such as whether we're inside a style rule, or an `@media` block, or the condition of a `@supports` rule.
2024-11-01 14:46:35 +00:00
enum class ContextType {
Unknown,
Style,
AtMedia,
AtFontFace,
AtKeyframes,
Keyframe,
AtSupports,
SupportsCondition,
AtLayer,
AtProperty,
};
static ContextType context_type_for_at_rule(FlyString const&);
Vector<ContextType> m_rule_context;
LibWeb/CSS: Disallow :has() and pseudo-elements in :has() when parsing
2024-11-14 12:18:10 +00:00
Vector<PseudoClass> m_pseudo_class_context; // Stack of pseudo-class functions we're currently inside
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
};
}
LibWeb: Implement CSS parsing convenience functions These mostly match the API in `DeprecatedCSSParser.h`. The exception is that `parse_selector()` returns a `SelectorList` instead of just one `Selector`. The only uses of that are in `ParentNode::query_selector[_all]()` which should be matching against a list, according to the spec. `parse_html_length()` is an odd case. It's used for `width="200"` cases in HTML, so is not really CSS related, but does produce a StyleValue. The values allowed in `width/height` in HTML vary per element, but they are a lot more restricted than in CSS, so it's slightly inappropriate to use the CSS parser for them, even though it's convenient. We also ignore a few functions: - `parse_line_width()` - `parse_line_style()` - `parse_color()` These are all only used in `StyleResolver`, when it is given a property value as a String. That won't happen once the old parser is removed.
2021-07-30 17:48:23 +01:00
namespace Web {
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
CSS::CSSStyleSheet* parse_css_stylesheet(CSS::Parser::ParsingParams const&, StringView, Optional<URL::URL> location = {});
LibWeb: Stop constructing temporary ElementInlineCSSStyleDeclarations Previously, parse_css_style_attribute() would parse the string, extract the properties, add them to a newly-created ElementInlineCSSStyleDeclarations, and then user code would take the properties back out of it again and throw it away. Instead, just return the list of properties, and the caller can create an EICSD if it needs one.
2025-03-17 12:55:21 +00:00
CSS::Parser::Parser::PropertiesAndCustomProperties parse_css_style_attribute(CSS::Parser::ParsingParams const&, StringView);
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
RefPtr<CSS::CSSStyleValue> parse_css_value(CSS::Parser::ParsingParams const&, StringView, CSS::PropertyID property_id = CSS::PropertyID::Invalid);
Optional<CSS::SelectorList> parse_selector(CSS::Parser::ParsingParams const&, StringView);
Optional<CSS::SelectorList> parse_selector_for_nested_style_rule(CSS::Parser::ParsingParams const&, StringView);
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
Optional<CSS::Selector::PseudoElementSelector> parse_pseudo_element_selector(CSS::Parser::ParsingParams const&, StringView);
LibWeb/CSS: Split up Parser.cpp This file has been a pain to edit for a while, even with the previous splits. So, I've divided it up into 3 parts: - Parser.cpp has the "base" code. It's the algorithms and entry-points defined in the Syntax spec. - ValueParsing.cpp contains code for parsing single values, such as a length, or a color, or a calculation. - PropertyParsing.cpp contains code for parsing an entire property's value. A few of these sit in a grey area between being a property's value and a value in their own right, but the rule I've used is "is this useful outside of a single property and its shorthands?" This only moves code, with as few modifications as possible to make that work. I did add explicit instantiations for the template implementations as part of this, which revealed a few that are actually only compatible with a single type, so I'll clear those up in a subsequent commit.
2025-02-06 14:08:26 +00:00
CSS::CSSRule* parse_css_rule(CSS::Parser::ParsingParams const&, StringView);
RefPtr<CSS::MediaQuery> parse_media_query(CSS::Parser::ParsingParams const&, StringView);
Vector<NonnullRefPtr<CSS::MediaQuery>> parse_media_query_list(CSS::Parser::ParsingParams const&, StringView);
RefPtr<CSS::Supports> parse_css_supports(CSS::Parser::ParsingParams const&, StringView);
LibWeb: Add an engine-internal CSS realm for internal style parsing This is used for default UA style right now, and we'll expand its use in the near future. Note that this required teaching the CSS parser to handle url() functions when there's no document URL to resolve them against. If we don't handle that, namespace rules in UA style don't parse correctly.
2025-03-25 10:04:42 +00:00
GC::Ref<JS::Realm> internal_css_realm();
LibWeb: Implement CSS parsing convenience functions These mostly match the API in `DeprecatedCSSParser.h`. The exception is that `parse_selector()` returns a `SelectorList` instead of just one `Selector`. The only uses of that are in `ParentNode::query_selector[_all]()` which should be matching against a list, according to the spec. `parse_html_length()` is an odd case. It's used for `width="200"` cases in HTML, so is not really CSS related, but does produce a StyleValue. The values allowed in `width/height` in HTML vary per element, but they are a lot more restricted than in CSS, so it's slightly inappropriate to use the CSS parser for them, even though it's convenient. We also ignore a few functions: - `parse_line_width()` - `parse_line_style()` - `parse_color()` These are all only used in `StyleResolver`, when it is given a property value as a String. That won't happen once the old parser is removed.
2021-07-30 17:48:23 +01:00
}
Reference in a new issue Copy permalink