All of the following properties in the font shorthand can be `normal`:
- font-style
- font-variant
- font-weight
- font-stretch
This means that we must allow up to four consecutive `normal` at the
start of a font shorthand value.
`parse_a_calc_function_node()` only detects math functions, but
regularly encounters unrelated functions like `rgba()`. Since we now
support all the math functions, this message is just misleading spam.
The CSS box-shadow property takes 2-4 properties that are `<length>`s,
those being:
- offset-x
- offset-y
- blur-radius
- spread-radius
Previously these were resolved directly to concrete Lengths at parse
time, but now they will be parsed as LengthStyleValues and/or
CalculatedStyleValues and be stored that way until styles are later
resolved.
Previously, using an identifier color like `currentColor` would fail to
parse, since we look at ident tokens (and reject unrecognised ones)
before trying to parse colors.
Instead of hard-coding a check for "calc", we now call out to
parse_dynamic_value() which allows use of other functions like min(),
max(), clamp(), etc.
Anywhere that `<number>` appears in the grammar, `calc()` that resolves
to a number is valid, including inside the `<ratio>` grammar.
Thankfully, a calculation that produces a number cannot rely on any
context information for the calculation, so we can resolve them
straight away and just pretend they were a `<number>` the whole
time. :^)
`foo.is(Token::Type::Delim) && foo.token().delim() == '!'` becomes
`foo.is_delim('!')`, which is a lot less verbose. I really should have
done this ages ago.
This fixes the issue that currently we use "auto" as initial value for
grid-template-column and grid-template-rows although spec says it
should be "none". This makes a lot of difference for these properties
because currently we represent "auto" as a list with one auto-sized
track which means initial value for grid-template-column defines one
"explicit" track while it should define none of them.
This change makes grid-auto-columns/rows be applied to the correct
tracks when initial values is used for grid-template-column/rows.
Wrap the parsing of numbers, integers, and dimensions in a transaction,
which we only commit if that parsed value was actually accepted by the
property.
This fixes `font: 0/0 a;` failing to parse.
This reintroduces bounds-checking for the CSS `<angle>`, `<frequency>`,
`<integer>`, `<length>`, `<number>`, `<percentage>`, `<resolution>`,
and `<time>` types.
I regressed this around 6b8f484114 when
changing how we parsed StyleValues.
This is an improvement from before though, since we now allow the bounds
of a dimension type to have units.
Added a test to make sure we don't regress this again. :^)
Having one StyleValue for `<number>` and `<integer>` is making user code
more complicated than it needs to be. We know based on the property
being parsed, whether it wants a `<number>` or an `<integer>`, so we
can use separate StyleValue types for these.
This partially implements CSS-Animations-1 (though there are references
to CSS-Animations-2).
Current limitations:
- Multi-selector keyframes are not supported.
- Most animation properties are ignored.
- Timing functions are not applied.
- Non-absolute values are not interpolated unless the target is also of
the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px).
- The JavaScript interface is left as an exercise for the next poor soul
looking at this code.
With those said, this commit implements:
- Interpolation for most common types
- Proper keyframe resolution (including the synthetic from-keyframe
containing the initial state)
- Properly driven animations, and proper style invalidation
Co-Authored-By: Andreas Kling <kling@serenityos.org>
The comment mentions that zero is let through, but then immediately
errors out if it sees any number outside quirks mode.
This commit makes that check let zeros through.
Specifically, stop letting NumericStyleValues holding `0` from
pretending to hold a Length. The parser is now smart enough that we
don't have to do this. :^)
We're about to stop letting 0 NumericStyleValues pretend to be Lengths,
so this will break. As noted, the flex-basis property accepts
`<length>` not `<number>` so this is actually correct.
Introduces incomplete parsing of grid shorthand property. Only
<grid-template> part of syntax is supported for now but it is enough
to significantly improve rendering of websites that use this shorthand
to define grid :)
We know what types and identifiers a property can accept, so we can use
that information to only parse things that can be accepted. This solves
some awkward ambiguity problems that we have now or will face in the
future, including:
- Is `0` a number or a length with no unit?
- Is `3.5` a number or a ratio?
- Is `bottom` an identifier, or a custom-ident?
Two CSS Parser methods are introduced here:
`parse_css_value_for_property()` attempts to parse a StyleValue that the
property can accept, skipping any types that it doesn't want.
`parse_css_value_for_properties()` does the same, but takes multiple
PropertyIDs and additionally returns which one the parsed StyleValue is
for. This is intended for parsing shorthands, so you can give it a list
of longhands you haven't yet parsed.
Subsequent commits will actually use these new methods.
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.)
