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

383 lines
17 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.
Everywhere: Use my shiny new serenityos.org email :^)
2021-09-03 11:14:37 +01:00
* Copyright (c) 2021, 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 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
#include <AK/NonnullOwnPtrVector.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/NonnullRefPtrVector.h>
#include <AK/RefPtr.h>
LibWeb: Parse CSS selectors according to the spec The spec does not directly tell us how to parse selectors, so there are likely some bugs here, but I've used the spec language where possible. This is very much based on the previous selector parsing code. Any parse error inside a selector makes the entire SelectorList invalid, so nothing is returned.
2021-07-23 16:13:07 +01:00
#include <AK/Result.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: 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: Parse CSS `<general-enclosed>`
2021-11-22 17:27:09 +00: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 12:56:37 +01:00
#include <LibWeb/CSS/MediaQuery.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/DeclarationOrAtRule.h>
#include <LibWeb/CSS/Parser/StyleBlockRule.h>
#include <LibWeb/CSS/Parser/StyleComponentValueRule.h>
#include <LibWeb/CSS/Parser/StyleDeclarationRule.h>
#include <LibWeb/CSS/Parser/StyleFunctionRule.h>
LibWeb: Merge CSS Parser's QualifiedStyleRule and AtStyleRule AtStyleRule being a subclass of QualifiedStyleRule was causing problems when trying to distinguish between them. Combining them and then distinguishing between them with a Type enum makes that check simpler, and is in line with how similar checks are done elsewhere in the parser.
2021-07-03 13:36:33 +01:00
#include <LibWeb/CSS/Parser/StyleRule.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: 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: 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 17:12:23 +01:00
#include <LibWeb/CSS/StyleValue.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: 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
namespace Web::CSS {
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
class CSSStyleSheet;
class CSSRule;
class CSSStyleRule;
struct StyleProperty;
LibWeb: Convert style declarations and at rules into CSSRules
2021-07-08 21:53:22 +01:00
enum class PropertyID;
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: 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
class ParsingContext {
public:
LibWeb: Use default instead of an empty constructor/destructor Default implementations allow for more optimizations. See: https://pvs-studio.com/en/docs/warnings/v832/
2021-09-15 23:24:47 -07:00
ParsingContext() = default;
LibWeb: Make CSS ParsingContext's Document* be const The only reason it wasn't const before (and why we had a const_cast hack) was to support ImageStyleValue's constructor taking it, which no longer applies. `hack_count--;` :^)
2021-10-22 20:59:45 +01:00
explicit ParsingContext(DOM::Document const&);
LibWeb: Fix resolving relative URLs in style sheets Relative URLs in style sheets should be resolved relative to the style sheet they're in instead of the document.
2022-03-14 21:09:55 +01:00
explicit ParsingContext(DOM::Document const&, Optional<AK::URL> const);
LibWeb: Implement ImageStyleValue parsing Later we will want to make a distinction between URL and Image values, but this works for now.
2021-07-22 13:00:29 +01:00
explicit ParsingContext(DOM::ParentNode&);
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
bool in_quirks_mode() const;
LibWeb: Make CSS ParsingContext's Document* be const The only reason it wasn't const before (and why we had a const_cast hack) was to support ImageStyleValue's constructor taking it, which no longer applies. `hack_count--;` :^)
2021-10-22 20:59:45 +01:00
DOM::Document const* document() const { return m_document; }
LibWeb: Add the Web::URL namespace and move URLEncoder to it This namespace will be used for all interfaces defined in the URL specification, like URL and URLSearchParams. This has the unfortunate side-effect of requiring us to use the fully qualified AK::URL name whenever we want to refer to the AK class, so this commit also fixes all such references.
2021-09-13 00:33:23 +03:00
AK::URL complete_url(String const&) 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 20:25:13 +01:00
LibWeb: Add current_property_id to CSS ParsingContext After `parse_css_value(PropertyID, TokenStream)`, we only need to know the current PropertyID when checking for property-specific quirks, which will take place in only 2 places, which happen deep down. Making the current PropertyID part of the context means that those places can check it easily, without us having to pass it to every one of the parsing functions, which otherwise do not care.
2021-09-11 20:39:44 +01:00
PropertyID current_property_id() const { return m_current_property_id; }
void set_current_property_id(PropertyID property_id) { m_current_property_id = property_id; }
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
private:
LibWeb: Make CSS ParsingContext's Document* be const The only reason it wasn't const before (and why we had a const_cast hack) was to support ImageStyleValue's constructor taking it, which no longer applies. `hack_count--;` :^)
2021-10-22 20:59:45 +01:00
DOM::Document const* m_document { nullptr };
LibWeb: Add current_property_id to CSS ParsingContext After `parse_css_value(PropertyID, TokenStream)`, we only need to know the current PropertyID when checking for property-specific quirks, which will take place in only 2 places, which happen deep down. Making the current PropertyID part of the context means that those places can check it easily, without us having to pass it to every one of the parsing functions, which otherwise do not care.
2021-09-11 20:39:44 +01:00
PropertyID m_current_property_id { PropertyID::Invalid };
LibWeb: Fix resolving relative URLs in style sheets Relative URLs in style sheets should be resolved relative to the style sheet they're in instead of the document.
2022-03-14 21:09:55 +01:00
Optional<AK::URL> m_url;
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: 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
template<typename T>
class TokenStream {
public:
explicit TokenStream(Vector<T> const&);
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
~TokenStream() = default;
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
LibWeb: Prevent copying CSS TokenStream This was leading to confusing bugs where I was accidentally passing it by value and then wondering why tokens weren't getting consumed!
2021-11-10 17:05:03 +00:00
TokenStream(TokenStream<T> const&) = delete;
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
bool has_next_token();
T const& next_token();
LibWeb: Allow peeking more than 1 token ahead in CSS Parser
2021-07-28 16:27:45 +01:00
T const& peek_token(int offset = 0);
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
T const& current_token();
void reconsume_current_input_token();
LibWeb: Add TokenStream::rewind_to_position() Parsing media queries sometimes requires significant back-tracking, so `reconsume_current_input_token()` was not good enough. `rewind_to_position()` lets you reconsume an erbitrary number of tokens to return to an earlier point in the stream, which you previously saved from `TokenStream::position()`.
2021-09-30 17:17:21 +01:00
int position() const { return m_iterator_offset; }
void rewind_to_position(int);
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
void skip_whitespace();
void dump_all_tokens();
private:
Vector<T> const& m_tokens;
int m_iterator_offset { -1 };
T make_eof();
T m_eof;
};
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 {
public:
Everywhere: Pass AK::StringView by value
2021-11-11 00:55:02 +01:00
Parser(ParsingContext const&, StringView input, String const& encoding = "utf-8");
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
~Parser() = default;
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
// 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: 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
NonnullRefPtrVector<CSSRule> parse_as_list_of_rules();
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
// For use by the CSSStyleSheet#insertRule method, and similar functions which might exist, which parse text into a single rule.
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
RefPtr<CSSRule> parse_as_rule();
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
// Used in @supports conditions. [CSS3-CONDITIONAL]
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
Optional<StyleProperty> parse_as_declaration();
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
// For the contents of a style attribute, which parses text into the contents of a single style rule.
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
Vector<DeclarationOrAtRule> parse_as_list_of_declarations();
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
// For things that need to consume a single value, like the parsing rules for attr().
Optional<StyleComponentValueRule> parse_as_component_value();
// 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.
Vector<StyleComponentValueRule> parse_as_list_of_component_values();
LibWeb: Bring CSS::Parser::parse_as_comma_separated_list...() to spec Previous implementation was returning everything in a single Vector, when what we really want is a Vector of Vectors, one for each comma- separated part of the list.
2021-07-02 19:52:07 +01:00
Vector<Vector<StyleComponentValueRule>> parse_as_comma_separated_list_of_component_values();
LibWeb: Implement CSS::Parse::parse_nth_child_pattern() This is a modified copy of the code from Selector.cpp, to work on a TokenStream instead of a String.
2021-07-08 13:44:01 +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
NonnullRefPtr<CSSStyleSheet> parse_as_css_stylesheet(Optional<AK::URL> location);
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
RefPtr<ElementInlineCSSStyleDeclaration> parse_as_style_attribute(DOM::Element&);
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: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 12:56:37 +01:00
NonnullRefPtrVector<MediaQuery> parse_as_media_query_list();
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: 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
RefPtr<StyleValue> parse_as_css_value(PropertyID);
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
static RefPtr<StyleValue> parse_css_value(Badge<StyleComputer>, ParsingContext const&, PropertyID, Vector<StyleComponentValueRule> const&);
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: Rename CSS::Parser::SelectorParsingResult => ParsingResult I'm going to use it for non-selector purposes too, so the name needed to change.
2021-09-12 19:29:47 +01:00
enum class ParsingResult {
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
Done,
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: 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: 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 {
Optional<AK::URL> location;
NonnullRefPtrVector<StyleRule> rules;
};
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: 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
ParsedStyleSheet parse_a_stylesheet(TokenStream<T>&, Optional<AK::URL> location);
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>
NonnullRefPtrVector<CSSRule> parse_a_list_of_rules(TokenStream<T>&);
template<typename T>
RefPtr<CSSRule> parse_a_rule(TokenStream<T>&);
template<typename T>
Optional<StyleProperty> parse_a_declaration(TokenStream<T>&);
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 16:37:54 +01:00
Vector<DeclarationOrAtRule> parse_a_list_of_declarations(TokenStream<T>&);
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>
Optional<StyleComponentValueRule> parse_a_component_value(TokenStream<T>&);
template<typename T>
Vector<StyleComponentValueRule> parse_a_list_of_component_values(TokenStream<T>&);
template<typename T>
Vector<Vector<StyleComponentValueRule>> 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: Combine identical relative/regular selector parsing functions
2022-03-17 19:29:40 +00:00
Result<SelectorList, ParsingResult> parse_a_selector_list(TokenStream<T>&, SelectorType, SelectorParsingMode = SelectorParsingMode::Standard);
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>
NonnullRefPtrVector<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: Implement `:nth-[last-]child(n of foo)` syntax In Selectors level 4, `:nth-child()` and `:nth-last-child()` can both optionally take a selector-list argument. This selector-list acts as a filter, so that only elements matching the list are counted. For example, this means that the following are equivalent: ```css :nth-child(2n+1 of p) {} p:nth-of-type(2n+1) {} ```
2022-03-17 19:13:51 +00:00
enum class AllowTrailingTokens {
No,
Yes
};
Optional<Selector::SimpleSelector::ANPlusBPattern> parse_a_n_plus_b_pattern(TokenStream<StyleComponentValueRule>&, AllowTrailingTokens = AllowTrailingTokens::No);
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: Use an enum class for the "top-level flag"
2022-03-29 13:46:16 +01: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 15:40:06 +01:00
template<typename T>
LibWeb: Use an enum class for the "top-level flag"
2022-03-29 13:46:16 +01:00
[[nodiscard]] NonnullRefPtrVector<StyleRule> 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 15:40:06 +01:00
template<typename T>
[[nodiscard]] NonnullRefPtr<StyleRule> consume_an_at_rule(TokenStream<T>&);
template<typename T>
[[nodiscard]] RefPtr<StyleRule> consume_a_qualified_rule(TokenStream<T>&);
template<typename T>
[[nodiscard]] Vector<DeclarationOrAtRule> consume_a_list_of_declarations(TokenStream<T>&);
template<typename T>
LibWeb: Convert style declarations and at rules into CSSRules
2021-07-08 21:53:22 +01:00
[[nodiscard]] Optional<StyleDeclarationRule> 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 15:40:06 +01:00
template<typename T>
LibWeb: Convert style declarations and at rules into CSSRules
2021-07-08 21:53:22 +01:00
[[nodiscard]] StyleComponentValueRule 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: Convert style declarations and at rules into CSSRules
2021-07-08 21:53:22 +01:00
[[nodiscard]] NonnullRefPtr<StyleBlockRule> 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 15:40:06 +01:00
template<typename T>
LibWeb: Convert style declarations and at rules into CSSRules
2021-07-08 21:53:22 +01:00
[[nodiscard]] NonnullRefPtr<StyleFunctionRule> 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 17:41:47 +01:00
LibWeb: Parse CSS `<general-enclosed>`
2021-11-22 17:27:09 +00:00
[[nodiscard]] Optional<GeneralEnclosed> parse_general_enclosed(TokenStream<StyleComponentValueRule>&);
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: 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
RefPtr<CSSRule> parse_font_face_rule(TokenStream<StyleComponentValueRule>&);
LibWeb: Convert style declarations and at rules into CSSRules
2021-07-08 21:53:22 +01:00
[[nodiscard]] RefPtr<CSSRule> convert_to_rule(NonnullRefPtr<StyleRule>);
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
[[nodiscard]] RefPtr<PropertyOwningCSSStyleDeclaration> convert_to_style_declaration(Vector<DeclarationOrAtRule> declarations);
LibWeb: Use a string instead of an internal Parser class in Supports Now that we can serialize CSS tokens, we can just hold a string and then re-parse it when the Supports is evaluated. This feels a little weird, but it only happens once so it's not going to slow it down much, and it keep the API cleaner.
2021-11-24 16:11:04 +00:00
[[nodiscard]] Optional<StyleProperty> convert_to_style_property(StyleDeclarationRule 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: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
class Dimension {
public:
LibWeb: Parse Angle/Frequency/Resolution/Time types
2022-02-22 12:48:59 +00:00
Dimension(Angle&& value)
: m_value(move(value))
{
}
Dimension(Frequency&& value)
: m_value(move(value))
{
}
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
Dimension(Length&& value)
: m_value(move(value))
{
}
Dimension(Percentage&& value)
: m_value(move(value))
{
}
LibWeb: Parse Angle/Frequency/Resolution/Time types
2022-02-22 12:48:59 +00:00
Dimension(Resolution&& value)
: m_value(move(value))
{
}
Dimension(Time&& value)
: m_value(move(value))
{
}
bool is_angle() const;
Angle angle() const;
bool is_angle_percentage() const;
AnglePercentage angle_percentage() const;
bool is_frequency() const;
Frequency frequency() const;
bool is_frequency_percentage() const;
FrequencyPercentage frequency_percentage() const;
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
bool is_length() const;
Length length() const;
LibWeb: Parse Angle/Frequency/Resolution/Time types
2022-02-22 12:48:59 +00:00
bool is_length_percentage() const;
LengthPercentage length_percentage() const;
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
bool is_percentage() const;
Percentage percentage() const;
LibWeb: Parse Angle/Frequency/Resolution/Time types
2022-02-22 12:48:59 +00:00
bool is_resolution() const;
Resolution resolution() const;
bool is_time() const;
Time time() const;
bool is_time_percentage() const;
TimePercentage time_percentage() const;
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
private:
LibWeb: Parse Angle/Frequency/Resolution/Time types
2022-02-22 12:48:59 +00:00
Variant<Angle, Frequency, Length, Percentage, Resolution, Time> m_value;
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
};
Optional<Dimension> parse_dimension(StyleComponentValueRule const&);
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
Optional<Color> parse_color(StyleComponentValueRule const&);
Optional<Length> parse_length(StyleComponentValueRule const&);
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
Optional<Ratio> parse_ratio(TokenStream<StyleComponentValueRule>&);
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
enum class AllowedDataUrlType {
None,
Image,
};
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
Optional<AK::URL> parse_url_function(StyleComponentValueRule const&, AllowedDataUrlType = AllowedDataUrlType::None);
LibWeb: Implement CSS::parse_css_value() A lot of this is not spec-compliant and copied from the old parser. In future PRs, we can revise it.
2021-07-09 21:04:34 +01:00
LibWeb: Ignore CSS properties with vendor-prefixed values For example, this CSS previously produced a lot of log spam about the `display` properties having invalid values: ```css .foo { display: -webkit-box; display: -moz-box; display: -ms-flexbox; display: -webkit-flex; display: flex; } ``` Now, it just ignores them, because we don't need to know about it. :^)
2021-09-12 19:44:35 +01:00
Result<NonnullRefPtr<StyleValue>, ParsingResult> parse_css_value(PropertyID, TokenStream<StyleComponentValueRule>&);
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
RefPtr<StyleValue> parse_css_value(StyleComponentValueRule const&);
RefPtr<StyleValue> parse_builtin_value(StyleComponentValueRule const&);
RefPtr<StyleValue> parse_dynamic_value(StyleComponentValueRule const&);
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
RefPtr<StyleValue> parse_calculated_value(Vector<StyleComponentValueRule> const&);
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
RefPtr<StyleValue> parse_dimension_value(StyleComponentValueRule const&);
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
RefPtr<StyleValue> parse_numeric_value(StyleComponentValueRule const&);
RefPtr<StyleValue> parse_identifier_value(StyleComponentValueRule const&);
RefPtr<StyleValue> parse_color_value(StyleComponentValueRule const&);
RefPtr<StyleValue> parse_string_value(StyleComponentValueRule const&);
RefPtr<StyleValue> parse_image_value(StyleComponentValueRule const&);
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>
RefPtr<StyleValue> parse_comma_separated_value_list(Vector<StyleComponentValueRule> const&, ParseFunction);
RefPtr<StyleValue> parse_simple_comma_separated_value_list(Vector<StyleComponentValueRule> const&);
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
RefPtr<StyleValue> parse_background_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_single_background_position_value(TokenStream<StyleComponentValueRule>&);
RefPtr<StyleValue> parse_single_background_repeat_value(TokenStream<StyleComponentValueRule>&);
RefPtr<StyleValue> parse_single_background_size_value(TokenStream<StyleComponentValueRule>&);
RefPtr<StyleValue> parse_border_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_border_radius_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_border_radius_shorthand_value(Vector<StyleComponentValueRule> const&);
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 19:56:25 +00:00
RefPtr<StyleValue> parse_content_value(Vector<StyleComponentValueRule> const&);
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
RefPtr<StyleValue> parse_flex_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_flex_flow_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_font_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_font_family_value(Vector<StyleComponentValueRule> const&, size_t start_index = 0);
RefPtr<StyleValue> parse_list_style_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_overflow_value(Vector<StyleComponentValueRule> const&);
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,
};
RefPtr<StyleValue> parse_shadow_value(Vector<StyleComponentValueRule> const&, AllowInsetKeyword);
RefPtr<StyleValue> parse_single_shadow_value(TokenStream<StyleComponentValueRule>&, AllowInsetKeyword);
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
RefPtr<StyleValue> parse_text_decoration_value(Vector<StyleComponentValueRule> const&);
RefPtr<StyleValue> parse_transform_value(Vector<StyleComponentValueRule> const&);
LibWeb: Parse the CSS transform-origin property This is almost a PositionStyleValue, but it's serialized differently, so let's use a StyleValueList with 2 length-percentage values.
2022-03-21 19:11:06 +01:00
RefPtr<StyleValue> parse_transform_origin_value(Vector<StyleComponentValueRule> const&);
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: Parse calc() values in new CSS Parser This is a port of the code from DeprecatedCSSParser, to work with CSS Tokens and TokenStream. I've modified it as little as possible.
2021-07-28 16:30:59 +01:00
// calc() parsing, according to https://www.w3.org/TR/css-values-3/#calc-syntax
LibWeb: Remove ParsingContext parameter from private CSS Parser methods This was only needed when they were all static.
2021-11-05 17:41:04 +00:00
OwnPtr<CalculatedStyleValue::CalcSum> parse_calc_sum(TokenStream<StyleComponentValueRule>&);
OwnPtr<CalculatedStyleValue::CalcProduct> parse_calc_product(TokenStream<StyleComponentValueRule>&);
Optional<CalculatedStyleValue::CalcValue> parse_calc_value(TokenStream<StyleComponentValueRule>&);
OwnPtr<CalculatedStyleValue::CalcNumberSum> parse_calc_number_sum(TokenStream<StyleComponentValueRule>&);
OwnPtr<CalculatedStyleValue::CalcNumberProduct> parse_calc_number_product(TokenStream<StyleComponentValueRule>&);
Optional<CalculatedStyleValue::CalcNumberValue> parse_calc_number_value(TokenStream<StyleComponentValueRule>&);
OwnPtr<CalculatedStyleValue::CalcProductPartWithOperator> parse_calc_product_part_with_operator(TokenStream<StyleComponentValueRule>&);
OwnPtr<CalculatedStyleValue::CalcSumPartWithOperator> parse_calc_sum_part_with_operator(TokenStream<StyleComponentValueRule>&);
OwnPtr<CalculatedStyleValue::CalcNumberProductPartWithOperator> parse_calc_number_product_part_with_operator(TokenStream<StyleComponentValueRule>& tokens);
OwnPtr<CalculatedStyleValue::CalcNumberSumPartWithOperator> parse_calc_number_sum_part_with_operator(TokenStream<StyleComponentValueRule>&);
OwnPtr<CalculatedStyleValue::CalcSum> parse_calc_expression(Vector<StyleComponentValueRule> const&);
LibWeb: Parse calc() values in new CSS Parser This is a port of the code from DeprecatedCSSParser, to work with CSS Tokens and TokenStream. I've modified it as little as possible.
2021-07-28 16:30:59 +01:00
LibWeb: Combine identical relative/regular selector parsing functions
2022-03-17 19:29:40 +00:00
Result<NonnullRefPtr<Selector>, ParsingResult> parse_complex_selector(TokenStream<StyleComponentValueRule>&, SelectorType);
LibWeb: Rename CSS::Parser::SelectorParsingResult => ParsingResult I'm going to use it for non-selector purposes too, so the name needed to change.
2021-09-12 19:29:47 +01:00
Result<Selector::CompoundSelector, ParsingResult> parse_compound_selector(TokenStream<StyleComponentValueRule>&);
LibWeb: Parse CSS selectors according to the spec The spec does not directly tell us how to parse selectors, so there are likely some bugs here, but I've used the spec language where possible. This is very much based on the previous selector parsing code. Any parse error inside a selector makes the entire SelectorList invalid, so nothing is returned.
2021-07-23 16:13:07 +01:00
Optional<Selector::Combinator> parse_selector_combinator(TokenStream<StyleComponentValueRule>&);
LibWeb: Pull out larger parsing parts from Parser::parse_simple_selector This lowers its cognitive complexity from 271 to under 100. The new `parse_pseudo_simple_selector` still has a complexity of 114.
2022-03-13 18:17:37 +01:00
Result<Selector::SimpleSelector, ParsingResult> parse_attribute_simple_selector(StyleComponentValueRule const&);
Result<Selector::SimpleSelector, ParsingResult> parse_pseudo_simple_selector(TokenStream<StyleComponentValueRule>&);
LibWeb: Rename CSS::Parser::SelectorParsingResult => ParsingResult I'm going to use it for non-selector purposes too, so the name needed to change.
2021-09-12 19:29:47 +01:00
Result<Selector::SimpleSelector, ParsingResult> parse_simple_selector(TokenStream<StyleComponentValueRule>&);
LibWeb: Parse CSS selectors according to the spec The spec does not directly tell us how to parse selectors, so there are likely some bugs here, but I've used the spec language where possible. This is very much based on the previous selector parsing code. Any parse error inside a selector makes the entire SelectorList invalid, so nothing is returned.
2021-07-23 16:13:07 +01:00
LibWeb: Parse media queries! :^) While not complete by any means, we are now compatible with the [level 3 spec](https://www.w3.org/TR/css3-mediaqueries/#syntax) and some parts of [level 4.](https://www.w3.org/TR/mediaqueries-4#mq-syntax) Compatibility with level 4+ requires: - Implementing the range syntax: `(800px <= width <= 1200px)` - Parsing `<general-enclosed>`, which represents syntax that is not yet used but they may use in the future.
2021-09-29 20:54:06 +01:00
NonnullRefPtr<MediaQuery> parse_media_query(TokenStream<StyleComponentValueRule>&);
LibWeb: Rewrite media-query parsing to match spec grammar Past me decided that the grammar was overly verbose and I could do it better myself. Which seemed fine until the spec changed and I didn't know how to integrate the changes. Lesson learned! :^) Rather than have a function for every single part of the grammar, I have written some as lambdas, and combned `<media-condition>` and `<media-condition-without-or>` into one function. But otherwise it's close to the spec, with comments listing the part of the grammar being parsed, so hopefully it will be easier to make future adjustments! This does not add any new functionality.
2022-01-01 11:44:44 +00:00
OwnPtr<MediaCondition> parse_media_condition(TokenStream<StyleComponentValueRule>&, MediaCondition::AllowOr allow_or);
Optional<MediaFeature> parse_media_feature(TokenStream<StyleComponentValueRule>&);
Optional<MediaQuery::MediaType> parse_media_type(TokenStream<StyleComponentValueRule>&);
OwnPtr<MediaCondition> parse_media_in_parens(TokenStream<StyleComponentValueRule>&);
LibWeb: Only try parsing valid types of media-feature values This resolves the ambiguity between whether a single number is a number or a ratio. :^) Also removed the "no more tokens" checks from deea129b8c730e717dc1a83c2eafa81b0e2b34ec - that logic was completely wrong, since there are always tokens after a value in the `(123 < foo < 456)` syntax.
2022-03-08 16:37:22 +00:00
Optional<MediaFeatureValue> parse_media_feature_value(MediaFeatureID, TokenStream<StyleComponentValueRule>&);
LibWeb: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 12:56:37 +01:00
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
OwnPtr<Supports::Condition> parse_supports_condition(TokenStream<StyleComponentValueRule>&);
Optional<Supports::InParens> parse_supports_in_parens(TokenStream<StyleComponentValueRule>&);
Optional<Supports::Feature> parse_supports_feature(TokenStream<StyleComponentValueRule>&);
Everywhere: Pass AK::StringView by value
2021-11-11 00:55:02 +01:00
static bool has_ignored_vendor_prefix(StringView);
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
static bool is_builtin(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: 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
struct PropertiesAndCustomProperties {
Vector<StyleProperty> properties;
HashMap<String, StyleProperty> custom_properties;
};
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 20:25:13 +01: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 17:41:47 +01:00
Tokenizer m_tokenizer;
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: 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: Spec-comment `parse_a_stylesheet()` Also introduce a `location` parameter when parsing a CSSStyleSheet. This is not provided by anyone yet.
2022-03-29 16:51:31 +01:00
RefPtr<CSS::CSSStyleSheet> parse_css_stylesheet(CSS::ParsingContext const&, StringView, Optional<AK::URL> location = {});
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
RefPtr<CSS::ElementInlineCSSStyleDeclaration> parse_css_style_attribute(CSS::ParsingContext const&, StringView, DOM::Element&);
Everywhere: Pass AK::StringView by value
2021-11-11 00:55:02 +01:00
RefPtr<CSS::StyleValue> parse_css_value(CSS::ParsingContext const&, StringView, CSS::PropertyID property_id = CSS::PropertyID::Invalid);
Optional<CSS::SelectorList> parse_selector(CSS::ParsingContext const&, StringView);
LibWeb: Implement most of CSSStyleRule.insertRule()
2021-09-29 21:12:39 +02:00
RefPtr<CSS::CSSRule> parse_css_rule(CSS::ParsingContext const&, StringView);
Everywhere: Pass AK::StringView by value
2021-11-11 00:55:02 +01:00
RefPtr<CSS::MediaQuery> parse_media_query(CSS::ParsingContext const&, StringView);
NonnullRefPtrVector<CSS::MediaQuery> parse_media_query_list(CSS::ParsingContext const&, StringView);
RefPtr<CSS::Supports> parse_css_supports(CSS::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 17:48:23 +01:00
}
Reference in a new issue Copy permalink