Similar reasoning to making Core::Stream::read() return Bytes, except
that every user of read_line() creates a StringView from the result, so
let's just return one right away.
A mistake I've repeatedly made is along these lines:
```c++
auto nread = TRY(source_file->read(buffer));
TRY(destination_file->write(buffer));
```
It's a little clunky to have to create a Bytes or StringView from the
buffer's data pointer and the nread, and easy to forget and just use
the buffer. So, this patch changes the read() function to return a
Bytes of the data that were just read.
The other read_foo() methods will be modified in the same way in
subsequent commits.
Fixes#13687
Alias values are represented by "alias-name=real-name".
We have a lot of repetitive code for converting between ValueID and
property-specific enums. Let's see if we can generate it. :^)
This first step just produces the enums, from a JSON file. The values in
there are a duplication of what's in Properties.json, but eventually
those will go away.
The goal here is to move the parser-internal classes into this namespace
so they can have more convenient names without causing collisions. The
Parser itself won't collide, and would be more convenient to just
remain `CSS::Parser`, but having a namespace and a class with the same
name makes C++ unhappy.
This adds the is_primitive() method as described in the Web IDL
specification. is_primitive() returns true if the type is a bigint,
boolean or numeric type.
This is an editorial change in the Intl spec. See:
087995c233d29c
This also adds a missing spec link for the sanctioned units and fixes a
broken spec link for IsSanctionedSingleUnitIdentifier. In LibUnicode,
the NumberFormat generator is updated to use the constexpr helper to
retrieve sanctioned units.
This does a few things in total:
* Ports the IPC-compiler to LibMain
* Extract some compiler steps into separate functions
* Minify some appends to use appendln (or appendff in the case of
StringBuilder)
This reduces the clang-tidies maximum cognitive-complexity score for
this file from 325 to under 100.
We did already have range checking for the `<integer>` and `<number>`
types, but this patch adds this functionality to all numeric types
(dimensions and percentages).
The syntax in Properties.json is taken from the spec:
https://www.w3.org/TR/css-values-3/#numeric-ranges
eg, `length [0,∞]` defines that a Length is allowed as long as it has a
positive value.
The implementation here allows for any number to be the positive or
negative limit, even though only 0 and positive/negative infinity are
meaningful values without a unit.
This is a bit strange in the IDL syntax, but e.g., in HTMLSelectElement,
we have (simplified):
undefined add(optional (HTMLElement or long)? before = null)
This could instead become:
undefined add(optional (HTMLElement or long) before)
This change generates code for the former as if it were the latter.
I came across some websites that change an elements CSS "opacity" in
their :hover selectors. That caused us to relayout on hover, which we'd
like to avoid.
With this patch, we now check if a property only affects the stacking
context tree, and if nothing layout-affecting has changed, we only
invalidate the stacking context tree, causing it to be rebuilt on next
paint or hit test.
This makes :hover { opacity: ... } rules much faster. :^)
Day and month name constants are defined in numerous places. This
pulls them together into a single place and eliminates the
duplication. It also ensures they are `constexpr`.
This patch adds CSS::property_affects_layout(PropertyID) which tells us
whether a CSS property would affect layout if it were changed.
This will be used to avoid unnecessary relayout work when something
changes that really only requires us to repaint the page.
To mark a property as not affecting layout, set "affects-layout" to
false in the corresponding Properties.json entry. Note that all
properties affect layout by default.
Since we want to store an initial value for every CSS::PropertyID,
it's pretty silly to use a HashMap when we can use an Array.
This takes the function from ~2.8% when mousing around on GitHub all the
way down to ~0.6%. :^)
These work differently from how we validate StyleValues. There, we parse
a StyleValue from the CSS, and then see if it is allowed in the
property. That causes problems when the syntax is ambiguous - for
example, `0` can be a number or a Length.
Here instead, we ask what kinds of value are allowed for a
media-feature, and then only attempt to parse those kinds of value.
This makes the ambiguity problem go away. :^)
Each media-feature in the spec only accepts one type of value, and/or
some identifiers. This makes the switch statements for the type a bit
excessive, but the spec does not *require* that only one type is
allowed, so this is more future-proof.
