This uses a `foo>bar` notation in the `valid-identifiers` field of
Properties.json, to say "replace `foo` with `bar`".
The motivation here is to avoid calling `parse_css_value_for_property()`
inside the per-property switch in `parse_css_value()`. Eventually we'll
need to be able to call that switch from
`parse_css_value_for_properties()` so that shorthands can make use of
any bespoke parsing code to parse their longhands.
This reverts commit c14173f651. We
should only annotate the minimum number of symbols that external
consumers actually use, so I am starting from scratch to do that
Before this change, calc() would resolve to different types depending on
the nearest containing value context. This meant that rgb(calc(), ...)
by itself worked correctly due to fallbacks, but rgb(calc(), ...) inside
e.g a linear-gradient would create a calc() value that resolves to a
length, which subsequently got rejected by the color value parser.
Fixing this makes various little gradients show up on Discord.
At some point `hue-rotate` was changed to use `AngleOrCalculated`
rather than `Angle`, but `Angle` was still being used in a `visit`,
which otherwise defaulted to zero. This caused all `hue-rotate` angles
to serialize to zero.
Fixes bug when `build_matching_rule_set()` mistakenly included all
unlayered rules twice. This was caused by mistakenly including all
unlayered rules into `""` named "service" layer, because we couldn't
tell if FlyString = `""` means no layer or layer named `""`.
Previously, an SVG with width of zero would have am intrinsic aspect
ratio of zero. With this change, if an SVG has a width or height of
zero, the intrinsic aspect ratio is determined by the SVG's viewbox.
...for `text-justify: inter-character`.
We previously had this mapped in Enums.json, but the behaviour is
different: `a=b` in Enums.json keeps `a` around but makes it behave the
same as `b`. A legacy name alias is instead expected to replace `a`
with `b`, so we have to do that separately.
We don't yet have a system for "legacy value aliases", but until we have
a lot of them we can handle them manually.
We also have to do this in two places because
parse_css_value_for_property() doesn't call any property-specific
parsing code.
Before this change we were running the CSS cascade machinery twice per
element:
- First, to compute the "logical alias mapping context" based on
writing-mode and pals.
- Then, to compute all properties.
This patch factors out the heaviest work from the cascade machinery
to a separate step that can be run only once. This step will:
- Collect all the matching rules for the element
- Resolve custom properties for the element
We still perform the per-element cascade twice, but now this is hogging
less than 1% of CPU time when typing on Discord (compared to 9% before.)
The specification [1] indicates that the tentative used width and height
should be computed first, and if they exceed the `max-width` or
`max-height`, the rules should be applied again using the computed
values of `max-width` and `max-height`.
The only required change to follow the spec is to remove the early
`return` statements, in both `compute_width_for_replaced_element`
and `compute_height_for_replaced_element`.
Fixes#5100.
[1] https://www.w3.org/TR/CSS22/visudet.html#min-max-widths
To make {,de}serialization of ImageBitmap work we also had to add
support for creating an ImageBitmap from a HTMLCanvasElement in
WindowOrWorkerGlobalScopeMixin::create_image_bitmap_impl().
This refactors out the reading part of Gfx::Bitmap from
HtmlCanvasElement::surface(). We can then reuse this from
WindowOrWorkerGlobalScopeMixin::create_image_bitmap_impl() when we
create an ImageBitmap from a HtmlCanvasElement.
1. Fix typos in some macro invocations of these error types. We now use
a single xmacro to instantiate error definitions to prevent such
errors in the future.
2. Use the "WebAssembly." prefix as needed.
3. Allocate the error constructors and prototypes with `realm.create`
rather than `heap.allocate`. The latter does not invoke `initialize`
methods. This exposed the next issue:
4. Use the correct intrinsic prototype in the error constructor. We were
using the base native error prototype. We unfortunately cannot invoke
OrdinaryCreateFromConstructor from LibJS directly with the correct
prototype, so an implementation was added here.
5. Use intrinsic accessors to create the constructors. I don't think
this one was actually a fix, but it makes the setup look more like
other built-ins.
This fixes an issue where only the last KeyframeEffect applied to an
element would actually have an effect on the computed properties.
It was particularly noticeable when animating a shorthand property like
border-width, since only one of the border edges would have its width
actually animate.
By deferring the invalidation until all animations have been processed,
we also reduce the amount of work that gets done on pages with many
animations/transitions per element. Discord is very fond of this for
example.
Using the new hooks in the XML Parser's listener interface, we now
append DOM nodes for CDATASections and ProcessingInstructions
to the document as they are encountered. This commit also fixes where
comment nodes are appended, ensuring they are added to the current node
instead of the document root.
...elements. Adds missing pseudo-element type passed into computed
properties getter.
Previously, due to this bug, we were using the element's computed
properties as the previous computed properties for its pseudo-elements.
This caused an excessive number of unintended CSS transitions to run.
The issue was particularly noticeable in Discord's emoji picker, where
each emoji has `::after` pseudo-element. We were incorrectly triggering
transitions on all their properties, resulting in significant
unnecessary work in style computation and animation event dispatching.
...and setter. We had lots of places where we check if pseudo-element
type is specified and then use `pseudo_element_computed_properties()` or
`computed_properties()`. This change moves these checks from caller side
to the getter and setter.
The underlying storage used during string formatting is StringBuilder.
To support UTF-16 strings, this patch allows callers to specify a mode
during StringBuilder construction. The default mode is UTF-8, for which
StringBuilder remains unchanged.
In UTF-16 mode, we treat the StringBuilder's internal ByteBuffer as a
series of u16 code units. Appending a single character will append 2
bytes for that character (cast to a char16_t). Appending a StringView
will transcode the string to UTF-16.
Utf16String also gains the same memory optimization that we added for
String, where we hand-off the underlying buffer to Utf16String to avoid
having to re-allocate.
In the future, we may want to further optimize for ASCII strings. For
example, we could defer committing to the u16-esque storage until we
see a non-ASCII code point.
