Before this change, we'd stop collecting must-be-present identifiers
from the selector once we crossed a combinator that wasn't ' ' or '>'.
However, we can simply skip over sibling combinators and continue
collecting ancestor identifiers on the "other side" of them, since
siblings always have a shared parent.
This allows us to use the ancestor filter to quickly reject more
selectors. It also fixes a harmless bug where we believed the ancestor
filter to be useful while there were 0 ancestor hashes in the selector.
The Transformation class wasn't really accomplishing anything. It still
had to store StyleValues, so it was basically the same as
TransformationStyleValue, with extra steps to convert from one to the
other. So... let's just use TransformationStyleValue instead!
Apart from moving code around, the behavior has changed a bit. We now
actually acknowledge unresolvable parameters and return an error when
we try to produce a matrix from them. Previously we just skipped over
them, which was pretty wrong. This gets us an extra pass in the
typed-om test.
We also get some slightly different results with our transform
serialization, because we're not converting to CSSPixels and back.
Some transform-functions are not reifiable as a CSSTransformComponent,
for example a matrix() with sibling-index() in it. In that case, rather
than crashing, fall back to the basic CSSStyleValue reification.
The crash doesn't happen yet, but would with the following commit's
changes. Currently, Transformation::to_matrix() completely ignores
unsupported argument types, but in the next commit that's replaced with
TransformationStyleValue::to_matrix(), which attempts to handle them
properly.
The spec asks us to serialize with no more than 6 decimal digits, so if
the number is smaller than 0.000,000,5 then it can't produce any digits
and we should serialize it as 0, instead of using scientific notation.
We also shouldn't use scientific notation for very large numbers, but we
don't seem to have a flag to disable that in the formatter, so I'm
leaving a FIXME for now.
Improves some test results. 🎉
Dealing with `unit_name` as a separate variable was becoming unwieldy,
so I've also combined that into the `syntax` variant.
Corresponds to:
0e6b4ef33b
...when the style is `none` or `hidden`. `outline-width` is not affected
by `outline-style: none` at all.
In our codebase, that means doing the border-width conversion when
assigning to ComputedValues.
Corresponds to:
2a3d1e4d1009f11f2ef9
`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
:heading() now matches based on a computed heading level, which is based
on the level of the tag (h1, h2, etc) and then modified by these two new
attributes.
I'm caching this heading level on HTMLHeadingElement, based on the dom
tree version. That's more invalidation than is actually needed, but it
saves us calculating it over and over when the document hasn't changed.
The failing test cases are:
- Implicit headingreset for modal dialogs which is apparently unspecced
and controversial.
- Not walking the flat tree properly. A flat tree ancestor of a
slot-assigned element is its slot, which is something we don't do
anywhere that I could find. I've made a note to look into this later.
We also don't implement the `ReflectRange` IDL attribute yet, which
means we're not clamping the read value of `headingOffset`.
Corresponds to:
e774e8e318
The corresponding WPT test was not imported since it still fails
for unrelated reasons. As it stands right now, we have no way of
testing this behavior.
This is equivalent to the existing `PositionStyleValue::create_center`
but returns the value expected after computation has been completed
(i.e. `50% 50%` rather than `center center`)
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.
In level 2 of the web animations spec, times are no longer always
measures in milliseconds, they can also be percents when dealing with
progress-based (i.e. scroll-based) timelines.
We don't actually support percent times yet but this change will make it
easier to implement when we do.
Web Animations Level 2 disallows setting some `AnimationEffect` timing
values (start delay, end delay, iteration duration) directly and instead
allows authors to set the specified values which are then normalized
into the actual used values taking into account the type of the
associated timeline (i.e. progress- vs time-based)
This was added in Level 2 of the Web Animations spec
In this level of the spec, all time values associated with animations
(including this duration property) are no longer simple numbers but are
instead either percentages or numbers for progress- and time-based
timelines respectively. These values are represented internally by a new
`TimeValue` wrapper struct, and externally (i.e. in JS) as
`CSSNumberish`.
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.
This also allows us to remove the path generation and interpolation
handling for `rect()` and `xywh()` since that occurs after computation
Regressions in clip-path-interpolation-xywh.html are due to improper
simplification of length-percentage mixes where the length is 0px.
Storing these within `LengthPercentage`, `LengthBox`, and `Variant`
over-complicated things.
We also now use the correct `SerializationMode` when serializing `xywh`
and `rect`
Specifically, we create and assign a layer if its import conditions
currently apply.
With this change, every case in the `layer-import.html` test actually
functions correctly, apart from our lack of proper `load` event
support. (Tested by hacking in a 100ms wait after the `await Promise()`
statement.)
...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.
We can deduplicate some code by using `assemble_coordinated_value_list`,
also moves this to a method in `ComputedProperties` to be in line with
other values
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.
This makes us consistent with how we handle this value within the
`background` shorthand and allows us to remove the special handling in
`StyleComputer::for_each_property_expanding_shorthands`
