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

427 lines
18 KiB
C
Raw Normal View History

LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
/*
Everywhere: Use "the SerenityOS developers." in copyright headers We had some inconsistencies before: - Sometimes "The", sometimes "the" - Sometimes trailing ".", sometimes no trailing "." I picked the most common one (lowecase "the", trailing ".") and applied it to all copyright headers. By using the exact same string everywhere we can ensure nothing gets missed during a global search (and replace), and that these inconsistencies are not spread any further (as copyright headers are commonly copied to new files).
2021-04-28 22:46:44 +02:00
* Copyright (c) 2020-2021, the SerenityOS developers.
LibWeb: Parse `<urange>` as CSS::UnicodeRange Like, An+B, this is an old construct that does not fit well with modern CSS syntax, so things get a bit hairy! We have to determine which tokens match the grammar for `<urange>`, then turn those back into a string, and then parse the string differently from normal. Thankfully the spec describes in detail how to do that. :^) This is not 100% correct, since we are not using the original source text (referred to in the spec as the "representation") of the tokens, but just converting them to strings in a manual, ad-hoc way. Re-engineering the Tokenizer to keep that original text was too much of a tangent for today. In any case, we do parse `U+4???`, `U+0-100`, `U+1234`, and similar, so good enough for now!
2022-04-07 17:41:54 +01:00
* Copyright (c) 2021-2022, 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
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
#include <AK/Error.h>
LibWeb: 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/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: 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: Understand the `format()` part of a `@font-face`'s `src` This is used to skip downloading fonts in formats that we don't support. Currently we only support TTF as far as I am aware. The parts of a `src` are in a fixed order, unusually, which makes the parsing more nesty instead of loopy.
2022-03-31 21:18:54 +01:00
#include <LibWeb/CSS/FontFace.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: Move/rename StyleBlockRule to Parser::Block
2022-04-12 14:08:26 +01: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 11:43:07 +01:00
#include <LibWeb/CSS/Parser/ComponentValue.h>
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 14:36:12 +01: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 17:41:47 +01:00
#include <LibWeb/CSS/Parser/DeclarationOrAtRule.h>
LibWeb: Move/rename StyleFunctionRule to Parser::Function
2022-04-12 13:35:55 +01:00
#include <LibWeb/CSS/Parser/Function.h>
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 19:05:13 +01:00
#include <LibWeb/CSS/Parser/Rule.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: Parse `<urange>` as CSS::UnicodeRange Like, An+B, this is an old construct that does not fit well with modern CSS syntax, so things get a bit hairy! We have to determine which tokens match the grammar for `<urange>`, then turn those back into a string, and then parse the string differently from normal. Thankfully the spec describes in detail how to do that. :^) This is not 100% correct, since we are not using the original source text (referred to in the spec as the "representation") of the tokens, but just converting them to strings in a manual, ad-hoc way. Re-engineering the Tokenizer to keep that original text was too much of a tangent for today. In any case, we do parse `U+4???`, `U+0-100`, `U+1234`, and similar, so good enough for now!
2022-04-07 17:41:54 +01:00
#include <LibWeb/CSS/UnicodeRange.h>
LibWeb: Stop manually forward-declaring types in CSS Parser.h
2022-04-12 11:32:18 +01:00
#include <LibWeb/Forward.h>
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
LibWeb: Move CSS Parser into new Web::CSS::Parser namespace The goal here is to move the parser-internal classes into this namespace so they can have more convenient names without causing collisions. The Parser itself won't collide, and would be more convenient to just remain `CSS::Parser`, but having a namespace and a class with the same name makes C++ unhappy.
2022-04-12 12:00:07 +01:00
namespace Web::CSS::Parser {
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
LibWeb: 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: Make CSS ParsingContext::m_url not Optional This always has a value, so let's make that clearer.
2022-04-25 16:17:21 +01:00
explicit ParsingContext(DOM::Document const&, AK::URL);
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: Make CSS ParsingContext::m_url not Optional This always has a value, so let's make that clearer.
2022-04-25 16:17:21 +01:00
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:
LibWeb: Add StateTransaction RAII to CSS TokenStream This is modeled after the one in ISO8601Parser. It rolls back the TokenStream state automatically at the end of scope unless told to commit the changes. This should be less error-prone than remembering to manually call `rewind_to_position()` at the correct time. For convenience, a StateTransaction can have "child" transactions. When a transaction is committed, it automatically commits its parents too. This is useful in situations where you have several nested and don't want to have to remember to manually `commit()` them all.
2022-04-27 12:46:22 +01:00
class StateTransaction {
public:
explicit StateTransaction(TokenStream<T>& token_stream)
: m_token_stream(token_stream)
, m_saved_iterator_offset(token_stream.m_iterator_offset)
{
}
~StateTransaction()
{
if (!m_commit)
m_token_stream.m_iterator_offset = m_saved_iterator_offset;
}
StateTransaction create_child() { return StateTransaction(*this); }
void commit()
{
m_commit = true;
if (m_parent)
m_parent->commit();
}
private:
explicit StateTransaction(StateTransaction& parent)
: m_parent(&parent)
, m_token_stream(parent.m_token_stream)
, m_saved_iterator_offset(parent.m_token_stream.m_iterator_offset)
{
}
StateTransaction* m_parent { nullptr };
TokenStream<T>& m_token_stream;
int m_saved_iterator_offset { 0 };
bool m_commit { false };
};
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
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 StateTransaction RAII to CSS TokenStream This is modeled after the one in ISO8601Parser. It rolls back the TokenStream state automatically at the end of scope unless told to commit the changes. This should be less error-prone than remembering to manually call `rewind_to_position()` at the correct time. For convenience, a StateTransaction can have "child" transactions. When a transaction is committed, it automatically commits its parents too. This is useful in situations where you have several nested and don't want to have to remember to manually `commit()` them all.
2022-04-27 12:46:22 +01:00
StateTransaction begin_transaction() { return StateTransaction(*this); }
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
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
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: Spec-comment `parse_a_rule()` We now correctly call convert_to_rule() outside of this function. As before, I've renamed `parse_as_rule()` -> `parse_as_css_rule()` to match the free function that calls it.
2022-03-30 11:48:54 +01:00
RefPtr<CSSRule> parse_as_css_rule();
LibWeb: Bring `parse_a_declaration()` to spec and add comments User code now calls `parse_as_supports_condition()` which actually does the conversion to a StyleProperty.
2022-03-30 12:05:16 +01:00
Optional<StyleProperty> parse_as_supports_condition();
LibWeb: Bring "parse a list of declarations" closer to spec The work to create a PropertyOwningCSSStyleDeclaration is now moved to convert_to_style_declaration() instead.
2022-03-28 16:37:54 +01:00
LibWeb: Parse forgiving selector-lists `<forgiving-selector-list>` and `<forgiving-relative-selector-list>` are the same as regular selector-lists, except that an invalid selector does not make the whole list invalid. The former is used by the `:is()` pseudo-class. For example: ```css /* This entire selector-list is invalid */ .foo, .bar, !?invalid { } /* This is valid, but the "!?invalid" selector is removed */ :is(.foo, .bar, !?invalid) { } ``` Also as part of this, I've removed the `parse_a_selector(TokenStream)` and `parse_a_relative_selector(TokenStream)` methods as they don't add anything useful.
2022-03-17 15:14:01 +00:00
enum class SelectorParsingMode {
Standard,
// `<forgiving-selector-list>` and `<forgiving-relative-selector-list>`
// are handled with this parameter, not as separate functions.
// https://drafts.csswg.org/selectors/#forgiving-selector
Forgiving
};
LibWeb: Implement CSS selector parsing entry points They're still using the same parsing code, so there's a lot of room for improvement, but it's good for now.
2021-07-03 12:34:25 +01:00
// Contrary to the name, these parse a comma-separated list of selectors, according to the spec.
LibWeb: Parse forgiving selector-lists `<forgiving-selector-list>` and `<forgiving-relative-selector-list>` are the same as regular selector-lists, except that an invalid selector does not make the whole list invalid. The former is used by the `:is()` pseudo-class. For example: ```css /* This entire selector-list is invalid */ .foo, .bar, !?invalid { } /* This is valid, but the "!?invalid" selector is removed */ :is(.foo, .bar, !?invalid) { } ``` Also as part of this, I've removed the `parse_a_selector(TokenStream)` and `parse_a_relative_selector(TokenStream)` methods as they don't add anything useful.
2022-03-17 15:14:01 +00:00
Optional<SelectorList> parse_as_selector(SelectorParsingMode = SelectorParsingMode::Standard);
Optional<SelectorList> parse_as_relative_selector(SelectorParsingMode = SelectorParsingMode::Standard);
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
LibWeb: 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: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
static RefPtr<StyleValue> parse_css_value(Badge<StyleComputer>, ParsingContext const&, PropertyID, Vector<ComponentValue> const&);
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
LibWeb: 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: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
enum class ParseError {
LibWeb: Ignore vendor-prefixed pseudo-element/classes in selectors Our debug logging when we fail to parse a legitimate selector, is less useful when it's hidden among selectors that don't parse because they contain vendor-prefixed pseudo-elements and classes. So, now we specifically ignore these and don't produce a log message.
2021-09-12 17:47:58 +01:00
IncludesIgnoredVendorPrefix,
LibWeb: Return SelectorParsingResult from all selector parsing functions This will allow us to know why a selector failed to parse, in situations where that matters. (Like, when a selector includes vendor prefixes...)
2021-09-12 17:42:11 +01:00
SyntaxError,
};
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
template<typename T>
using ParseErrorOr = ErrorOr<T, ParseError>;
LibWeb: Return SelectorParsingResult from all selector parsing functions This will allow us to know why a selector failed to parse, in situations where that matters. (Like, when a selector includes vendor prefixes...)
2021-09-12 17:42:11 +01:00
LibWeb: Implement and use "parse a CSS stylesheet" algorithm `parse_a_stylesheet()` should not do any conversion on its rules. This change corrects that. There are other places where we get this wrong, but one thing at a time. :^)
2022-03-29 14:13:39 +01:00
// "Parse a stylesheet" is intended to be the normal parser entry point, for parsing stylesheets.
struct ParsedStyleSheet {
Optional<AK::URL> location;
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 19:05:13 +01:00
NonnullRefPtrVector<Rule> rules;
LibWeb: Implement and use "parse a CSS stylesheet" algorithm `parse_a_stylesheet()` should not do any conversion on its rules. This change corrects that. There are other places where we get this wrong, but one thing at a time. :^)
2022-03-29 14:13:39 +01:00
};
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
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: 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 11:36:38 +01: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 17:06:48 +01: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 19:05:13 +01:00
NonnullRefPtrVector<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 11:48:54 +01:00
// "Parse a rule" is intended for use by the CSSStyleSheet#insertRule method, and similar functions which might exist, which parse text into a single rule.
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 19:05:13 +01: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 11:48:54 +01:00
LibWeb: Bring `parse_a_declaration()` to spec and add comments User code now calls `parse_as_supports_condition()` which actually does the conversion to a StyleProperty.
2022-03-30 12:05:16 +01:00
// "Parse a declaration" is used in @supports conditions. [CSS3-CONDITIONAL]
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 14:36:12 +01:00
Optional<Declaration> parse_a_declaration(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_declarations()` The `parse_as_list_of_declarations()` public method is unused and will not be used by any user code so has been removed.
2022-03-30 12:23:07 +01:00
LibWeb: Implement and use `parse_a_style_blocks_contents()`
2022-03-30 16:44:13 +01: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 12:23:07 +01: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 17:06:48 +01: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 16:37:54 +01:00
Vector<DeclarationOrAtRule> parse_a_list_of_declarations(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_component_value()`
2022-03-30 12:32:42 +01:00
// "Parse a component value" is for things that need to consume a single value, like the parsing rules for attr().
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<ComponentValue> parse_a_component_value(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_component_values()`
2022-03-30 12:39:36 +01:00
// "Parse a list of component values" is for the contents of presentational attributes, which parse text into a single declaration’s value, or for parsing a stand-alone selector [SELECT] or list of Media Queries [MEDIAQ], as in Selectors API or the media HTML attribute.
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Vector<ComponentValue> parse_a_list_of_component_values(TokenStream<T>&);
LibWeb: Spec-comment `parse_a_list_of_component_values()`
2022-03-30 12:39:36 +01:00
LibWeb: Clarify naming and publicity of CSS Parser methods `parse_as_foo()` implies that the Parser's internal data is used, whereas `parse_a_foo()` implies that the passed-in data is used. Also, made all the `parse_a_foo()` methods private, as they are only required within the Parser, and this makes the API clearer to outsiders. The `parse_a(s)_foo()` naming is a little awkward, but it comes from section 5.3 of the spec, so seemed worth keeping: https://www.w3.org/TR/css-syntax-3/#parser-entry-points
2021-07-30 17:06:48 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Vector<Vector<ComponentValue>> parse_a_comma_separated_list_of_component_values(TokenStream<T>&);
LibWeb: Combine identical relative/regular selector parsing functions
2022-03-17 19:29:40 +00:00
enum class SelectorType {
Standalone,
Relative
};
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
ParseErrorOr<SelectorList> parse_a_selector_list(TokenStream<T>&, SelectorType, SelectorParsingMode = SelectorParsingMode::Standard);
LibWeb: Combine identical relative/regular selector parsing functions
2022-03-17 19:29:40 +00:00
LibWeb: Sketch out media-query parsing This does everything except actually parse the individual media queries.
2021-09-29 12:56:37 +01:00
template<typename T>
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: Handle trailing tokens outside of parse_a_n_plus_b_pattern() parse_a_n_plus_b_pattern()'s job is to parse as much of the TokenStream as it can as a An+B, and then stop. The caller can then deal with any trailing tokens as it wishes.
2022-04-27 12:03:42 +01:00
Optional<Selector::SimpleSelector::ANPlusBPattern> parse_a_n_plus_b_pattern(TokenStream<ComponentValue>&);
LibWeb: Import new CSS parser It's not finished or hooked up to anything yet, but let's get it into the tree so we can continue working on it. Original work by @stelar7.
2021-03-22 17:41:47 +01:00
LibWeb: 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: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 19:05:13 +01:00
[[nodiscard]] NonnullRefPtrVector<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 15:40:06 +01: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 19:05:13 +01: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 15:40:06 +01: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 19:05:13 +01: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 15:40:06 +01:00
template<typename T>
LibWeb: Implement and use `parse_a_style_blocks_contents()`
2022-03-30 16:44:13 +01: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 15:40:06 +01: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 14:36:12 +01: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 15:40:06 +01:00
template<typename T>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
[[nodiscard]] ComponentValue consume_a_component_value(TokenStream<T>&);
LibWeb: Use TokenStream in CSS Parser Each method can either be called with a TokenStream, or with no arguments to replicate the previous behaviour.
2021-07-03 15:40:06 +01:00
template<typename T>
LibWeb: Move/rename StyleBlockRule to Parser::Block
2022-04-12 14:08:26 +01: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 15:40:06 +01:00
template<typename T>
LibWeb: Move/rename StyleFunctionRule to Parser::Function
2022-04-12 13:35:55 +01: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 17:41:47 +01:00
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<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 15:54:16 +01:00
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
RefPtr<CSSRule> parse_font_face_rule(TokenStream<ComponentValue>&);
LibWeb: Understand the `format()` part of a `@font-face`'s `src` This is used to skip downloading fonts in formats that we don't support. Currently we only support TTF as far as I am aware. The parts of a `src` are in a fixed order, unusually, which makes the parsing more nesty instead of loopy.
2022-03-31 21:18:54 +01:00
Vector<FontFace::Source> parse_font_face_src(TokenStream<ComponentValue>&);
LibWeb: Parse `@font-face` rules This is very limited for now, only caring about `font-family` and `src`.
2022-03-28 20:32:28 +01:00
LibWeb: Rename StyleRule -> Rule This name is what's used in the spec, and is a little less confusing.
2022-04-12 19:05:13 +01:00
RefPtr<CSSRule> convert_to_rule(NonnullRefPtr<Rule>);
LibWeb: Remove redundant `[[nodiscard]]` from CSS Parser methods Optional and smart-pointers are already `[[nodiscard]]` so functions returning them do not need to be declared as such.
2022-03-30 16:50:47 +01:00
RefPtr<PropertyOwningCSSStyleDeclaration> convert_to_style_declaration(Vector<DeclarationOrAtRule> declarations);
LibWeb: Rename StyleDeclarationRule -> Declaration This is the term used in the CSS specs.
2022-03-31 14:36:12 +01:00
Optional<StyleProperty> convert_to_style_property(Declaration const&);
LibWeb: Convert CSS::Parser methods to return desired types This is very much stubbed out for now. Most notably is Parser::convert_rule() where most of the conversion will happen from the parser's internal rule classes to CSSRule and its children.
2021-07-09 16:34:29 +01:00
LibWeb: 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
};
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<Dimension> parse_dimension(ComponentValue const&);
LibWeb: Parse rgb and hsl functions according to CSS Module Level 4 Implement parsing of rgb(..) and hsl(..) in both the modern level 4 syntax without commas, and the legacy syntax with commas. The parser accepts non-integer numbers but rounds to integer values for now.
2022-06-09 19:08:57 +02:00
Optional<Color> parse_rgb_or_hsl_color(StringView function_name, 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 11:43:07 +01:00
Optional<Color> parse_color(ComponentValue const&);
Optional<Length> parse_length(ComponentValue const&);
Optional<Ratio> parse_ratio(TokenStream<ComponentValue>&);
LibWeb: Parse `<urange>` as CSS::UnicodeRange Like, An+B, this is an old construct that does not fit well with modern CSS syntax, so things get a bit hairy! We have to determine which tokens match the grammar for `<urange>`, then turn those back into a string, and then parse the string differently from normal. Thankfully the spec describes in detail how to do that. :^) This is not 100% correct, since we are not using the original source text (referred to in the spec as the "representation") of the tokens, but just converting them to strings in a manual, ad-hoc way. Re-engineering the Tokenizer to keep that original text was too much of a tangent for today. In any case, we do parse `U+4???`, `U+0-100`, `U+1234`, and similar, so good enough for now!
2022-04-07 17:41:54 +01:00
Optional<UnicodeRange> parse_unicode_range(TokenStream<ComponentValue>&);
LibWeb: Use StateTransaction for UnicodeRange parsing ...and change how the two parsing steps fit together. The two steps were previously quite muddled. Both worked with the TokenStream directly, and both were responsible for rewinding that stream if there was an error. This is both confusing and also made it impossible to replace the rewinding with StateTransactions. This commit more clearly divides the work between the two functions: One parses ComponentValues and produces a string, and the other parses that string to produce the UnicodeRange. It also replaces manual rewinding in the former with StateTransactions.
2022-04-27 19:56:05 +01:00
Optional<UnicodeRange> parse_unicode_range(StringView);
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: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<AK::URL> parse_url_function(ComponentValue const&, AllowedDataUrlType = AllowedDataUrlType::None);
LibWeb: Parse the linear-gradient() CSS function This should parse linear-gradient()s as defined in the W3 spec https://drafts.csswg.org/css-images/#linear-gradients. Note: This currently cannot parse multi-position color stops, these are shown on MDN and work in Firefox and Chrome, though do not seem to be defined in the spec. See: https://developer.mozilla.org/en-US/docs/Web/CSS/gradient/linear-gradient#gradient_with_multi-position_color_stops P.s. This also allows -webkit-linear-gradient for compatibility.
2022-07-12 00:15:05 +01:00
RefPtr<StyleValue> parse_linear_gradient_function(ComponentValue const&);
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
ParseErrorOr<NonnullRefPtr<StyleValue>> parse_css_value(PropertyID, TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
RefPtr<StyleValue> parse_css_value(ComponentValue const&);
RefPtr<StyleValue> parse_builtin_value(ComponentValue const&);
RefPtr<StyleValue> parse_dynamic_value(ComponentValue const&);
RefPtr<StyleValue> parse_calculated_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_dimension_value(ComponentValue const&);
RefPtr<StyleValue> parse_numeric_value(ComponentValue const&);
RefPtr<StyleValue> parse_identifier_value(ComponentValue const&);
RefPtr<StyleValue> parse_color_value(ComponentValue const&);
LibWeb: Parse rect style value Add ability to parse a rect when it is used as the value of a style property.
2022-07-31 18:46:35 +02:00
RefPtr<StyleValue> parse_rect_value(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 11:43:07 +01:00
RefPtr<StyleValue> parse_string_value(ComponentValue const&);
RefPtr<StyleValue> parse_image_value(ComponentValue 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>
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
RefPtr<StyleValue> parse_comma_separated_value_list(Vector<ComponentValue> const&, ParseFunction);
RefPtr<StyleValue> parse_simple_comma_separated_value_list(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_background_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_single_background_position_value(TokenStream<ComponentValue>&);
RefPtr<StyleValue> parse_single_background_repeat_value(TokenStream<ComponentValue>&);
RefPtr<StyleValue> parse_single_background_size_value(TokenStream<ComponentValue>&);
RefPtr<StyleValue> parse_border_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_border_radius_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_border_radius_shorthand_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_content_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_flex_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_flex_flow_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_font_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_font_family_value(Vector<ComponentValue> const&, size_t start_index = 0);
RefPtr<StyleValue> parse_list_style_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_overflow_value(Vector<ComponentValue> 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,
};
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
RefPtr<StyleValue> parse_shadow_value(Vector<ComponentValue> const&, AllowInsetKeyword);
RefPtr<StyleValue> parse_single_shadow_value(TokenStream<ComponentValue>&, AllowInsetKeyword);
RefPtr<StyleValue> parse_text_decoration_value(Vector<ComponentValue> const&);
LibWeb: Allow multiple text-decoration-lines The spec grammar for `text-decoration-line` is: `none | [ underline || overline || line-through || blink ]` Which means that it's either `none`, or any combination of the other values. This patch makes that parse for `text-decoration-line` and `text-decoration`, stores the results as a Vector, and adjusts `paint_text_decoration()` to run as a loop over all the values that are provided. As noted, storing a Vector of values is a bit wasteful, as they could be stored as flags in a single `u8`. But I was getting too confused trying to do that in a nice way.
2022-04-14 16:22:35 +01:00
RefPtr<StyleValue> parse_text_decoration_line_value(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
RefPtr<StyleValue> parse_transform_value(Vector<ComponentValue> const&);
RefPtr<StyleValue> parse_transform_origin_value(Vector<ComponentValue> const&);
LibWeb: Parse grid-template-columns and grid-template-rows Add functionality to begin parsing grid-template-columns and grid-template-rows. There are still things to be added, like parsing functions, but I would say a couple of the major points are already adressed like length, percentage, and flexible-length.
2022-08-23 19:49:07 +02:00
RefPtr<StyleValue> parse_grid_track_sizes(Vector<ComponentValue> 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: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
OwnPtr<CalculatedStyleValue::CalcSum> parse_calc_sum(TokenStream<ComponentValue>&);
OwnPtr<CalculatedStyleValue::CalcProduct> parse_calc_product(TokenStream<ComponentValue>&);
Optional<CalculatedStyleValue::CalcValue> parse_calc_value(TokenStream<ComponentValue>&);
OwnPtr<CalculatedStyleValue::CalcNumberSum> parse_calc_number_sum(TokenStream<ComponentValue>&);
OwnPtr<CalculatedStyleValue::CalcNumberProduct> parse_calc_number_product(TokenStream<ComponentValue>&);
Optional<CalculatedStyleValue::CalcNumberValue> parse_calc_number_value(TokenStream<ComponentValue>&);
OwnPtr<CalculatedStyleValue::CalcProductPartWithOperator> parse_calc_product_part_with_operator(TokenStream<ComponentValue>&);
OwnPtr<CalculatedStyleValue::CalcSumPartWithOperator> parse_calc_sum_part_with_operator(TokenStream<ComponentValue>&);
OwnPtr<CalculatedStyleValue::CalcNumberProductPartWithOperator> parse_calc_number_product_part_with_operator(TokenStream<ComponentValue>& tokens);
OwnPtr<CalculatedStyleValue::CalcNumberSumPartWithOperator> parse_calc_number_sum_part_with_operator(TokenStream<ComponentValue>&);
OwnPtr<CalculatedStyleValue::CalcSum> parse_calc_expression(Vector<ComponentValue> const&);
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
ParseErrorOr<NonnullRefPtr<Selector>> parse_complex_selector(TokenStream<ComponentValue>&, SelectorType);
ParseErrorOr<Optional<Selector::CompoundSelector>> parse_compound_selector(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
Optional<Selector::Combinator> parse_selector_combinator(TokenStream<ComponentValue>&);
LibWeb: Replace Result with ErrorOr in CSS Parser ...using a ParseErrorOr type alias. This lets us replace a bunch of manual error-checking with TRY. :^) I also replaced the ParsingResult::Done value with returning an Optional. I wasn't happy with treating "Done" as an error when I first wrote this, and this makes a clear distinction between the two.
2022-04-27 11:04:16 +01:00
ParseErrorOr<Selector::SimpleSelector> parse_attribute_simple_selector(ComponentValue const&);
ParseErrorOr<Selector::SimpleSelector> parse_pseudo_simple_selector(TokenStream<ComponentValue>&);
ParseErrorOr<Optional<Selector::SimpleSelector>> parse_simple_selector(TokenStream<ComponentValue>&);
LibWeb: Rename StyleComponentValueRule -> ComponentValue "Component value" is the term used in the spec, and it doesn't conflict with any other types, so let's use the shorter name. :^) Also, this doesn't need to be friends with the Parser any more.
2022-03-31 11:43:07 +01:00
NonnullRefPtr<MediaQuery> parse_media_query(TokenStream<ComponentValue>&);
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 15:54:16 +01:00
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: Move CSS Parser into new Web::CSS::Parser namespace The goal here is to move the parser-internal classes into this namespace so they can have more convenient names without causing collisions. The Parser itself won't collide, and would be more convenient to just remain `CSS::Parser`, but having a namespace and a class with the same name makes C++ unhappy.
2022-04-12 12:00:07 +01:00
RefPtr<CSS::CSSStyleSheet> parse_css_stylesheet(CSS::Parser::ParsingContext const&, StringView, Optional<AK::URL> location = {});
RefPtr<CSS::ElementInlineCSSStyleDeclaration> parse_css_style_attribute(CSS::Parser::ParsingContext const&, StringView, DOM::Element&);
RefPtr<CSS::StyleValue> parse_css_value(CSS::Parser::ParsingContext const&, StringView, CSS::PropertyID property_id = CSS::PropertyID::Invalid);
Optional<CSS::SelectorList> parse_selector(CSS::Parser::ParsingContext const&, StringView);
RefPtr<CSS::CSSRule> parse_css_rule(CSS::Parser::ParsingContext const&, StringView);
RefPtr<CSS::MediaQuery> parse_media_query(CSS::Parser::ParsingContext const&, StringView);
NonnullRefPtrVector<CSS::MediaQuery> parse_media_query_list(CSS::Parser::ParsingContext const&, StringView);
RefPtr<CSS::Supports> parse_css_supports(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 17:48:23 +01:00
}
Reference in a new issue Copy permalink