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.)
This adds initial support for `open-quote`, `close-quote`,
`no-open-quote` and `no-close-quote`. We don't yet track the "nesting
level" so we always use the first pair of quotes from the `quotes`
property.
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.
