Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
By the time that property() gets called, we've already given every
single property a value, so we can just return it. This simplifies a
lot of places that were manually handling a lack of value
unnecessarily.
This means deviating a little from the spec, so that we create a
complete Block in one go instead of creating an empty one and then
poking at its internals.
The goal here is to move the parser-internal classes into this namespace
so they can have more convenient names without causing collisions. The
Parser itself won't collide, and would be more convenient to just
remain `CSS::Parser`, but having a namespace and a class with the same
name makes C++ unhappy.
Previously, we would create a new Gfx::ScaledFont whenever we needed one
for an element's computed style. This worked fine on Acid3 since the use
of web fonts was extremely limited.
In the wild, web fonts obviously get used a lot more, so let's have a
per-point-size font cache for them.
Previously, we were running the "load fonts if needed" machine at the
start of every style computation. That was a lot of unnecessary work,
especially on sites with lots of style rules, since we had to traverse
every style sheet to see if any @font-face rules needed loading.
With this patch, we now load fonts once per sheet, right after adding
it to a document's style sheet list.
"Component value" is the term used in the spec, and it doesn't conflict
with any other types, so let's use the shorter name. :^)
Also, this doesn't need to be friends with the Parser any more.
CSS Values and Units Module Level 5 defines attr as:
`attr(<q-name> <attr-type>?, <declaration-value>?)`
This implementation does not contain support for the type argument,
effectively supporting `attr(<q-name>, <declaration-value>?)`
When encountering a @font-face rule, StyleComputer will now fire off
a resource request and download the first source URL specified.
Once downloaded, we try to parse it as a TrueType font file, and if it
works, it's added to a cache in StyleComputer. This effectively makes
fonts per-document since every document has its own StyleComputer.
This is very unoptimized and could definitely use some caching, etc.
But it does work on Acid3. :^)
Our font database uses point sizes for fonts, and we were passing it
px sizes. This caused all fonts to be 1.333x larger than they should
be on the web. Of course it wasn't always noticeable with bitmap fonts,
but noticeable everywhere with scalable fonts.
Relative font-sizes like "2em" were previously resolved against the
fallback value (10px) which led to incorrect layouts in many places.
Fix this by resolving relative font-sizes against the absolutized
font-size of the parent or root element as appropriate.
Let's make it very clear that these are *computed* values, and not at
all the specified values. The specified values are currently discarded
by the CSS cascade algorithm.
Get rid of the old, roundabout way of invalidating the rule cache by
incrementing the StyleSheetList "generation".
Instead, when something wants to invalidate the rule cache, just have it
directly invalidate the rule cache. This makes it much easier to see
what's happening anyway.
Style computation always happens *before* layout, so we can't rely on
things having (or not having) layout nodes, as that information will
always be one step behind.
Instead, we have to use the DOM to find all the information we need.
Previously we were making a copy of the full set of custom properties
that applied to a DOM element. This was very costly and dominated the
profile when mousing around on GitHub.
Note that this may break custom properties on pseudo elements a little
bit, and that's something we'll have to look into.
Previously this queried the root layout-node's font, which was both
wrong and could crash if the layout wasn't ready yet. Now, it's just
wrong. But at least all the font-related wrongness is grouped together
in StyleComputer. :^)
Build the final custom property map right away instead of first making
a temporary pointer-only map. We also precompute the final needed
capacity for the map to avoid incremental rehashing.
Let's have one function that determines the type of transformation
needed, and another to actually perform the transformation.
This makes it much easier to read, and we don't have to duplicate the
logic for doing the transformation.
Instead of awkwardly visiting and mutating lengths inside StyleValues,
we now simply create a new StyleValue instead.
This fixes an issue where inherited relative lengths could get
absolutized using a parent as reference, and then not having the correct
values when used in a child context.
