When converting this code to use Optional, I accidentally left in the
initialization, so it *always* had a value, and always created a Length
from it. Oops.
The pattern we've adopted for other multi-value properties is to run in
a loop like this, since that makes it easier to cater for values
appearing in different orders.
During the LengthPercentage split, I converted the individual-corner
`border-foo-bar-radius` properties to LengthPercentage but forgot
`border-radius` itself! Oops. Discord's CSS was doing `border-radius:
50%` a lot, so this cuts down on CSS parser spam.
Browser has a handy debug menu option to dump all stylesheets, so we
don't need to spam the console with this. (All the spam massively slows
down page loads.)
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.
This lets us produce valid CSS in its to_string() method, instead of
always adding commas as before. :^)
Also, finally added a Formatter for StyleValues.
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. :^)
This means you can now do queries like:
```css
@media (400px <= width < 800px) { }
```
Chromium and Firefox which I tested with both don't support this yet, so
that's cool. :^)
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.
Web::CSS::MediaQuery::MediaFeature::Type was getting a bit ridiculous!
Also, this moves the detection of "min-" and "max-" media-features into
the MediaFeature itself, since this is an implementation detail, not
part of the spec.
Previously, we were using StyleValues for this, which was a bit of a
hack and was brittle, breaking when I modified how custom properties
were parsed. This is better and also lets us limit the kinds of value
that can be used here, to match the spec.
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.
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.
The changes in commit d462a6720a meant
that `CSSLoader::load_next_import_if_needed()` was no longer being
called, so no `@import` rules were loading.
The spec does not seem to mention when that loading should take place,
but WebKit does this at parse time, as each rule is added to the style
sheet. If it works for them, it's probably not that bad. :^)
So, that's what we now do here. The `CSSImportRule` creates a fetch
request when it is constructed, so each one is responsible for its own
contents.
Like the `background-foo` longhand properties (except
`background-color`), `background` allows multiple layers to be defined,
separated by commas. A layer does not necessarily contain something to
actually draw!
This parses as a `BackgroundStyleValue`, holding a `StyleValueList` for
each property. This is mostly to make expansion into longhands simpler -
if we had a list of `BackgroundStyleValue`s instead, one per layer, then
we would have to break it up per-property anyway when computing styles.
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.
...as opposed to storing StyleValues, which we have to later check are
IdentifierStyleValues, which store identifiers that we can convert to
Repeat values later. It's fewer allocations, and we can't end up with
invalid values by mistake. :^)
This is step 1 in removing the two `background-repeat-x/y`
pseudo-properties. Since adding the concept of compound StyleValues, we
don't need `background-repeat` to be split in two any more.
