The value is originally set using a `CSSPixels` value converted to
double, then when it is used it is always converted back to a
`CSSPixels` again. Let's just store it as that instead.
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.
Although DistinctNumeric, which is supposed to abstract the underlying
type, was used to represent CSSPixels, we have a whole bunch of places
in the layout code that assume CSSPixels::value() returns a
floating-point type. This assumption makes it difficult to replace the
underlying type in CSSPixels with a non-floating type.
To make it easier to transition CSSPixels to fixed-point math, one step
we can take is to prevent access to the underlying type using value()
and instead use explicit conversions with the to_float(), to_double(),
and to_int() methods.
This is a hack to emulate the behavior of other engines that use
fixed-point math. By rounding to 3 decimals, we retain a fair amount of
detail, while still allowing overshooting 100% without breaking lines.
This is both gross and slow, but it fixes real sites. Notably, the
popular Bootstrap library uses overshooting percentages in their
12-column grid system.
This hack can be removed when CSSPixels is made a fixed-point type.
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...)
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 :^)
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. :^)
When we're performing max-content layout (a separate throwaway layout
pass that only exists to discover the intrinsic max-content size of
a specific box), we act as if the containing block has infinite width.
This allows an infinite length to propagate into the layout system,
which is fine, but at some point it needs to be turned into a finite
number or some loop conditions will not make sense and we can hang
indefinitely (e.g in the flexible lengths resolution algorithm.)
We fix this by making Length::resolved() turn non-finite values into
an "auto" length.
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. :^)
