Our parsing code was treating `foo` and `foo: bar` as `<media-feature>`s
when really they need to be `(foo)` and `(foo: bar)` respectively. This
previously worked for the valid case because boolean expressions can
also have arbitrary `()` blocks. However, it meant we'd also allow them
without the parentheses which isn't valid.
So instead, parse and serialize the parentheses as part of the
`<media-feature>`. This gets us some WPT passes and fixes an Acid3
failure.
Previously we implemented an all encompassing `MathDepthStyleValue`
specifically for the `math-depth` property, this was unnecessary since
we can represent `auto-add` and `<integer>` using existing `StyleValue`
classes.
This brings the values created from parsing in line with those set via
`StylePropertyMap` which allows us to simplify computation
This means we now allow oblique angles when parsing the `font`
shorthand.
This also required us to rename the existing `FontStyle` enum to
`FontStyleKeyword`
Previously, we registered `@property` rules during parsing, and treated
them the same as `CSS.registerProperty()` calls. This is not correct
for a couple of reasons: One, the spec wants us to distinguish between
those two sources of registered custom properties, with
`CSS.registerProperty()` calls taking precedence. Two, we never removed
the registered property when its `@property` was removed from the
document.
This commit deals with this by iterating active CSSPropertyRules to find
which ones currently apply, and storing those in a cache. This cache is
invalidated whenever the Document's style is invalidated, which happens
whenever a CSSRule is added or removed from the Document.
The attached test demonstrates this now working as it should.
As well as being required to implement absolutization this also means we
now bypass a limitation with `LengthPercentage` where we would always
use `SerializationMode::Normal` for the constituent lengths which gains
us some WPT passes
Dealing with `unit_name` as a separate variable was becoming unwieldy,
so I've also combined that into the `syntax` variant.
Corresponds to:
0e6b4ef33b
`border-radius` requires a slash between the x/y components, but the
longhands like `border-top-left-radius` don't allow it. This spec
change allows authors to put a slash there for consistency.
Corresponds to:
e938d7d705
Previously this was implemented inline within the parsing of
`{repeating}-radial-gradient()` functions but it will also be useful for
`circle()` and `ellipse()`.
We now support the CSS Images Module Level 4 additions to the
`<radial-size>` syntax, namely:
- `<length-percentage>` rather than just `<length>` for circles.
- Distinct `<radial-extent>` values for horizontal and vertical for
ellipses.
- Mixing of `<radial-extent>` and `<length-percentage>` values for
ellipses.
The regressions are due to WPT not being updated to expect the first of
these additions.
When we invoke Tokenizer::consume_a_url_token, we have already consumed
the "url(" text from the source. Thus we would set the original source
text to the text starting just after those consumed code points. Let's
instead pass in the known starting position from the caller.
This fixes a bug seen on https://lichess.org, where they perform a
`substring(4)` on the property value to remove the "url(" text. This
would strip away the "http" part of the URL, and we would try to load
"s://lichess.org/image.svg". With this fixed, we can play chess games
on this site.
Our codebase assumes that a selector only contains a single
pseudo-element, and that it's in the final compound selector. If there
are multiple of them, or they're somewhere else in the selector, we
just silently pretend the others aren't there, which is *not* what we
want, and causes the selector to match things it shouldn't.
A proper fix is quite involved, so as a temporary fix, just reject any
selector that doesn't fit our assumptions during parsing. That way we
get false negatives instead of false positives.
Storing these within `LengthPercentage`, `LengthBox`, and `Variant`
over-complicated things.
We also now use the correct `SerializationMode` when serializing `xywh`
and `rect`
...instead of returning the one from its associated style sheet.
This reverts 848a250b29 where I made
`CSSImportRule.media` nullable.
CSSImportRule may not have an associated style sheet, because of not
matching a supports condition, or just failing to load the URL.
Regardless of whether we do or not, the expected (non-spec) behaviour
is that we should return a MediaList always, which matches the media
queries specified on the `@import` rule.
This is required after e937f5d - it went unnoticed until now since the
serialization is the same and the relevant code just fell back to it's
own defaults which were the same.
