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--;` :^)
... 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.
The name is a little awkward, but this corresponds to the condition of a
`@supports` rule or the `CSS.supports("")` function.
A supports query only gets evaluated once, since its condition cannot
change during runtime. (We either support something or we don't, and the
spec specifically mentions that user preferences that disable features
do not affect the result here.) We keep a representation of it around
though, so that it can be serialized if needed. This is a little awkward
since we hold onto a `StyleDeclarationRule` which should be an internal
Parser class. This means making some Parser functions more public.
Potentially we could evaluate the Supports inside the Parser, and have
it only store a String representation of itself. But this works for now.
:^)
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.
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()`.
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.
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. :^)
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.
This patch moves the CSS property+value storage down to a new subclass
of CSSStyleDeclaration called PropertyOwningCSSStyleDeclaration.
The JavaScript wrapper for CSSStyleDeclaration now calls virtual
functions on the C++ object.
This is preparation for supporting computed style CSSStyleDeclaration
objects which won't have internal property storage, but rather an
internal element pointer. :^)
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.
Apart from now gathering comma-separated font-family names into a
StyleValueList, this also corrects the logic for parsing a single
font-family. Previously, we did not handle unquoted font names at all,
and now they are handled including when they are several words separated
by whitespace.
Modified the logic for `font` to use `parse_font_family_value()`.
`FontStyleValue.font_families()` is now a StyleValueList instead of a
vector, so that it can be better handled in StyleResolver.
We also finally remove the CSS::ParsingContext in
set_property_expanding_shorthands(). :^)
This wraps an x and y background-repeat value. Potentially, we could use
this in place of the background-repeat-x and background-repeat-y
pseudo-properties, but for now StyleResolver splits it into those
properties, like it did before.
This parses the elliptical border-radius values, though currently we
only support circular ones. So, to_length() is overloaded to return the
horizontal-radius. This means the code in Layout/Node.cpp does not need
to change for now.
This is not just moving the code from StyleResolver to Parser. The logic
has changed to allow for the `flex-basis` to come before or after the
`flex-grow/shrink` values, as well as handle the special one-value
cases.
Also added test cases to flex.html to check the parsing. It does parse
correctly, but elements with `flex-basis: auto` do not calculate their
width correctly.
Modified text-decoration.html to better test that the values can be in
any order, and that it adopts the color from the `color` property if no
decoration color is specified. Right now, it always does because we do
not support a different decoration color. Later, we need to support the
`currentcolor` special CSS value for this purpose.
Yes, the name is silly, but it's a StyleValue for list-style, so...
yeah. :^)
Since `list-style-type` and `list-style-image` can both have `none` as a
value, and can appear in any order, we have to handle it separately, and
then assign either or both of those to `none` depending on how many
`none`s there are, and whether those sub-properties already have values.
Added some extra test cases to lists.html to cover list-style-image and
list-style-position parts of the list-style shorthand, and the `none`
values.
This one represents one secton of a `background` property, since it can
have multiple background values separated by commas. Eventually, we will
represent that as a List of BackgroundStyleValues.
Also modified some background-foo properties in StyleResolver so that
the is_background_x() functions could be removed.
I realized that our handling of var() in shorthand properties is wrong,
so have been removing the is_builtin_or_dynamic() calls from the parsing
code for shorthands. This broke our var() test page, so I have replaced
the use of 'background' with 'background-color' there.
After working with the code for a while, it makes more sense to put all
the parsing in Parser, instead of some of it living in StyleResolver.
That means our current ValueListStyleValue needs to be replaced with
specific StyleValue types for the properties that are shorthands or
otherwise combine several values together.
Here we implement FontStyleProperty, which represents a `font` CSS
property.
Also adjusted the fonts.html test page so that font-weights are featured
in test cases without things we do not yet support.
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.
`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
Previous multi-value properties use a ValueListStyleValue, which then
gets parsed into its sub-properties in the StyleResolver. However, that
is not ideal, especially as it exposes StyleResolver to the inner
workings of the Parser and Tokenizer, which it should not need to know
about.
The way `box-shadow` was implemented as a StyleValue subclass means that
the parsing can happen inside the Parser instead, which seems like a
better solution. Converting the other complicated cases (background,
font, list-style) is on my todo list for later.
This lets us get the Length and Color values directly, without having to
create a StyleValue object and then throw it away again, when parsing
the box-shadow property in the next commit.
Parsing this pattern from CSS tokens turns out to be slightly crazy, but
thankfully well documented in the spec.
The spec lists the cases in order of simple -> complicated, but this
would cause problems in code, since `<n-dimension> <signed-.integer>`
would never by reached, as `<n-dimension>` comes before. Instead, I
have grouped them by their first token.
Also renamed the NthChildPattern class to ANPlusBPattern, to match spec
terminology.
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.
Also added css-import.html, which tests the 3 syntax variations on
`@import` statements. Note that the optional media-query parameter to
`@import` is not handled yet.
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.
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.
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. :^)
