CSS-Typed-OM has the following hierarchy:
CSSStyleValue
- CSSNumericValue
- CSSUnitValue
- CSSMathValue
- ...various math functions...
Somewhat unintuitively, numbers are also stored using CSSUnitValue with
`unit = "number"`.
There are no distinct classes for LengthStyleValue, etc in the spec, but
they're convenient for us, so they are implemented as subclasses of
CSSUnitValue, at least for now.
Avoid unintentionally converting between float and double multiple times
by just using double everywhere. Also, remove the unused `int` versions
of their constructors.
This is to make it easier to bounds-check their values during parsing.
Length is left out because many length units are relative to the
context in which they are used, and so we cannot easily compare `10px`
and `1em`, for example.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
C++20 can automatically synthesize `operator!=` from `operator==`, so
there is no point in writing such functions by hand if all they do is
call through to `operator==`.
This fixes a compile error with compilers that implement P2468 (Clang
16 currently). This paper restores the C++17 behavior that if both
`T::operator==(U)` and `T::operator!=(U)` exist, `U == T` won't be
rewritten in reverse to call `T::operator==(U)`. Removing `!=` operators
makes the rewriting possible again.
See https://reviews.llvm.org/D134529#3853062
