Instead of switching on the PropertyID and doing a boatload of
comparisons, we reorder the PropertyID enum so that all inherited
properties are in two contiguous ranges (one for shorthands,
one for longhands).
This replaces the switch statement with two simple range checks.
Note that the property order change is observable via
window.getComputedStyle(), but the order of those properties is
implementation defined anyway.
Removes a 1.5% item from the profile when loading https://hemnet.se/
This header held a bunch of utility functions shared across several code
generators. The only user of any of these utilities now is the public
suffix generator. Move the one used function to that generator, and
remove the common header.
We don't actually generate any such events ourselves. But Google Lens
will create one with the DataTransfer attribute set to that of any drop
event we send it.
USVString attributes Now replace any surrogates with the replacement
character U+FFFD and resolve any relative URLs to an absolute URL. This
brings our implementation in line with the specification.
For a long time, we've used two terms, inconsistently:
- "Identifier" is a spec term, but refers to a sequence of alphanumeric
characters, which may or may not be a keyword. (Keywords are a
subset of all identifiers.)
- "ValueID" is entirely non-spec, and is directly called a "keyword" in
the CSS specs.
So to avoid confusion as much as possible, let's align with the spec
terminology. I've attempted to change variable names as well, but
obviously we use Keywords in a lot of places in LibWeb and so I may
have missed some.
One exception is that I've not renamed "valid-identifiers" in
Properties.json... I'd like to combine that and the "valid-types" array
together eventually, so there's no benefit to doing an extra rename
now.
Implements the corresponding encoders, selects the appropriate one when
encoding URL search params. If an encoder for the given encoding could
not be found, fallback to utf-8.
USVString is defined in the IDL spec as:
> The USVString type corresponds to scalar value strings. Depending on
> the context, these can be treated as sequences of either 16-bit
> unsigned integer code units or scalar values.
This means we need to account for surrogate code points by using the
replacement character.
This fixes the last test in https://wpt.live/url/url-constructor.any.html
Previously we were assuming that the attribute return value was never
nullable and going to be returned in an Optional<IntegralType>, causing
complile errors for something such as: `attribute unsigned long?`.
Mirroring the pre-existing `generate_from_integral` function. This will
allow us to fix a bug that all of these if statements have in common -
no handling of nullable types.
This also adjusts the type casted for each integral to fully match that
stated by the spec.
It turns out we were already generating all the necessary include
statements, and we can simply remove all this goofy code soup that
uses the C preprocessor to speculatively look for include files.
This is `counter(name, style?)` or `counters(name, link, style?)`. The
difference being, `counter()` matches only the nearest level (eg, "1"),
and `counters()` combines all the levels in the tree (eg, "3.4.1").
If no header includes the prototype of a function, then it cannot be
used from outside the translation unit it was defined in. In that case,
it should be marked as `static`, in order to avoid possible ODR
problems, unnecessary exported symbols, and allow the compiler to better
optimize those.
If this warning triggers in a function defined in a header, `inline`
needs to be added, otherwise if the header is included in more than one
TU, it will fail to link with a duplicate definition error.
The reason this diff got so big is that Lagom-only code wasn't built
with this flag even in Serenity times.
Following the rules in the algorithm from
https://webidl.spec.whatwg.org/#js-platform-objects, "To Internally
create a new object implementing the interface interface", this change
incorporates the steps to load a prototype from new.target, and write
it to the created instance returned from constructor_impl(). This
mirrors the code for generate_html_constructor(), which incorporates
additional steps needed by Custom Elements.
Bug #334
This implements most of the CloseWatcher API from the html spec.
AbortSignal support is unimplemented.
Integration with dialogs and popovers is also unimplemented.
For SerenityOS, we parse emoji metadata from the UCD to learn emoji
groups, subgroups, names, etc. We used this information only in the
emoji picker dialog. It is entirely unused within Ladybird.
This removes our dependence on the UCD emoji file, as we no longer
need any of its information. All we need to know is the file path to
our custom emoji, which we get from Meta/emoji-file-list.txt.
There are a couple of differences here due to using ICU:
1. Titlecasing behaves slightly differently. We previously transformed
"123dollars" to "123Dollars", as we would use word segmentation to
split a string into words, then transform the first cased character
to titlecase. ICU doesn't go quite that far, and leaves the string
as "123dollars". While this is a behavior change, the only user of
this API is the `text-transform: capitalize;` CSS rule, and we now
match the behavior of other browsers.
2. There isn't an API to compare strings with case insensitivity without
allocating case-folded strings for both the left- and right-hand-side
strings. Our implementation was previously allocation-free; however,
in a benchmark, ICU is still ~1.4x faster.
