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.
