It's a little verbose to repeat these in cases like the borders, but if
everything has an initial value, we can guarantee that
`property_initial_value()` will return something! :^)
- `align-items`: `normal` is the initial value in the CSS-ALIGN spec,
but `stretch` is in CSS-FLEXBOX. The FLEXBOX spec is the one we've
actually implemented elsewhere, and ALIGN adds new values with special
syntax, so it's not trivial to add it here.
- `border-spacing`: `0` is equivalent to `0px 0px` and we don't yet
parse the double-value syntax.
- `text-decoration-thickness`: Had the wrong value.
There's nothing really background-size-specific about this, but since
there is no `<size>` value type defined in the CSS spec at this time,
and background-size is the only user of it, I think this name makes more
sense. But I'm not 100% convinced.
...as opposed to storing StyleValues, which we have to later check are
IdentifierStyleValues, which store identifiers that we can convert to
Repeat values later. It's fewer allocations, and we can't end up with
invalid values by mistake. :^)
While right now this doesn't save much complexity, it will do once we
care about multiple background layers per node. Then, having a single
repeat value per layer will simplify things.
It also means we can remove the pseudo-property concept entirely! :^)
This is step 1 in removing the two `background-repeat-x/y`
pseudo-properties. Since adding the concept of compound StyleValues, we
don't need `background-repeat` to be split in two any more.
This is done a bit differently from other properties: using a
TokenStream instead of just a Vector of ComponentValues. The reason for
this is, we can then use call the same function when parsing the
`background` shorthand. Otherwise, we would have to know in advance how
many values to pass down, which basically would involve duplicating the
`background-position` parsing code inside `background`.
The StyleValue is PositionStyleValue, since it represents a
`<position>`: https://www.w3.org/TR/css-values-4/#typedef-position
Unfortunately, background-position's parsing is a bit different from
`<position>`'s, (background-position allows 3-value syntax and
`<position>` doesn't) so we'll need to come back and write a different
parsing function for that later.
This allows supporting websites to use a light or dark theme to match
our desktop theme, without being limited to palette colors. This can be
overridden with the `WebContentServer::set_preferred_color_scheme()` IPC
call.
When using bitmap fonts, the computed *font* that we're using may be
smaller than the font-size property asked for. We can still honor the
font-size value in layout calculations.
This accounts for cases like:
```css
.foo {
color: blue ! important ;
}
```
That's rare now that minifying is so popular, but does appear on some
websites.
I've added spec comments to `consume_a_declaration()` while I was at it.
Noticed this while checking some MediaWiki-based sites. It's not
obvious, but the spec does allow this, by not mentioning it in this list
of places whitespace is forbidden:
https://www.w3.org/TR/selectors-4/#white-space
This works at the Token level, which is quick and easy but has
drawbacks: We don't know when something is a property name or a value,
or if something is part of a selector. But, this works for now.
The only reason it wasn't const before (and why we had a const_cast
hack) was to support ImageStyleValue's constructor taking it, which no
longer applies. `hack_count--;` :^)
This always felt awkward to me, and required a few other hacks to make
it work. Now, the request is only started when `load_bitmap()` is
called, which we do inside `NodeWithStyle::apply_style()`.
Pro tip: If your function takes a StringBuilder by value, it doesn't
actually append anything to the caller's StringBuilder. On the plus
side, I probably won't make this mistake for a while? I hope?
We want to check the last SimpleSelector, not the first one. We don't
have to check that a SimpleSelector exists since a CompoundSelector
without one is invalid.
Also, renamed `builder` to `s` to match spec comments, and fixed a
find-and-replace typo where some pseudo-class names were
"last-of-pseudo_class" instead of "last-of-type".
This implements these algorithms from the CSSOM-1 spec:
- serialize a string
- serialize a URL
Also, we now have two versions of each of the serialization functions:
One that returns a String as before, and the other that takes a
StringBuilder to write into. This saves creating extra StringBuilders
when they are not needed. :^)