- Don't add multiple numbers to nested steps, just the innermost one
(as rendered in the HTML document)
- "Otherwise" comments go before the else, not after it
- "FIXME:" goes before step number, not between it and the comment text
- Always add a period between number and comment text
The majority of these were introduced in #13756, but some unrelated ones
have been updated as well.
Every StyleValue type now has its own `equals()` method, rather than
relying on the default "compare the to_string() output" method, which
has now been removed. This logic is still used by UnresolvedSV and
CalculatedSV, because it's probably the best option for them unless
performance becomes a real issue.
Also took this opportunity to move all the `equals()` implementations
into the .cpp file, which may or may not actually help with compile
times but StyleValue.h is huge and included everywhere, so it can't
hurt.
The spec grammar for `text-decoration-line` is:
`none | [ underline || overline || line-through || blink ]`
Which means that it's either `none`, or any combination of the other
values. This patch makes that parse for `text-decoration-line` and
`text-decoration`, stores the results as a Vector, and adjusts
`paint_text_decoration()` to run as a loop over all the values that are
provided.
As noted, storing a Vector of values is a bit wasteful, as they could be
stored as flags in a single `u8`. But I was getting too confused trying
to do that in a nice way.
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 function was written as if it returned `Optional<CSS::BoxSizing>`
but actually returned a plain `CSS::BoxSizing`, meaning if the property
was not set or was invalid, it would return whichever enum value was
first. This wasn't visible because we don't yet pay any attention to
the `box-sizing` property.
Alias values are represented by "alias-name=real-name".
We have a lot of repetitive code for converting between ValueID and
property-specific enums. Let's see if we can generate it. :^)
This first step just produces the enums, from a JSON file. The values in
there are a duplication of what's in Properties.json, but eventually
those will go away.
As before, this requires deviating from the spec slightly to create the
StyleRule fully-formed instead of creating it empty and then modifying
its internals.
This means deviating slightly from the spec in order to construct a
fully-initialized Declaration instead of creating an empty one and then
poking at its internals.
DeclarationOrAtRule should probably use a Variant, but for now, making
its Declaration member optional is quick and easy.
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.
