Previously, we were collapsing whitespace in Layout::TextNode and then
passed the resulting string for further processing through ChunkIterator
-> InlineLevelIterator -> InlineFormattingContext -> LineBuilder ->
LineBoxFragment -> PaintableFragment. Our painting tree is where we deal
with things like range offsets into the underlying text nodes, but since
we modified the original string, the offsets were wrong.
This changes the way we generate fragments:
* Layout::TextNode no longer collapses whitespace as part of its
stored "text for rendering", but moves this logic to ChunkIterator
which splits up this text into separate views whenever whitespace
needs to be collapsed.
* Layout::LineBox now only extends the last fragment if its end offset
is equal to the new fragment's start offset. Otherwise, there's a
gap caused by collapsing whitespace and we need to generate a
separate fragment for that in order to have a correct start offset.
Some tests need new baselines because of the fixed start offsets.
Fixes#566.
When we have a `calc` which is a mix of a dimension and a percentage, we
should use the percentage alone for the computed value if the dimension
component is 0 e.g. `calc(50% + 0px)` should use `50%` as it's computed
value.
This fixes an issue where text decorations (e.g. underlines) of text
split across multiple fragments would have unintended 1px gaps.
Gains us 2 WPT passes (imported)
Generating boilerplate is nice! This also has the bonus that we're more
correct: I included all the units listed in the spec before,
(see https://drafts.css-houdini.org/css-typed-om-1/#numeric-factory )
but we're supposed to exactly include ones for the units we support:
> If an implementation supports additional CSS units that do not have a
corresponding method in the above list, but that do correspond to one
of the existing CSSNumericType values, it must additionally support
such a method, named after the unit in its defined canonical casing,
using the generic behavior defined above.
> If an implementation does not support a given unit, it must not
implement its corresponding method from the list above.
Now, our factory functions will exactly match the units we support.
The changed test result is partly the order being different, and partly
that the container-query units are no longer included as we don't
actually support them.
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.
This updates `background-blend-mode`, `mix-blend-mode`, and `isolation`
to be animation type `discrete` rather than `none`. This reflects
169b0e1 but isn't reflected
on the published spec as the published spec is out of date - see
https://github.com/w3c/fxtf-drafts/issues/547
Gains us 26 WPT tests.
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: 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.
