If we finish parsing a calculation tree and it still contains
UnparsedCalculationNodes, then it's not valid, and we shouldn't create
a StyleValue from it.
The spec says: "The first value gives the width of the corresponding
image, the second value its height. If only one value is given the
second is assumed to be auto."
Fixes#18782
This necessitated returning `nullptr` instead of just `{}` in a lot of
places. Also, some temporary hackiness in `parse_css_value()`: That
returns a special `ParseError` type already, so we now have a
`FIXME_TRY()` macro which logs the error and then returns a generic
`ParseError::InternalError` value. Eventually this macro will go away,
once I figure out how to deal with this more nicely.
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.)
