This is intended to annotate conversions from unknown floating-point
values to CSSPixels, and make it more obvious the fp value will be
rounded to the nearest fixed-point value.
In general it is not safe to convert any arbitrary floating-point value
to CSSPixels. CSSPixels has a resolution of 0.015625, which for small
values (e.g. scale factors between 0 and 1), can produce bad results
if converted to CSSPixels then scaled back up. In the worst case values
can underflow to zero and produce incorrect results.
Avoid unintentionally converting between float and double multiple times
by just using double everywhere. Also, remove the unused `int` versions
of their constructors.
This fixes a plethora of rounding problems on many websites.
In the future, we may want to replace this with fixed-point arithmetic
(bug #18566) for performance (and consistency with other engines),
but in the meantime this makes the web look a bit better. :^)
There's a lot more things that could be converted to doubles, which
would reduce the amount of casting necessary in this patch.
We can do that incrementally, however.
Length units are either relative to the font, or to the viewport, but
never both. So we can save some work by not gathering font metrics for
a viewport unit, and not retrieving the viewport for a font unit.
Currently this is only helpful when the `to_px(Layout::Node)` method is
called, but since that is 208 places according to CLion, (plus 33
indirect uses via `Length::resolved()`) it still seems worthwhile. :^)
`*vi` and `*vb` vary on which direction they check depending on whether
the writing mode is horizontal or vertical, so they will need some
modification once we support that.
Using the rough heuristic instead of the actual spec measurement. It's
allowed by the spec, but not ideal:
> In the cases where it is impossible or impractical to determine the
ideographic advance measure, it must be assumed to be 1em.
As noted, the ascent of the font is not the best heuristic for this, but
it is one that's listed as OK to use by the spec:
> In the cases where it is impossible or impractical to determine the
cap-height, the font’s ascent must be used.
Rather than passing an increasingly-unwieldy number of font parameters
individually to every function that resolves lengths, let's wrap them
up.
This is frustratingly close to being `Gfx::FontPixelMetrics`, but bitmap
fonts cause issues: We choose the closest font to what the CSS
requests, but that might have a wildly different size than what the
page expects, so we have to fudge the numbers.
No behaviour changes.
They previously weren't sorted at all. Alphabetical would be nice, but
then things like `em` and `rem` would be separated. So, let's copy the
spec's order. That way it's easier to keep track of which units we have
or haven't implemented. (Since there are so many...)
This makes it possible to do arithmetic on them without having to
resolve to their canonical unit, which often requires context
information that is not available until the last minute. For example, a
Length cannot be resolved to px without knowing the font size, parent
element's size, etc.
Only Length currently requires such context, but treating all these
types the same means that code that manipulates them does not need to
know or care if a new unit gets added that does require contextual
information.
There were a mix of users between those who want to know if the Length
changed, and those that just want an absolute Length. So, we now have
two methods: Length::absolutize() returns an empty Optional if nothing
changed, and Length::absolutized() always returns a value.
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
This remained undetected for a long time as HeaderCheck is disabled by
default. This commit makes the following file compile again:
// file: compile_me.cpp
#include <LibWeb/CSS/GridTrackSize.h>
// That's it, this was enough to cause a compilation error.
Which is to say, a T where `is_calculated()` is false.
As is becoming a repeating theme with CSS types, we have two states for
a FooPercentage that is a `calc()` expression: Either the FooPercentage
holds the CalculatedStyleValue directly, or it holds a Foo which itself
holds the CalculatedStyleValue. The first case was already handled to
return Foo, and with this patch, the second is too. :^)
This means the units are defined in a single place instead of two.
Also removed the verify that we didn't produce a bogus % dimension token
in the Tokenizer, since this has never happened and the parser is not a
tokenizer test suite. :^)
"5em" means 5*font-size, but by forcing "em" to mean the presentation
size of the bitmap font actually used, we broke a bunch of layouts that
depended on a correct interpretation of "em".
This means that "em" units will no longer be relative to the exact
size of the bitmap font in use, but I think that's a compromise we'll
have to make, since accurate layouts are more important.
This yields a visual progression on both ACID2 and ACID3. :^)
Nobody makes undefined Lengths now, (although actually removing
Undefined will come in a later commit) so we can remove this parameter,
and `resolved_or_auto()`/`resolved_or_zero()`.
Despite looking like it was still needed, it was only used for passing
to other calls to Length::resolved() recursively. This makes the
various `foo.resolved().resolved()` calls a lot less awkward.
(Though, still quite awkward.)
I think we'd need to separate calculated lengths out to properly tidy
these calls up, but one yak at a time. :^)
Length and Percentage are different types, and sometimes only one or the
other is allowed in a given CSS property. This is a first step towards
separating them.
Previously: Length (and all nearly all of its inline method
definitions) depended on the definition of class CalculatedStyleValue.
Meanwhile, CalculatedStyleValue (and nearly all of its namespaced
structs) depended on the definition of class Length.
Thus, a compilation unit that (for example) only contains
#include <Userland/Libraries/LibWeb/CSS/Length.h>
would fail to compile.
This patch resolves this issue by pushing the inline definition of
various Web::CSS::Length methods into a different file.
In cases where we know the Length is absolute, we know we don't need to
pass in a Layout::Node or FontMetrics etc, and yet we were required to
before. Splitting it means jumping through less hoops that we don't have
to. :^)
