This fixes the sizing of the arrow icons displayed to the left of
parent sections on a table of contents on Wikipedia articles, which
are sized using the equation `calc(max(0.75em, 12px))`. Now, the icon
will not expand past the edges of the box they are within, avoiding
clipping the edges of the arrows.
These apply to any elements that have some kind of open/closed state.
The spec suggests `<details>`, `<dialog>`, and `<select>`, so that's
what I've supported here. Only `<details>` is fleshed out right now,
but once the others are, these pseudo-classes should work
automatically. :^)
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.
Previously we made StringStyleValues from these, but once we start
actually quoting StringStyleValues when serializing them, this will
break the font-family serialization.
This is a simple mapping of some code-points to others.
I was going to use a ref test for this, but without knowing that the
font contains the code-points (which SerenitySans does not) we'd be
comparing a series of replacement characters to a series of replacement
characters, which doesn't tell you if they're the right code-points
underneath.
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.
Previously we were overly generous in what we accepted for `display`.
For example, we accepted:
- Multiple outside or inside identifiers
- Unrecognized identifiers
- Non-identifier tokens
Now, we reject all these cases. This makes us stop accepting the
`display: block math;` declaration in `MathML/Default.css`, and so the
one layout test we have containing MathML elements has changed to
reflect that.
We only need special-case code to handle two kinds of properties:
- Those with special rules, many of which are listed here:
https://www.w3.org/TR/cssom-1/#resolved-values
- Shorthands, because we only store longhand values.
In other cases, we can fall back to the computed values that we already
have, and these will be correct. So, we can remove them from here. :^)
Previously, the corner was always set to the top right, except if the
top left turned out to be closest, in which case it would be left
default-initialized instead.
The value is originally set using a `CSSPixels` value converted to
double, then when it is used it is always converted back to a
`CSSPixels` again. Let's just store it as that instead.
Give it a shadow tree, similar to HTMLInputElement's, so that we can
actually edit its contents at a basic level. Add some CSS to use the
`rows` and `cols` attributes as the size if they are present.
This should allow us to add a Element::attribute which returns an
Optional<String>. Eventually all callers should be ported to switch from
the DeprecatedString version, but in the meantime, this should allow us
to port some more IDL interfaces away from DeprecatedString.
Support the optional `<attr-type>` parameter to the `attr()` function,
which allows parsing the attribute's value as a variety of types,
instead of always as a string.
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 allows us to retain perfect precision for aspect ratios derived
from either the intrinsic sizes of replaced elements, or the
`aspect-ratio` CSS property.
NewAKString is effectively the default for any new IDL interface, so
let's mark this as the default behavior. It also makes it much easier to
figure out whatever interfaces are still left to port over to new AK
String.
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.
