property_accepts_type() only looks at the property itself, not any
longhands it might have, so we thought that `font` didn't accept
`<custom-ident>`s, and seeing "-apple-..." makes us throw out the
declaration even though it's valid as a font name.
We'll reject these like any other unrecognized value if it's somewhere
that's not supported, so this was really just an optimization for a
rare edge case, and removing the check doesn't have any observable
effect except fixing this bug and any similar cases.
Changing property_accepts_type() to look at longhands is not
straightforward, as not all longhand values are valid in the shorthand.
This applies size, inline-size, and style containment in some cases.
There are other WPT tests for that, but we seem to not implement enough
of containment for this to have an effect so I've not imported those.
Gets us 35 WPT subtests.
This change adds the allowed angle range to the `font-style` property
definition. This allows these angles to be clamped after interpolation.
Ideally, the generator should be updated so that we can specify the
angle is in degrees. This would allow us to make use of this
information during parsing, which we can't do currently because we
don't know what the unit is. Using this value for interpolation
purposes is fine because the angle has been converted to its canonical
unit by this point.
We shouldn't include spread distance when serializing `text-shadow` as
it is not supported unlike `box-shadow` - to achieve this we store
whether this is a text or box shadow within the ShadowStyleValue and
serialize appropriately.
This introduces the `TextUnderlinePositionStyleValue` class, it is
possible to represent `text-underline-position` as a `StyleValueList`
but would have required ugly workarounds for either serialization or in
`ComputedProperties::text_underline_position`
Continues the work started in #5386 to simplify handling of positional
value list shorthand properties.
Previously we would parse these as `StyleValueList`s and then rely on
`StyleComputer::for_each_property_expanding_shorthands` to expand them
into longhands.
This required a bit of work to handle `ShorthandStyleValue`s for the
`@page` `margin` descriptor.
Previously we would instead parse these as single values and rely on
ad-hoc functionality in `for_each_property_expanding_shorthands` to
expand them to longhands.
This gets us a step closer to removing that ad-hoc functionality.
This behaviour should only apply to literal percentages as clarified
here: 4ee8429
We were also doing this wrong by converting the numeric type of the calc
to Length which was causing values to be defaulted to 1 instead (hence
the new passing tests for computed values as well)
...selector. Grammar per spec: `::slotted( <compound-selector> )`, so
we should reject selector as invalid if first compound selector is
followed by something else.
This change makes layout more correct on https://www.rottentomatoes.com/
This has always been a bit of a hack. Initially it made sense as a lot
of properties that accept a length also accept `auto`, but while
convenient, that leads to problems: It's easy to forget to check if a
length is `auto`, and places that don't accept it end up with an
invalid state lurking in the type system, which makes things unclear.
Not every user of this requires an `auto` state, but most do.
This has quite a big diff but most of that is mechanical:
LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`,
and `to_px_or_zero()` instead of `to_px()`, to make their output
clearer.
...instead of `auto` Lengths.
This also fixes interpolating between two `auto` `<bg-size>`s, which
fixes a lot of animation tests for both `background-size` and `mask`.
The spec is a bit awkward here: A few algorithms create an "empty"
SourceSet, and then assign its source-size value a few steps later, so
we have a temporary state with no length. In order to avoid complicating
the types with Optional, I've chosen to just assign it to 0px.
Previously we used `auto`, but `auto` is not a valid value here - it is
used inside the "parse a sizes attribute" algorithm, but that always
returns an actual length (or calc).
Reifying the result gets quite ad-hoc. Firstly because "parse a
component value" produces a ComponentValue, not a full StyleValue like
we need for math functions. And second, because not all math functions
can be reified as a CSSNumericValue:
Besides the fact that I haven't implemented CalculatedStyleValue
reification at all yet, there are a lot of math functions with no
corresponding CSSMathValue in the spec yet. If the calculation tree
contains any of those, the best we can do is reify as a CSSStyleValue,
and that isn't a valid return value from CSSNumericValue.parse(). So, I
made us throw a SyntaxError in those cases. This seems to match
Chrome's behaviour. Spec issue:
https://github.com/w3c/css-houdini-drafts/issues/1090
This reverts e7890429aa and partly reverts
a59c15481f.
The one pseudo-class that accepted multiple of these was :heading(), and
since that got changed to take integers instead, there's no need to keep
this extra complexity (and memory usage) around.
The CSSNumericType defined in the spec is a simple dictionary which is
only used for OM purposes. This NumericType class is used internally
and matches the more abstract definition of a "type".
This property provides a hint to the rendering engine about properties
that are likely to change in the near future, allowing for early
optimizations to be applied.
The upcoming `:heading()` pseudo-class takes multiple comma-separated
An+Bs. Also rename this field as the `:nth-[last-]child()`
pseudo-classes are only a subset of the users.
This currently only applies to property-level calculation contexts, more
work to be done to generate accepted ranges for other calculation
contexts (e.g. within transformation functions, color functions, etc)
