There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
Until now, we've internally thought of the CSS "display" property as a
single-value property. In practice, "display" is a much more complex
property that comes in a number of configurations.
The most interesting one is the two-part format that describes the
outside and inside behavior of a box. Switching our own internal
representation towards this model will allow for much cleaner
abstractions around layout and the various formatting contexts.
Note that we don't *parse* two-part "display" yet, this is only about
changing the internal representation of the property.
Spec: https://drafts.csswg.org/css-display
Once we've performed the cascade on a set of values for an element,
we should have enough information to resolve/absolutize some lengths.
Basically, any CSS length that isn't "auto" or a percentage can be
turned into an absolute length (in pixels) as long as we have the
following information:
- The viewport rect
- The parent element's font
- The document element's font
- The element's own font
To ensure that we can absolutize lengths relative to the element's own
font, we now do a separate first pass where font-related properties are
defaulted (in the cascade spec sense of the word) and become usable.
There's a lot more work to do here, but this should open up a lot of
simplification in layout code, since it will no longer need to care
about relative lengths. Layout still needs to resolve percentages, since
we can't do that for some properties until the containing block
dimensions are known.
This replaces a bunch of casts with `.as_foo()` calls, and adjusts calls
to the old `is_foo()` methods that now are better as `has_foo()`.
Also tidied up some whitespace to be more consistent.
This does a few things, that are hard to separate. For a while now, it's
been confuzing what `StyleValue::is_foo()` actually means. It sometimes
was used to check the type, and sometimes to see if it could return a
certain value type. The new naming scheme is:
- `is_length()` - is it a LengthStyleValue?
- `as_length()` - casts it to LengthStyleValue
- `has_length()` - can it return a Length?
- `to_length()` - gets the internal value out (eg, Length)
This also means, no more `static_cast<LengthStyleValue const&>(*this)`
stuff when dealing with StyleValues. :^)
Hopefully this will be a bit clearer going forward. There are lots of
places using the original methods, so I'll be going through them to
hopefully catch any issues.
The 'C' in "CSS" is for Cascade, so let's actually implement the cascade
in LibWeb. :^)
StyleResolver::resolve_style() now begins by collecting all the matching
CSS rules for the given DOM::Element. Rules are then processed in the
spec's cascade order (instead of in the order we encounter them.)
With this, "!important" is now honored on CSS properties.
After performing the cascade, we do another pass of what the spec calls
"defaulting" where we resolve "inherit" and "initial" values.
I've left a FIXME about supporting correct "initial" values for every
property, since we're currently lacking some coverage there.
Note that this mechanism now resolves every known CSS property. This is
*not* space-efficient and we'll eventually need to come up with some
strategies to reduce memory usage around this. However, this will do
fine until we have more of the engine working correctly. :^)
The StyleProperties code for opacity existed before NumericStyleValue
was a thing, and was affected by over-enthusiastic unitless-length
parsing, so it assumed everything was a length. Now it matches the
Color4 spec instead, accepting either a number, or a percentage.
We also get to remove the hack! :^)
When property() previously would have returned an InitialStyleValue, we
now look up what the initial value would be, and return that instead.
We also intercep 'inherit', but inheritance is not implemented yet so we
just return nothing.
This does cause a regression on Acid2: The eyes no longer appear, and I
am not sure why. :^(
If the font-family property is set to a StyleValueList, we now iterate
through it, looking up each font in turn until one is found.
StyleResolver no longer needs to handle FontFamily specifically, which
is a nice bonus.
Serenity's current dependence on bitmap fonts leads to some weirdness
here - for example, the `if (!found_font)` path can trigger even if a
generic font family like "sans-serif" is used, since our default
sans-serif font might not be available in the desired size or weight.
The `monospace` variable only exists for that reason.
This is not a complete solution, by a long way! Serenity's font support
is still quite basic, so more work needs to be done there before we can
start implementing the spec's font-matching algorithm. But this is still
an improvement. :^)
The code was assuming the font-weight would be a Length, apparently
since NumericStyleValue didn't exist at the time. Now, it's always a
numeric value, so treat it as such.
We also replace the hardcoded numbers with references to the FontWeight
enum.
Also, it was always setting the weight to 900, so that has been fixed.
The previous code assumed all font sizes were in px, but now we perform
the conversion. There is an existing bug with em sizes returning 0,
which seems to affect other places too - see
`NodeWithStyle::apply_style()`.
This also implements 'larger', 'smaller' and calc() font-sizes.
A '0' token can be interpreted both as a Number, and as a Length. This
is problematic as in our CSS parser, we often call parse_css_value()
first, to figure out what something is, and then assign it. So we do not
know in advance whether we want a Length or not. Previously, it always
got parsed as a Length, and then every place that expected a
NumericStyleValue had to also check for a Length(0), which is easy to
forget to do.
In particular, this was causing issues with the `flex` property parsing.
To solve this, we now always parse 0 as a NumericStyleValue, and NSVs of
0 pretend to be a Length(0px) when asked. In two places, we were casting
to a LengthStyleValue* based on is_length(), which no longer works, so
those have been adjusted to use `StyleValue::to_length()` instead. They
also now check for `is_numeric()` first, to avoid the extra conversion
to a Length and back.
Possibly this opens up new issues elsewhere. In my testing it seems
fine, but until we can get CSS test suites running, it's hard to know
for certain.
This patch spreads box-shadows around:
- The Values important to box-shadows are stored in a BoxShadowData
struct
- StyleProperties knows how to construct such a struct from a
BoxShadowStyleValue and a Node knows how to ask for it
- CalculatedValues contain BoxShadowData and expose them
This is a bit hackish, but this way the existance of the calc()
becomes transparent to the user who just wants a Length and doesn't
care where it came from.
This doesn't exactly do what you would think from its name: It surely
adds an extra leading zero to the front of a number, but only if the
number is less than 10. CSS is weird sometimes.
Try to find a font that has at least some of the requested properties.
This makes e.g. rfcs on tools.ietf.org easier to read since their
headers are now bold.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
The background-repeat value may be specified as either one- or two-value
identifiers (to be interpreted as horizontal and vertical repeat). This
adds two pseudo-properties, background-repeat-x and background-repeat-y,
to handle this. One-value identifiers are mapped to two-value in
accordance with the spec.
