Using longhands rather than expanded longhands meant for instance that
we wouldn't transition `border-top-width` if we had `border` as the
transition property.
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)
As `recompute_inherited_style` works in-place rather than building
ComputedProperties from scratch we need to keep track of which animated
properties are inherited to know whether we should remove them when we
have no more inherited value.
When serializing the "style" attribute, we were incorrectly assuming
that some of the grid-related CSS properties would never contain var()
substitution functions.
With this fixed, we can now book appointments on https://cal.com/ :^)
This changes the maximum number of decimal places from 5 to 6, but 5 was
previously a guess, and not specified behaviour:
> For all of the decimal changes (except color) I couldn't really find a
> spec that mandates any required precision, so I just copied what
> Firefox seems to do, which is limit the output to 5 decimal places.
> https://github.com/SerenityOS/serenity/pull/23449
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.
When converting rotate transform functions `sin` and `cos` can sometimes
be inaccurate. To avoid these inaccuracies we:
- Mod the angle to minimise inaccuracies in the first place.
- Discard tiny (smaller than epsilon) values returned by `sin` and
`cos` as inaccuracies.
This is in line with other browsers (e.g. Gecko and WebKit).
This commit regresses a couple tests related to the mask shorthand
property. This is because we now parse the longhands but there are
errors related to serialization. Some of the failures are fixed again in
the next commit. However, for some animation tests this is not the case.
Those failures were simply masked by the fact that we did not parse the
property correctly.
Add global registry for registered properties and partial support
for `@property` rule. Enables registering properties with initial
values. Also adds basic retrieval via `var()`.
Note: This is not a complete `@property` implementation.
We should not serialize a group of properties `longhands` as a single
shorthand if there is any property declared between the first and
last property in `longhands` which is not part of `longhands` but
belongs to the same logical property group, and has different mapping
logic to any of property in `longhands`
Make sure we have a parent element before trying to look at it!
I've also pulled out a stub function for getting a custom property's
initial value, so that there's only one place to change once we support
`@property` more.
Previously if we encountered a keyword other than `fill` when parsing
`<border-image-slice` we would return a nullptr.
This could cause issues when we parse `<border-image-slice>` as part of
parsing `border-image`, for example `border-image: 100% none` would fail
as we would try parse `none` as part of the `<border-image-slice>`
instead of `<border-image-source>`.
This change makes it so that we don't consume the token and leave it to
be parsed as part of the next section of the grammar.
Custom properties are required to produce a computed value just like
regular properties. The computed value is defined in the spec as
"specified value with variables substituted, or the guaranteed-invalid
value", though in reality all arbitrary substitution functions should be
substituted, not just `var()`.
To support this, we parse the CSS-wide keywords normally in custom
properties, instead of ignoring them. We don't yet handle all of them
properly, and because that will require us to cascade them like regular
properties. This is just enough to prevent regressions when implementing
ASFs.
Our output in this new test is not quite correct, because of the awkward
way we handle whitespace in property values - so it has 3 spaces in the
middle instead of 1, until that's fixed.
It's possible this computed-value production should go in
cascade_custom_properties(), but I had issues with that. Hopefully once
we start cascading custom properties properly, it'll be clearer how
this should all work.
Previously the type argument in attr() could be the name of a CSS type
on its own. This has changed, and now only `raw-string`
(previously `string`) or the name of a dimension unit is allowed. Other
types and more complex grammar use the `type()` function, which we
don't yet support.
I've updated the syntax comment, but not the algorithm itself, which
will be reimplemented in a later commit.
...with inline children. This fixes an issue when we ignore abspos boxes
contained by PaintableWithLines while calculating overflow rect size.
Lots of layout tests are affected, because now PaintableWithLines has
overflow rect.
`Text/input/DOM/Element-set-scroll-left.html` is also affected and now
matches other browsers.
