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. :^)
A lot of this is quite ugly, but it should only be so until I remove
Length::Type::Percentage entirely. (Which should happen later in this
PR, otherwise, yell at me!) For now, a lot of things have to be
resolved twice, first from a LengthPercentage to a Length, and then
from a Length to a pixel one.
The flexbox logic confuses me so regressions are possible, though our
test page looks the same as before so it should be fine.
Renamed FlexBasis::Length -> LengthPercentage too, for clarity.
This does undo the changes in 88c32836d8,
which accounted for our bitmap fonts being a different size than the
`font-size` property requests. I think this would be better handled
inside Length::to_px(), which would then apply to all font-size-relative
lengths (eg, em and rem) instead of only for the line-height property.
Layout::Node still treats border radii as having a single value instead
of horizontal and vertical, but one less hack is nice, and helps with
conversion to LengthPercentage. :^)
This is in a slightly weird state, where Percentages are sometimes
Lengths and sometimes not, which I will be cleaning up in subsequent
commits, in an attempt not to change all of LibWeb in one go. :^)
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.
Regardless of the backing type that the number would otherwise parse to,
if it is zero and the sign was supposed to be negative then it needs to
be a floating point number to represent the correct value.
This is in line with this recent change to Conditional-3:
> Removed the “unknown” value in CSS feature queries’ boolean logic,
> defining unrecognized syntaxes as “false” instead.
> https://github.com/w3c/csswg-drafts/issues/6175
Each ZONE entry contains a RULES segment with one of the following:
* A DST rule name, which links the ZONE to a RULE entry holding the
DST rules to apply.
* A static offset to be applied to the STDOFF offset. This implicitly
means that the time zone is in DST during that time frame.
* A "-" string, meaning no offset is applied to the STDOFF offset, and
the time zone is in standard time during that time frame.
That's an old yak :^)
No, past me, AST nodes do not need to learn to stringify themselves.
This is now massively simplified by using the [[SourceText]] internal
slot.
Also updates a bunch of tests that are incorrect due to the old
implementation not being spec compliant, and add plenty more.
