The property values here will always be StyleValueLists and not
TransformationStyleValues. The handling of interpolation in this case
gets quite a bit more complex, so let's just remove the dead code for
now and attempt this optimization again in the future if it's needed.
This can be perfectly valid, and depends on the property being animated.
For example, interpolating between the StyleValue "none" (an identifier)
and a TransformationStyleValue is perfectly defined.
In the upcoming commits where we properly handle transformation
interpolation, it actually becomes easier to change this back to custom,
so lets do that since its more correct anyways.
If a DOM::Element has an animation-name property, then in addition to
remembering where it came from, it will also remember the
Animations::Animation object that was created for it. This allows
StyleComputer to cancel that animation if the animation-name property
changes as well as to apply any changes required (for example, if
animation-play-state changes from "running" to "paused", it needs to
call .pause() on the animation).
This also changes transform's animation-type to by-computed-value. It is
far easier to handle since we switch on StyleValue::type(), and it might
be the case that this applies to all custom animated properties and we
don't need "custom" at all, but let's wait until we get to those
properties to make that decision.
This is now handled by Web Animations, so if the animation was ever
running backwards, this logic would re-reverse it so that it played
forwards again.
With this commit, we are finally running animations off of the web
animations spec! A lot of the work StyleComputer is doing is now done
elsewhere. For example, fill-forward animations are handled by
Animation::is_relevant() returning true in the after phase, meaning the
"active_state_if_fill_forward" map is no longer needed.
Implements following rule from CSS Overflow Module Level 3:
"The visible/clip values of overflow compute to auto/hidden
(respectively) if one of overflow-x or overflow-y is neither visible
nor clip."
This patch makes a few changes to the way we calculate line-height:
- `line-height: normal` is now resolved using metrics from the used
font (specifically, round(A + D + lineGap)).
- `line-height: calc(...)` is now resolved at style compute time.
- `line-height` values are now absolutized at style compute time.
As a consequence of the above, we no longer need to walk the DOM
ancestor chain looking for line-heights during style computation.
Instead, values are inherited, resolved and absolutized locally.
This is not only much faster, but also makes our line-height metrics
match those of other engines like Gecko and Blink.
Fetching the viewport rect is currently somewhat expensive, since it
requires finding the navigable the document is active in.
We can avoid the cost of repeated calls by simply allowing StyleComputer
to cache the viewport rect at the start of style computation.
Before this change, we would only cache and reuse Gfx::ScaledFont
instances for downloaded CSS fonts.
By moving it into Gfx::VectorFont, we get caching for all vector fonts,
including local system TTFs etc.
This avoids a *lot* of style invalidations in LibWeb, since we now vend
the same Gfx::Font pointer for the same font when used repeatedly.
The styling of elements using the `use_pseudo_element()` was only
applied on layout. When an element style was recomputed later that
styling was not overruled with the pseudo element selector styles.
This moves the styling override from `TreeBuilder.cpp` to
`StyleComputer.cpp`. Now the styles are always correctly applied.
I also removed the method `property_id_by_index()` because it was
not needed anymore.
Als some calls to `invalidate_layout()` in the Meter, Progress and
Select elements where not needed anymore because the style values
are update on the changing of the style attribute.
This fixes issue #22278.
No functional impact intended. This is just a more complicated way of
writing what we have now.
The goal of this commit is so that we are able to store the 'name' of a
pseudo element for use in serializing 'unknown -webkit-
pseudo-elements', see:
https://www.w3.org/TR/selectors-4/#compat
This is quite awkward, as in pretty much all cases just the selector
type enum is enough, but we will need to cache the name for serializing
these unknown selectors. I can't figure out any reason why we would need
this name anywhere else in the engine, so pretty much everywhere is
still just passing around this raw enum. But this change will allow us
to easily store the name inside of this new struct for when it is needed
for serialization, once those webkit unknown elements are supported by
our engine.
According to the CSS font matching algorithm specification, it is
supposed to be executed for each glyph instead of each text run, as is
currently done. This change partially implements this by having the
font matching algorithm produce a list of fonts against which each
glyph will be tested to find its suitable font.
Now, it becomes possible to have per-glyph fallback fonts: if the
needed glyph is not present in a font, we can check the subsequent
fonts in the list.
This required dealing with a *lot* of fallout, but it's all basically
just switching from DeprecatedFlyString to either FlyString or
Optional<FlyString> in a hundred places to accommodate the change.
The postitioning enum values are used by the position CSS property.
Unfortunately, the prior naming clashes with the CSS Values-4 type
named position, which will be implemented in a later commit.
Which pretty much needs to be done together due to the amount of places
where they are compared together.
This also involves porting over StackOfOpenElements over to FlyString
from DeprecatedFly string to prevent a gazillion calls to
`.to_deprecated_fly_string` calls in HTMLParser.
Renaming the DeprecatedString version of this function to
Element::get_deprecated_attribute.
While performing this rename, port over functions where it is trivial to
do so to the Optional<String> version of this function.
By loading only the fonts actually used on a page, we can often avoid
making a lot of unnecessary requests and style invalidations.
This change makes initial loading of apple.com much faster.
Fixes https://github.com/SerenityOS/serenity/issues/20747
Now that shorthands use ShorthandStyleValue, the only bespoke code left
for them applies to CSS-wide keywords. We can automate expanding those,
so let's do so. :^)
For now, part of this is commented-out. Our current implementations of
`<mask>` and `<symbol>` rely on creating layout nodes, so they can't be
`display: none`.
The `to_string()` for this is modified a little from the original,
because we have to calculate what the layer-count is then, instead of
having it already calculated.
We were parsing these all right, but ignoring them in StyleComputer.
No test unfortunately, since we don't currently have a way to delay
the load event until a @font-face has been fully loaded. (Any test
of this right now would be flaky.)
In order to access the string's contents, use the new
`StringStyleValue::string_value()` method.
I think I found all the existing places that relied on
`StringStyleValue::to_string()` returning an unquoted string, but it's
hard to know for sure until things break.
This one is a bit fun because it can be `add(<integer>)` or `auto-add`,
but children have to inherit the computed value not the specified one.
We also have to compute it before computing the font-size, because of
`font-size: math` which will be implemented later.
This is a `<display-inside>` keyword added by the MathML spec, and has
the rough meaning of "display in the default way". It enables the
standard layout rules for each MathML element (and is ignored for
anything that isn't a MathML element).
I believe we'll need an actual MathML formatting context to do the
layout correctly, but we can at least support a couple of elements that
behave the same as HTML ones.
Resolving typed `attr()` functions is going to involve using more
internal Parser methods, so this is the simplest solution for that.
Also... resolving these is basically parsing them, so it makes more
sense for that process to live here.
This is just moving code, with minimal changes so it still works.
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.
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.
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. :^)
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 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.
This effectively makes it per-Document, but we hang it off of
StyleComputer since that's what it's used for.
The purpose of this is to prevent downloaded fonts from escaping the
context that loaded them. There's probably a more elegant solution where
we still share caching of system fonts, but let's start here.
We had `parse_calculated_value()` which parsed the contents of `calc()`,
and `parse_dynamic_value()` which parsed any math function, both of
which produce a CalculatedStyleValue, but return a plain StyleValue.
This was confusing, so let's combine them together, and return a
CalculatedStyleValue.
This also makes the other math functions work in
`StyleComputer::expand_unresolved_values()`.
