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

412 lines
20 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 13:41:47 -03: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 17:46:44 -03:00
* Copyright (c) 2020-2021, the SerenityOS developers.
LibWeb/CSS: Refactor `contains_single_none_ident()` to actually parse it The new method is Parser::parse_all_as_single_none_value(), which has a few advantages: 1. There's no need for user code to manually create a StyleValue. 2. It consumes tokens so that doesn't have to be done manually. 3. Whitespace before or after the `none` is consumed correctly. It does mean we create and then discard a `none` StyleValue in a couple of places, namely parsing for `grid-*` properties. We may or may not want to migrate those to returning the IdentifierStyleValue instead.
2024-07-19 08:07:51 -03:00
* Copyright (c) 2021-2024, Sam Atkins <atkinssj@serenityos.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 13:41:47 -03: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 05:24:48 -03: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 13:41:47 -03: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 07:04:16 -03:00
#include <AK/Error.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 13:30:40 -03: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 13:41:47 -03:00
#include <AK/Vector.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 19:30:01 -03:00
#include <LibGfx/Font/UnicodeRange.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 11:54:16 -03:00
#include <LibWeb/CSS/CSSStyleDeclaration.h>
LibWeb: Parse CSS `<general-enclosed>`
2021-11-22 14:27:09 -03:00
#include <LibWeb/CSS/GeneralEnclosed.h>
LibWeb: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 08:56:37 -03: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 12:18:37 -03:00
#include <LibWeb/CSS/ParsedFontFace.h>
LibWeb: Move/rename StyleBlockRule to Parser::Block
2022-04-12 10:08:26 -03:00
#include <LibWeb/CSS/Parser/Block.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 07:43:07 -03:00
#include <LibWeb/CSS/Parser/ComponentValue.h>
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 10:36:12 -03:00
#include <LibWeb/CSS/Parser/Declaration.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 13:41:47 -03:00
#include <LibWeb/CSS/Parser/DeclarationOrAtRule.h>
LibWeb: Move CSS::Parser::Dimension class to a separate file
2023-08-17 11:43:30 -03:00
#include <LibWeb/CSS/Parser/Dimension.h>
LibWeb: Move/rename StyleFunctionRule to Parser::Function
2022-04-12 09:35:55 -03:00
#include <LibWeb/CSS/Parser/Function.h>
LibWeb: Move CSS ParsingContext to its own header The implementation is already its own file, so having the class defined in Parser.h feels weird.
2023-08-17 11:47:00 -03:00
#include <LibWeb/CSS/Parser/ParsingContext.h>
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 15:05:13 -03:00
#include <LibWeb/CSS/Parser/Rule.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 12:05:57 -03: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 13:41:47 -03:00
#include <LibWeb/CSS/Parser/Tokenizer.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 11:11:11 -03: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 10:48:32 -03: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 13:41:47 -03:00
#include <LibWeb/CSS/Selector.h>
LibWeb: Expose StyleValue parsing method in CSS Parser Now that StyleResolver is going to deal with StyleComponentValueRules, it will need to be able to parse those into StyleValues, using `parse_css_value()`. Also added StyleValue::is_builtin_or_dynamic(), which returns true for values that are valid anywhere - things like `initial` and `inherit`, along with `var()`, `attr()` and `calc()` - which we want to test for easily.
2021-07-18 13:12:23 -03:00
#include <LibWeb/CSS/StyleValue.h>
LibWeb: Split AbstractImageStyleValue out of StyleValue.{h,cpp}
2023-03-24 13:42:50 -03:00
#include <LibWeb/CSS/StyleValues/AbstractImageStyleValue.h>
LibWeb: Split CalculatedStyleValue out of StyleValue.{h,cpp}
2023-03-30 13:34:14 -03: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 11:54:16 -03:00
#include <LibWeb/CSS/Supports.h>
LibWeb: Stop manually forward-declaring types in CSS Parser.h
2022-04-12 07:32:18 -03: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 13:41:47 -03: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 08:00:07 -03: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 13:41:47 -03: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 07:16:49 -03:00
class PropertyDependencyNode;
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 13:41:47 -03:00
class Parser {
public:
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 14:17:08 -03:00
static ErrorOr<Parser> create(ParsingContext const&, StringView input, StringView encoding = "utf-8"sv);
Parser(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 13:41:47 -03: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 00:22:27 -03:00
CSSStyleSheet* parse_as_css_stylesheet(Optional<URL::URL> location);
LibWeb: Make CSSStyleDeclaration GC-allocated
2022-08-07 11:21:26 -03:00
ElementInlineCSSStyleDeclaration* parse_as_style_attribute(DOM::Element&);
LibWeb: Make CSSRule and all its subclasses GC-allocated
2022-08-07 10:46:44 -03: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 08:05:16 -03: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 12:37:54 -03: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 12:14:01 -03: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 08:34:25 -03: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 12:14:01 -03: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 13:06:48 -03: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 10:17:01 -03: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 08:56:37 -03: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 11:54:16 -03:00
RefPtr<Supports> parse_as_supports();
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> 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 13:48:23 -03: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 08:57:12 -03:00
Optional<ComponentValue> parse_as_component_value();
LibWeb: Support loading FontFaces constructed with binary data
2024-05-13 15:02:38 -03:00
Vector<ParsedFontFace::Source> parse_as_font_face_src();
LibWeb: Remove Badge from CSS::Parser::resolve_unresolved_style_value KeyframeEffect needs to use this method to resolve unresolved properties in the same way that StyleComputer does.
2024-03-17 21:27:38 -03:00
static NonnullRefPtr<StyleValue> resolve_unresolved_style_value(ParsingContext const&, DOM::Element&, Optional<CSS::Selector::PseudoElement::Type>, 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 09:32:12 -03:00
LibWeb: Allow calc() values in image `sizes` attribute Note that we currently can't resolve calc() values without a layout node, so when normalizing an image's source set, we'll flush any pending layout updates and hope that gives us an up-to-date layout node. I've left a FIXME about implementing this in a more elegant and less layout-thrashy way, as that will require more architectural work.
2023-07-28 10:52:06 -03:00
[[nodiscard]] LengthOrCalculated parse_as_sizes_attribute();
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 11:56:01 -03:00
LibWeb: Add attribute list that must always be compared without casing
2024-06-22 08:33:48 -03:00
// https://html.spec.whatwg.org/multipage/semantics-other.html#case-sensitivity-of-selectors
static constexpr Array case_insensitive_html_attributes = {
"accept"sv,
"accept-charset"sv,
"align"sv,
"alink"sv,
"axis"sv,
"bgcolor"sv,
"charset"sv,
"checked"sv,
"clear"sv,
"codetype"sv,
"color"sv,
"compact"sv,
"declare"sv,
"defer"sv,
"dir"sv,
"direction"sv,
"disabled"sv,
"enctype"sv,
"face"sv,
"frame"sv,
"hreflang"sv,
"http-equiv"sv,
"lang"sv,
"language"sv,
"link"sv,
"media"sv,
"method"sv,
"multiple"sv,
"nohref"sv,
"noresize"sv,
"noshade"sv,
"nowrap"sv,
"readonly"sv,
"rel"sv,
"rev"sv,
"rules"sv,
"scope"sv,
"scrolling"sv,
"selected"sv,
"shape"sv,
"target"sv,
"text"sv,
"type"sv,
"valign"sv,
"valuetype"sv,
"vlink"sv,
};
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 13:06:48 -03:00
private:
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 14:17:08 -03:00
Parser(ParsingContext const&, Vector<Token>);
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 07:04:16 -03: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 13:47:58 -03: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 09:03:51 -03: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 13:42:11 -03: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 07:04:16 -03: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 13:42:11 -03: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 10:13:39 -03: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 00:22:27 -03:00
Optional<URL::URL> location;
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 10:17:01 -03:00
Vector<NonnullRefPtr<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 10:13:39 -03: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 13:06:48 -03: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 00:22:27 -03: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 10:13:39 -03:00
LibWeb: Use parse_a_list_of_rules() for `@media` and `@supports` From the spec: > "Parse a list of rules" is intended for the content of at-rules such > as @media. It differs from "Parse a stylesheet" in the handling of > <CDO-token> and <CDC-token>. - https://www.w3.org/TR/css-syntax-3/#ref-for-parse-a-list-of-rules
2022-03-30 07:36:38 -03:00
// "Parse a list of rules" is intended for the content of at-rules such as @media. It differs from "Parse a stylesheet" in the handling of <CDO-token> and <CDC-token>.
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 13:06:48 -03: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 10:17:01 -03:00
Vector<NonnullRefPtr<Rule>> parse_a_list_of_rules(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 07:48:54 -03: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 13:06:48 -03:00
template<typename T>
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 15:05:13 -03:00
RefPtr<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 07:48:54 -03: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 08:05:16 -03: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 13:06:48 -03:00
template<typename T>
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 10:36:12 -03: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 08:23:07 -03:00
LibWeb: Implement and use `parse_a_style_blocks_contents()`
2022-03-30 12:44:13 -03:00
template<typename T>
Vector<DeclarationOrAtRule> parse_a_style_blocks_contents(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 08:23:07 -03:00
// "Parse a list of declarations" is for the contents of a style attribute, which parses text into the contents of a single style 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 13:06:48 -03:00
template<typename T>
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 12:37:54 -03:00
Vector<DeclarationOrAtRule> parse_a_list_of_declarations(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_component_value()`
2022-03-30 08:32:42 -03: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 13:06:48 -03: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 07:43:07 -03:00
Optional<ComponentValue> parse_a_component_value(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_component_values()`
2022-03-30 08:39:36 -03: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 13:06:48 -03: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 07:43:07 -03:00
Vector<ComponentValue> parse_a_list_of_component_values(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_component_values()`
2022-03-30 08:39:36 -03: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 13:06:48 -03: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 07:43:07 -03: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 16:29:40 -03: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 11:40:06 -03: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 07:04:16 -03:00
ParseErrorOr<SelectorList> parse_a_selector_list(TokenStream<T>&, SelectorType, SelectorParsingMode = SelectorParsingMode::Standard);
LibWeb: Combine identical relative/regular selector parsing functions
2022-03-17 16:29:40 -03:00
LibWeb: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 08:56:37 -03: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 10:17:01 -03: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 11:54:16 -03: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 13:41:47 -03: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 08:03:42 -03: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 13:41:47 -03:00
LibWeb: Use an enum class for the "top-level flag"
2022-03-29 09:46:16 -03:00
enum class TopLevel {
No,
Yes
};
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 11:40:06 -03: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 10:17:01 -03:00
[[nodiscard]] Vector<NonnullRefPtr<Rule>> consume_a_list_of_rules(TokenStream<T>&, TopLevel);
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 11:40:06 -03:00
template<typename T>
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 15:05:13 -03:00
[[nodiscard]] NonnullRefPtr<Rule> consume_an_at_rule(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 11:40:06 -03:00
template<typename T>
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 15:05:13 -03:00
RefPtr<Rule> consume_a_qualified_rule(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 11:40:06 -03:00
template<typename T>
LibWeb: Implement and use `parse_a_style_blocks_contents()`
2022-03-30 12:44:13 -03:00
[[nodiscard]] Vector<DeclarationOrAtRule> consume_a_style_blocks_contents(TokenStream<T>&);
template<typename 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 11:40:06 -03:00
[[nodiscard]] Vector<DeclarationOrAtRule> consume_a_list_of_declarations(TokenStream<T>&);
template<typename T>
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 10:36:12 -03:00
Optional<Declaration> consume_a_declaration(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 11:40:06 -03: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 07:43:07 -03: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 11:40:06 -03:00
template<typename T>
LibWeb: Move/rename StyleBlockRule to Parser::Block
2022-04-12 10:08:26 -03:00
NonnullRefPtr<Block> consume_a_simple_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 11:40:06 -03:00
template<typename T>
LibWeb: Move/rename StyleFunctionRule to Parser::Function
2022-04-12 09:35:55 -03:00
NonnullRefPtr<Function> consume_a_function(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 13:41:47 -03: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 07:43:07 -03:00
Optional<GeneralEnclosed> parse_general_enclosed(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 11:54:16 -03:00
LibWeb: Make CSSRule and all its subclasses GC-allocated
2022-08-07 10:46:44 -03:00
CSSRule* parse_font_face_rule(TokenStream<ComponentValue>&);
LibWeb: Support loading FontFaces constructed with binary data
2024-05-13 15:02:38 -03: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 16:32:28 -03:00
LibWeb: Make CSSRule and all its subclasses GC-allocated
2022-08-07 10:46:44 -03:00
CSSRule* convert_to_rule(NonnullRefPtr<Rule>);
LibWeb: Move media-query parsing code to separate file Parser.cpp is big and complicated enough to make CLion sluggish and unhappy, so let's move some code out of it.
2023-08-17 10:56:00 -03:00
CSSMediaRule* convert_to_media_rule(NonnullRefPtr<Rule>);
LibWeb: Avoid unnecessary copies in CSS Parser
2022-09-10 08:51:22 -03:00
PropertyOwningCSSStyleDeclaration* convert_to_style_declaration(Vector<DeclarationOrAtRule> const& declarations);
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 10:36:12 -03: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 12:34:29 -03: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 07:43:07 -03: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 09:43:38 -03: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>&);
Optional<ResolutionOrCalculated> parse_resolution(TokenStream<ComponentValue>&);
Optional<TimeOrCalculated> parse_time(TokenStream<ComponentValue>&);
Optional<TimePercentage> parse_time_percentage(TokenStream<ComponentValue>&);
LibWeb/CSS: Split parse_rgb_or_hsl_color into separate functions
2024-07-03 05:39:14 -03:00
Optional<Color> parse_rgb_color(Vector<ComponentValue> const&);
Optional<Color> parse_hsl_color(Vector<ComponentValue> const&);
LibWeb/CSS: Support hwb, oklab and oklch color functions
2024-07-03 08:17:37 -03:00
Optional<Color> parse_hwb_color(Vector<ComponentValue> const&);
Optional<Color> parse_oklab_color(Vector<ComponentValue> const&);
Optional<Color> parse_oklch_color(Vector<ComponentValue> 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 07:43:07 -03:00
Optional<Color> parse_color(ComponentValue const&);
LibWeb: Convert parse_source_size_value() to TokenStream
2023-12-30 14:06:14 -03: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 07:43:07 -03: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 19:30:01 -03: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 17:02:52 -03:00
Vector<Gfx::UnicodeRange> parse_unicode_ranges(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 09:27:57 -03:00
Optional<GridSize> parse_grid_size(ComponentValue const&);
LibWeb: Implement grid-template function fit-content()
2024-07-22 17:49:52 -03:00
Optional<GridFitContent> parse_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 09:27:57 -03: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 09:38:50 -03: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 00:22:27 -03:00
Optional<URL::URL> parse_url_function(ComponentValue const&);
LibWeb: Parse URL values using TokenStream
2023-12-27 09:00:41 -03:00
RefPtr<StyleValue> 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 07:43:07 -03:00
LibWeb: Parse the `polygon()` basic shape function
2024-05-25 20:20:09 -03:00
RefPtr<StyleValue> parse_basic_shape_function(ComponentValue const&);
RefPtr<StyleValue> parse_basic_shape_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 08:48:36 -03:00
template<typename TElement>
Optional<Vector<TElement>> parse_color_stop_list(TokenStream<ComponentValue>& tokens, auto is_position, auto get_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 17:33:00 -03:00
Optional<Vector<LinearColorStopListElement>> parse_linear_color_stop_list(TokenStream<ComponentValue>&);
Optional<Vector<AngularColorStopListElement>> parse_angular_color_stop_list(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_linear_gradient_function(ComponentValue const&);
RefPtr<StyleValue> parse_conic_gradient_function(ComponentValue const&);
RefPtr<StyleValue> parse_radial_gradient_function(ComponentValue const&);
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-11 20:15:05 -03: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 07:04:16 -03:00
ParseErrorOr<NonnullRefPtr<StyleValue>> parse_css_value(PropertyID, TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> 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 13:23:42 -03:00
struct PropertyAndValue {
PropertyID property;
RefPtr<StyleValue> style_value;
};
LibWeb: Make parse_css_value_for_properties() return Optional Signalling failure with a null `PropertyAndValue::style_value` is weird.
2023-08-19 11:26:57 -03:00
Optional<PropertyAndValue> parse_css_value_for_properties(ReadonlySpan<PropertyID>, TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_builtin_value(ComponentValue const&);
RefPtr<CalculatedStyleValue> parse_calculated_value(ComponentValue const&);
LibWeb: Generate parsing code for CSS math functions
2023-07-13 10:59:31 -03:00
// NOTE: Implemented in generated code. (GenerateCSSMathFunctions.cpp)
LibWeb: Make CSS math function parsing infallible
2023-08-19 11:20:23 -03:00
OwnPtr<CalculationNode> parse_math_function(PropertyID, Function const&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
OwnPtr<CalculationNode> parse_a_calc_function_node(Function const&);
LibWeb: Parse dimension values using TokenStream
2024-04-21 15:08:47 -03:00
RefPtr<StyleValue> parse_dimension_value(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_integer_value(TokenStream<ComponentValue>&);
RefPtr<StyleValue> parse_number_value(TokenStream<ComponentValue>&);
LibWeb: Allow percentages on CSS transform scale functions
2024-01-08 14:51:19 -03:00
RefPtr<StyleValue> parse_number_or_percentage_value(TokenStream<ComponentValue>&);
LibWeb: Parse identifier values using TokenStream
2024-04-21 15:01:59 -03:00
RefPtr<StyleValue> parse_identifier_value(TokenStream<ComponentValue>&);
LibWeb: Parse color values using TokenStream
2024-04-21 14:35:50 -03:00
RefPtr<StyleValue> parse_color_value(TokenStream<ComponentValue>&);
LibWeb: Parse rect() values using TokenStream
2023-12-27 09:08:47 -03:00
RefPtr<StyleValue> parse_rect_value(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_ratio_value(TokenStream<ComponentValue>&);
LibWeb: Parse string values using TokenStream
2024-04-21 13:41:04 -03:00
RefPtr<StyleValue> parse_string_value(TokenStream<ComponentValue>&);
LibWeb: Parse image values using TokenStream
2023-12-27 08:55:24 -03:00
RefPtr<StyleValue> parse_image_value(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> 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 12:33:21 -03:00
enum class PositionParsingMode {
Normal,
BackgroundPosition,
};
RefPtr<PositionStyleValue> parse_position_value(TokenStream<ComponentValue>&, PositionParsingMode = PositionParsingMode::Normal);
LibWeb: Parse FilterValueListStyleValue using TokenStream
2023-12-07 12:16:51 -03:00
RefPtr<StyleValue> parse_filter_value_list_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 14:19:55 -03:00
template<typename ParseFunction>
LibWeb: Make parse_comma_separated_value_list() take a TokenStream This lets us use it from inside places that use TokenStreams.
2023-12-07 09:54:27 -03:00
RefPtr<StyleValue> parse_comma_separated_value_list(TokenStream<ComponentValue>&, ParseFunction);
RefPtr<StyleValue> parse_simple_comma_separated_value_list(PropertyID, TokenStream<ComponentValue>&);
LibWeb/CSS: Refactor `contains_single_none_ident()` to actually parse it The new method is Parser::parse_all_as_single_none_value(), which has a few advantages: 1. There's no need for user code to manually create a StyleValue. 2. It consumes tokens so that doesn't have to be done manually. 3. Whitespace before or after the `none` is consumed correctly. It does mean we create and then discard a `none` StyleValue in a couple of places, namely parsing for `grid-*` properties. We may or may not want to migrate those to returning the IdentifierStyleValue instead.
2024-07-19 08:07:51 -03:00
RefPtr<StyleValue> parse_all_as_single_none_value(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
LibWeb: Parse aspect-ratio property using TokenStream
2023-12-07 12:12:30 -03:00
RefPtr<StyleValue> parse_aspect_ratio_value(TokenStream<ComponentValue>&);
LibWeb: Parse background property using TokenStream
2023-12-07 12:21:17 -03:00
RefPtr<StyleValue> parse_background_value(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_single_background_position_x_or_y_value(TokenStream<ComponentValue>&, PropertyID);
RefPtr<StyleValue> parse_single_background_repeat_value(TokenStream<ComponentValue>&);
RefPtr<StyleValue> parse_single_background_size_value(TokenStream<ComponentValue>&);
LibWeb: Parse border properties using TokenStream
2023-12-07 14:15:15 -03:00
RefPtr<StyleValue> parse_border_value(PropertyID, TokenStream<ComponentValue>&);
LibWeb: Parse border-radius properties using TokenStream
2023-12-07 09:23:51 -03:00
RefPtr<StyleValue> parse_border_radius_value(TokenStream<ComponentValue>&);
RefPtr<StyleValue> parse_border_radius_shorthand_value(TokenStream<ComponentValue>&);
LibWeb: Parse content property using TokenStream
2023-12-07 09:34:51 -03:00
RefPtr<StyleValue> parse_content_value(TokenStream<ComponentValue>&);
LibWeb: Parse display property using TokenStream
2023-12-07 09:35:03 -03:00
RefPtr<StyleValue> parse_display_value(TokenStream<ComponentValue>&);
LibWeb: Parse flex property using TokenStream
2023-12-07 14:28:55 -03:00
RefPtr<StyleValue> parse_flex_value(TokenStream<ComponentValue>&);
LibWeb: Parse flex-flow property using TokenStream
2023-12-07 14:30:23 -03:00
RefPtr<StyleValue> parse_flex_flow_value(TokenStream<ComponentValue>&);
LibWeb: Part font property using TokenStream
2023-12-07 14:32:33 -03:00
RefPtr<StyleValue> parse_font_value(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_font_family_value(TokenStream<ComponentValue>&);
LibWeb: Parse list-style property using TokenStream
2023-12-08 14:00:58 -03:00
RefPtr<StyleValue> parse_list_style_value(TokenStream<ComponentValue>&);
LibWeb: Parse math-depth property using TokenStream We don't need to skip whitespace at the top level because that's already done before we're called. But we do still have to skip it inside the `add()` function
2023-12-08 14:06:04 -03:00
RefPtr<StyleValue> parse_math_depth_value(TokenStream<ComponentValue>&);
LibWeb: Parse overflow property using TokenStream Also simplify it a bit. We don't need to handle 1 / 2 values separately, but past Sam didn't realise that.
2023-12-08 14:09:03 -03:00
RefPtr<StyleValue> parse_overflow_value(TokenStream<ComponentValue>&);
LibWeb: Parse place-content property using TokenStream
2023-12-08 14:21:49 -03:00
RefPtr<StyleValue> parse_place_content_value(TokenStream<ComponentValue>&);
LibWeb: Parse place-items property using TokenStream
2023-12-08 14:23:48 -03:00
RefPtr<StyleValue> parse_place_items_value(TokenStream<ComponentValue>&);
LibWeb: Parse place-self property using TokenStream
2023-12-08 14:26:19 -03:00
RefPtr<StyleValue> parse_place_self_value(TokenStream<ComponentValue>&);
LibWeb: Parse quotes property using TokenStream
2023-12-07 09:38:51 -03:00
RefPtr<StyleValue> parse_quotes_value(TokenStream<ComponentValue>&);
LibWeb: Implement support for scrollbar-gutter This property is now correctly parsed. Ladybird always uses overlay scrollbars so this property does nothing.
2024-06-26 19:19:38 -03:00
RefPtr<StyleValue> 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 13:59:44 -03:00
enum class AllowInsetKeyword {
No,
Yes,
};
LibWeb: Parse shadow values using TokenStream
2023-12-07 14:26:25 -03:00
RefPtr<StyleValue> parse_shadow_value(TokenStream<ComponentValue>&, AllowInsetKeyword);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_single_shadow_value(TokenStream<ComponentValue>&, AllowInsetKeyword);
LibWeb: Parse text-decoration property using TokenStream
2023-12-08 14:28:41 -03:00
RefPtr<StyleValue> parse_text_decoration_value(TokenStream<ComponentValue>&);
LibWeb: Make internal StyleValue-parsing methods infallible
2023-08-19 10:48:27 -03:00
RefPtr<StyleValue> parse_text_decoration_line_value(TokenStream<ComponentValue>&);
RefPtr<StyleValue> parse_easing_value(TokenStream<ComponentValue>&);
LibWeb: Parse transform property using TokenStream While I'm at it, use the helper for "none", and remove the unnecessary whitespace skipping.
2023-12-08 14:44:57 -03:00
RefPtr<StyleValue> parse_transform_value(TokenStream<ComponentValue>&);
LibWeb: Parse transform-origin property using TokenStream
2023-12-26 11:40:36 -03:00
RefPtr<StyleValue> parse_transform_origin_value(TokenStream<ComponentValue>&);
LibWeb: Parse transition style values
2024-02-19 23:01:34 -03:00
RefPtr<StyleValue> parse_transition_value(TokenStream<ComponentValue>&);
LibWeb: Parse grid-template-[columns,rows] properties using TokenStream
2023-12-26 11:58:33 -03:00
RefPtr<StyleValue> parse_grid_track_size_list(TokenStream<ComponentValue>&, bool allow_separate_line_name_blocks = false);
LibWeb: Parse grid-auto-[columns,rows] properties using TokenStream
2023-12-26 11:54:46 -03:00
RefPtr<StyleValue> 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 14:42:43 -03:00
RefPtr<GridAutoFlowStyleValue> parse_grid_auto_flow_value(TokenStream<ComponentValue>&);
LibWeb: Parse grid-template property using TokenStream
2023-12-26 12:14:15 -03:00
RefPtr<StyleValue> parse_grid_track_size_list_shorthand_value(PropertyID, TokenStream<ComponentValue>&);
LibWeb: Parse grid track placements using TokenStream I'm not entirely happy with this, but I barely understand grid, and this does still work.
2023-12-08 09:07:48 -03:00
RefPtr<StyleValue> parse_grid_track_placement(TokenStream<ComponentValue>&);
LibWeb: Parse grid-column and grid-row properties using TokenStream
2023-12-07 14:36:46 -03:00
RefPtr<StyleValue> parse_grid_track_placement_shorthand_value(PropertyID, TokenStream<ComponentValue>&);
LibWeb: Parse grid-template-areas property using TokenStream
2023-12-07 18:08:06 -03:00
RefPtr<StyleValue> parse_grid_template_areas_value(TokenStream<ComponentValue>&);
LibWeb: Parse grid-area property using TokenStream
2023-12-07 14:40:14 -03:00
RefPtr<StyleValue> parse_grid_area_shorthand_value(TokenStream<ComponentValue>&);
LibWeb: Parse grid property using TokenStream
2023-12-26 12:16:36 -03:00
RefPtr<StyleValue> 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 12:20:06 -03:00
LibWeb: Make CSS math function parsing infallible
2023-08-19 11:20:23 -03:00
OwnPtr<CalculationNode> parse_a_calculation(Vector<ComponentValue> 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 07:43:07 -03: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 07:04:16 -03: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 07:43:07 -03: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 12:48:44 -03: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 07:04:16 -03: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 07:43:07 -03:00
NonnullRefPtr<MediaQuery> parse_media_query(TokenStream<ComponentValue>&);
OwnPtr<MediaCondition> parse_media_condition(TokenStream<ComponentValue>&, MediaCondition::AllowOr allow_or);
Optional<MediaFeature> parse_media_feature(TokenStream<ComponentValue>&);
Optional<MediaQuery::MediaType> parse_media_type(TokenStream<ComponentValue>&);
OwnPtr<MediaCondition> parse_media_in_parens(TokenStream<ComponentValue>&);
Optional<MediaFeatureValue> parse_media_feature_value(MediaFeatureID, TokenStream<ComponentValue>&);
OwnPtr<Supports::Condition> parse_supports_condition(TokenStream<ComponentValue>&);
Optional<Supports::InParens> parse_supports_in_parens(TokenStream<ComponentValue>&);
Optional<Supports::Feature> 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 11:54:16 -03:00
LibWeb: Wrap PseudoElements stored in SimpleSelector in a class No functional impact intended. This is just a more complicated way of writing what we have now. The goal of this commit is so that we are able to store the 'name' of a pseudo element for use in serializing 'unknown -webkit- pseudo-elements', see: https://www.w3.org/TR/selectors-4/#compat This is quite awkward, as in pretty much all cases just the selector type enum is enough, but we will need to cache the name for serializing these unknown selectors. I can't figure out any reason why we would need this name anywhere else in the engine, so pretty much everywhere is still just passing around this raw enum. But this change will allow us to easily store the name inside of this new struct for when it is needed for serialization, once those webkit unknown elements are supported by our engine.
2023-12-10 05:00:03 -03:00
NonnullRefPtr<StyleValue> resolve_unresolved_style_value(DOM::Element&, Optional<Selector::PseudoElement::Type>, PropertyID, UnresolvedStyleValue const&);
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 16:32:45 -03:00
bool expand_variables(DOM::Element&, Optional<Selector::PseudoElement::Type>, FlyString const& property_name, HashMap<FlyString, NonnullRefPtr<PropertyDependencyNode>>& dependencies, TokenStream<ComponentValue>& source, Vector<ComponentValue>& dest);
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 07:16:49 -03:00
Everywhere: Pass AK::StringView by value
2021-11-10 20:55:02 -03: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 12:49:09 -03:00
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 11:01:38 -03:00
struct PropertiesAndCustomProperties {
Vector<StyleProperty> properties;
LibWeb: Port custom properties to FlyString
2023-11-05 00:19:16 -03:00
HashMap<FlyString, StyleProperty> custom_properties;
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 11:01:38 -03:00
};
PropertiesAndCustomProperties extract_properties(Vector<DeclarationOrAtRule> const&);
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 16:25:13 -03:00
ParsingContext m_context;
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 13:41:47 -03: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 10:00:41 -03:00
TokenStream<Token> m_token_stream;
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 13:41:47 -03: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 13:48:23 -03:00
namespace Web {
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 00:22:27 -03:00
CSS::CSSStyleSheet* parse_css_stylesheet(CSS::Parser::ParsingContext const&, StringView, Optional<URL::URL> location = {});
LibWeb: Make CSSStyleDeclaration GC-allocated
2022-08-07 11:21:26 -03:00
CSS::ElementInlineCSSStyleDeclaration* parse_css_style_attribute(CSS::Parser::ParsingContext const&, StringView, DOM::Element&);
LibWeb: Make external StyleValue-parsing methods infallible
2023-08-19 11:01:21 -03:00
RefPtr<CSS::StyleValue> parse_css_value(CSS::Parser::ParsingContext const&, StringView, CSS::PropertyID property_id = CSS::PropertyID::Invalid);
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 08:00:07 -03:00
Optional<CSS::SelectorList> parse_selector(CSS::Parser::ParsingContext const&, StringView);
LibWeb: Make CSSRule and all its subclasses GC-allocated
2022-08-07 10:46:44 -03:00
CSS::CSSRule* parse_css_rule(CSS::Parser::ParsingContext const&, StringView);
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 08:00:07 -03:00
RefPtr<CSS::MediaQuery> parse_media_query(CSS::Parser::ParsingContext const&, StringView);
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 10:17:01 -03:00
Vector<NonnullRefPtr<CSS::MediaQuery>> parse_media_query_list(CSS::Parser::ParsingContext const&, StringView);
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 08:00:07 -03:00
RefPtr<CSS::Supports> parse_css_supports(CSS::Parser::ParsingContext const&, StringView);
LibWeb: Use free functions for parsing in `@Supports`
2023-03-06 11:46:21 -03:00
Optional<CSS::StyleProperty> parse_css_supports_condition(CSS::Parser::ParsingContext const&, StringView);
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 13:48:23 -03:00
}
Reference in a new issue Copy permalink