This is a bit iffy, but since <br> elements can't be implemented in
"just CSS" today, we should also exclude them from the blockification
algorithm. This is important, since <br> is expected to always have
inline-like behavior.
Since we always pass the px value as an argument to resolved(), we can
pass it directly as CSSPixels instead of wrapping it in Length. This
approach allows us to avoid converting to a double, resulting in fewer
precision issues.
This moves some stuff around to make LibGUI depend on LibSyntax instead
of the other way around, as not every application that wishes to do
syntax highlighting is necessarily a LibGUI (or even a GUI) application.
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.
This means StyleComputer::resolve_unresolved_style_value() always
returns a value, so we can change its return type.
However, it does still return an UnresolvedStyleValue sometimes, so we
can't remove those checks from the user code.
- Ambiguous `raw_value()` method is replaced with `line_number()` and
`span()`.
- `line_name()` that before returned either line name or area name is
replaced with `line_name()` and `area_name()`.
- `Position` type is replaced with `Line` and `Area` type so we don't
have to guess while doing layout.
Affected test expectations:
- `template-lines-and-areas` - improvement over what we had before.
- `named-tracks` - rebaseline a giant test. will have to split it into
smaller tests in the future.
The spec allows for these either to be based on the OS, or to be defined
by the browser. Looking at the other browser engines, there's a mix of
the two options. Since we've had issues with using OS colors as
defaults, let's use hard-coded colors for now. Some of these are based
on the definitions in
https://html.spec.whatwg.org/multipage/rendering.html
Reuse the check from IdentifierStyleValue in the CSS Parser, instead of
duplicating it. This might not be the ideal place to put it, but it
works for now.
Note that we don't load the local font as specified, but at least we no
longer reject such src properties in the CSS parser.
This makes the custom fonts used on http://apple.com/ actually load. :^)
This property was removed from the CSS specs, and efforts to correct the
HTML spec have stalled. For now, let's comment them out so that I don't
get spammed with the meaningless log warnings that they didn't parse,
every time I launch Ladybird. :^)
In case we've looked up the family name before and cached the result of
font fallback, we now invalidate any cached entries with the same family
name so that the next lookup may consider the newly downloaded font.
This avoids looking at every single installed typeface to see if there's
a family name match.
Fixes a large performance regression introduced when making
StyleComputer consider system fonts in CSS font fallback.
Regressed with 69a81243f5.
User styles are applied after the UserAgent's built-in styles, and
before the Author styles that are part of the web page.
Because they're neither part of the page, but can still be modified
while the page is open, caching is a little tricky. The approach here
is to piggy-back on the StyleComputer's rule caches, which already get
rebuilt whenever the styles change. This is not the smartest approach,
since it means re-parsing the style sheet more often than is necessary,
but it's simple and works. :^)
This matches if the element has a placeholder, and that placeholder is
currently visible. This applies to `<input>` and `<textarea>` elements,
but our `<textarea>` is very limited so does not support placeholders.
As noted in a9620d8784 we don't currently
set the target element so this does not function, so no tests. But it
should work once we have a fleshed out Navigables implementation. :^)
This is all of them currently, except Length, because we lack the needed
information to be able to expand font-relative lengths.
The whole way `expand_unresolved_values()` works is awkward, but at some
point we'll be able to run the simplification algorithm on the
calculation, which will either return a single value, or a new
calculation that's simplified as much as possible.
Mostly I just wanted that FIXME log message to go away, because it's
overwhelming on certain sites.
And treat them as "auto" for now, per CSS-SIZING-3, with a FIXME about
supporting more layout directions.
This fixes an issue on MDN where `height: max-content` was not
overriding height from non-CSS presentational hints.
CSS-ALIGN-3 tells us that `normal` behavior inside flex containers is
simply to behave as `stretch` so this patch makes them behave the same
inside FFC.
Furthermore, we change the `align-items` initial value to `normal`,
matching other engines.
This saves us from having to manually write these every time we add a
new type of StyleValue:
- bool is_foo() const;
- FooStyleValue const& as_foo() const;
- FooStyleValue& as_foo();
