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.
StyleValueList is a list of StyleValues of the same type, for use in
properties like `margin` which accept a variable number of arguments.
I had originally hoped to simply swap the old ValueListStyleValue from
being a list of ComponentValues to one of StyleValues, but I can see now
that I will need to have both for a little while, so renamed the old
is_value_list() to is_component_value_list() temporarily.
I had accidentally parsed it in `parse_builtin_or_dynamic_value()`
instead of `parse_length()` before, which was confusing, so now it's
parsed along with other Lengths.
Whether it should be a Length is up for debate, and has been tripping me
up a few times, but a lot of code expects it to be one. For now, an
'auto' Length value (or any other value which overloads `is_auto()`)
also claims to be a `ValueID::Auto` identifier.
A '0' token can be interpreted both as a Number, and as a Length. This
is problematic as in our CSS parser, we often call parse_css_value()
first, to figure out what something is, and then assign it. So we do not
know in advance whether we want a Length or not. Previously, it always
got parsed as a Length, and then every place that expected a
NumericStyleValue had to also check for a Length(0), which is easy to
forget to do.
In particular, this was causing issues with the `flex` property parsing.
To solve this, we now always parse 0 as a NumericStyleValue, and NSVs of
0 pretend to be a Length(0px) when asked. In two places, we were casting
to a LengthStyleValue* based on is_length(), which no longer works, so
those have been adjusted to use `StyleValue::to_length()` instead. They
also now check for `is_numeric()` first, to avoid the extra conversion
to a Length and back.
Possibly this opens up new issues elsewhere. In my testing it seems
fine, but until we can get CSS test suites running, it's hard to know
for certain.
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.
As the new CSS parser tokenizes its input, we can no longer easily
rely on a StringStyleValue for multi-value properties. (eg, border)
ValueListStyleValue lets us wrap all of the ComponentValues that
the Parser produced for one declaration, as a single StyleValue, to
then be parsed into StyleValues by the StyleResolver.
Originally, I wanted it to be a list of StyleValues, but several
properties use syntax that makes use of non-StyleValue tokens, eg:
```css
/* Syntax using a / */
font: 12px/14px sans-serif;
/* Multiple values separated by commas */
background: url(catdog.png), url(another-image.jpg), blue;
```
Passing the ComponentValue tokens themselves means that all that
information is carried over. The alternative might be to create a
StyleValue subclass for each property and parse them fully inside
the Parser. (eg, `FontStyleValue`)
I decided against `ListStyleValue` as a name, to avoid confusion
with list styles. It's not ideal, but names are hard.
This doesn't exactly do what you would think from its name: It surely
adds an extra leading zero to the front of a number, but only if the
number is less than 10. CSS is weird sometimes.
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 *
The background-repeat value may be specified as either one- or two-value
identifiers (to be interpreted as horizontal and vertical repeat). This
adds two pseudo-properties, background-repeat-x and background-repeat-y,
to handle this. One-value identifiers are mapped to two-value in
accordance with the spec.
