Transitions apply after logical properties are mapped to their physical
counterparts so we should apply this mapping to `transition` properties
Gains us 20 WPT tests.
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.
If we are interpolating between a dimension and a percentage value and
the dimension component is 0, we now return a percentage value rather
than a `calc()` value.
All remaining failing subtests in border-image-width-interpolation.html
are related to incorrect handling of mixed dimension and percentage
interpolation and are fixed by #6142.
This also fixes a bug in the view transitions code that was
required to get the imported test to pass. The code for setting
the initial containing block size just did not set the right thing,
since doing so would trigger an error later on.
That later error resulted from walking up the tree, without
considering that the document element has a parent that is not
itself an element. (and then doing element things to it)
Now follows the same pattern as PaintableBox and StackingContext, where
it exits if hidden, then hit tests children, then hit tests itself if
it's `visible_for_hit_testing()`.
This change removes premature reset of
`block_container_y_position_update_callback`. Also makes callback
private in `BlockMarginState`, because resetting it independently of
currently accumulated margins is incorrect.
Lots of test expectations are updated, but there is no visual
difference.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/6074
We also support interpolating from a CalculatedStyleValue to a
compatible dimension or percentage style value.
This also brings with it a couple of improvements in how we handle
interpolation between mixed dimension and percentage types in terms of:
- Proper simplification of the resulting calc()
- Improved handling of interpolation outside the 0-1 range
This behaviour should only apply to literal percentages as clarified
here: https://github.com/w3c/csswg-drafts/commit/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)
This ensures that we clamp values for properties like padding-* to valid
ranges (non-negative in this case) if they are specified with `calc()`.
The length-related changes in this commit combined with the ones from
the previous commit fix the primary layout issue on https://lwn.net
(yes, not the first place I would have expected problems either).
...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`.
If a node with `contenteditable=true/plaintextonly` is the child of an
editable node or an editing host, we should make it editable instead of
an editing host. This effectively merges nested editing hosts together,
which is how other browsers deal with this as well.
Gains us 5 WPT subtest passes in `editing`.
`font-size` can end up with a negative value - either due to `calc`
being resolved using the old method which doesn't clamp the value, or
interpolation - in this case we should clamp negative values to zero.
Gains us 36 new WPT passes and fixes crashes in the three imported
tests.
Interpolation can leave `padding-*` values as negative - this should be
handled by interpolation clamping it to the allowed range of values
but we don't yet do that. As a stop gap we can clamp this before setting
it in ComputedValues.
This fixes 3 crashes and gains us 11 passes in the imported WPT tests
Currently, ImageProvider::current_image_bitmap takes a Gfx::IntSize
argument which determines the size of the returned bitmap. The default
value of this argument is 0x0 which causes the function to return
nullptr. This behavior is evidently unintuitive enough that it has lead
to incorrect usage in multiple places. For example, the 2D canvas
drawImage method will never actually draw anything because it calls
current_image_bitmap with no arguments. And the naturalWidth and
naturalHeight of an image will always return 0 (even after the image has
loaded) for the same reason.
To correct this and hopefully avoid similar issues in the future,
ImageProvider::current_image_bitmap will be renamed to
current_image_bitmap_sized, and the default value for the size argument
will be removed. For consistency, a similar change will be made to
SVGImageElement::default_image_bitmap.
The existing current_image_bitmap function will no longer take a size
argument. Instead it will always return a bitmap of the image's
intrinsic size. This seems to be what most existing callers had already
assumed was the function's behavior.
From the SVG spec
The value of the ‘viewBox’ attribute is a list of four numbers <min-x>,
<min-y>, <width> and <height>, separated by whitespace and/or a comma...
Currently try_parse_view_box will fail to parse the attribute if the
values are separated by commas.
This change replaces try_parse_view_box with a more correct
implementation. It will reside in the AttributeParser.cpp. This new
implementation correctly handles comma-separated viewBox values, and is
also more robust against invalid inputs.
Additionally, it adds a new test case to ensure viewBox values with
various syntax are parsed correctly and invalid values are rejected.
What I thought was a spec issue was actually a combination of my own
misunderstanding and a bug in our IDL generator. With that bug fixed, I
can correct this to how it is in the spec.
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
