The Display class already supported all specific values, and now they
will be parsed too. The display property now has a special type
DisplayStyleValue.
Now that LengthStyleValue never contains `auto`, IdentifierStyleValue is
the only type that can hold an identifier. This lets us remove a couple
of virtual methods from StyleValue.
I've kept `has_auto()` and `to_identifier()` for convenience, but they
are now simple non-virtual methods.
Previously, whether trying to parse a `<length>` or `<dimension>`, we
would accept `auto` and produce a `LengthStyleValue` from it. This
would fool the `property_accepts_value()` into allowing `auto` where it
does not belong, if the property did accept lengths.
Of the few places in the parser that called `parse_dimension_value()` or
`parse_length()`, none of them were expecting it to accept `auto`, so
this fixes those too. :^)
Currently, `property_accepts_value()` always returns `true` if the
property is a shorthand. (This is a bug, and should actually be fixed
properly at some point...) This means that all identifiers are caught
here, including `auto`, which should be handled by the `flex-basis`
branch instead.
This works currently because `auto` is a LengthStyleValue, but that's
about to change!
This code assumed that `auto` was always stored as a LengthStyleValue,
which will not be true in the next commit. (And was not a safe
assumption to make anyway.)
This is a tiny bit messy because:
- The spec says we should expand this to `flex: <flex-grow> 1 0`
- All major engines expand it to `flex: <flex-grow> 1 0%`
Spec bug: https://github.com/w3c/csswg-drafts/issues/5742
VALUES-4 defines the internal representation of `calc()` as a tree of
calculation nodes. ( https://www.w3.org/TR/css-values-4/#calc-internal )
VALUES-3 lacked any definition here, so we had our own ad-hoc
implementation based around the spec grammar. This commit replaces that
with CalculationNodes representing each possible node in the tree.
There are no intended functional changes, though we do now support
nested calc() which previously did not work. For example:
`width: calc( 42 * calc(3 + 7) );`
I have added an example of this to our test page.
A couple of the layout tests that used `calc()` now return values that
are 0.5px different from before. There's no visual difference, so I
have updated the tests to use the new results.
Level 4 drops the limitations of what types can be a denominator, which
means `<calc-number-sum>`, `<calc-number-product>` and
`<calc-number-value>` all go away.
This parses the new background-position-x/y longhands and properly
hooks up them up. This requires converting PositionStyleValue to
just contain two EdgeStyleValues so that it can be easily expanded
into the longhands.
...and replace it with AngleOrCalculated.
This has the nice bonus effect of actually handling `calc()` for angles
in a transform function. :^) (Previously we just would have asserted.)
