We had `parse_calculated_value()` which parsed the contents of `calc()`,
and `parse_dynamic_value()` which parsed any math function, both of
which produce a CalculatedStyleValue, but return a plain StyleValue.
This was confusing, so let's combine them together, and return a
CalculatedStyleValue.
This also makes the other math functions work in
`StyleComputer::expand_unresolved_values()`.
This would cause a nullptr-deref during painting of invalid
linear-gradients, such as `linear-gradient(top, #f8f9fa, #ececec)`
found in googles sign-in button
We now keep the color value as a StyleValue up until we go to paint the
gradient, which makes `currentColor` work, along with any other color
values that can't be immediately converted into a `Gfx::Color` while
parsing.
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
We don't yet set the Document's target element in most cases, so this
does not function very well. But that will improve once we *do* set it,
which involves a more complete Navigables implementation.
For now, we parse these, but don't actually consider the namespace when
matching them. `DOM::Element` does not (yet) store attribute namespaces
so we can't check what they are.
Holding the `prefix` as a StringView meant it pointed at string data
held by `token`. `token` gets reassigned shortly afterwards, meaning
`prefix` would hold invalid character data.
This is basically a name with a namespace prefix. It will be used for
adding namespaces to Universal, TagName, and Attribute selectors.
For convenience, this can also optionally parse/store the `*` wildcard
character as the name.
We were already parsing non-function-syntax :host, so let's also do
the :host(...) variant. Note that we don't have matching for these yet.
This fixes many issues on sites generated by Wix, as they often have
selector lists that include some :host() selector, and we'd reject the
entire rule after failing to parse it.
Don't give up if we can't parse that single value for the property
directly, but let the parsing code carry on and see if we can produce a
CompositeStyleValue.
CSS shouldn't probably check if a MIME type in the 'data:' URL is
correct or not. Every URL gets sent to a ResourceLoader so a client can
just validate if got file with correct media type.
This also makes loading 'data:' URLs in @import work now, as we didn't
have AllowedDataUrlType for stylesheets.
If a math function resolves to `<length>` or `<percentage>`, then it
will by definition also resolve to `<length-percentage>`. (Same for any
other basic types.) Since we were checking `<length-percentage>` first
and then bailing if no given properties could accept that, math
functions would always fail to match a property that just accepts a non
`-percentage` type.
This is a universal value like `initial` and `inherit` and works by
reverting the current value to whatever we had at the start of the
current cascade origin.
The implementation is somewhat inefficient as we make a copy of all
current values at the start of each origin. I'm sure we can come up with
a way to make this faster eventually.
Note that we currently can't resolve calc() values without a layout
node, so when normalizing an image's source set, we'll flush any pending
layout updates and hope that gives us an up-to-date layout node.
I've left a FIXME about implementing this in a more elegant and less
layout-thrashy way, as that will require more architectural work.
This change makes tree builder omit elements with "display: contents"
from the layout tree during construction. Their child elements are
instead directly appended to the parent element in layout tree.
When specifying either `background-position-x: right` or
`background-position-y: bottom` without an offset value no
EdgeStyleValue was created.
However, the spec says the offset should be optional.
Now, if you do not provide an offset, it creates the EdgeStyleValue
with a default offset of 0 pixels.
We're gonna call parse_a_comma_separated_list_of_component_values from
another cpp file soon, so let's prepare for that by instantiating the
specific version we need.
This commit makes it possible to let properties accept easing functions
as values, which will be used in a later commit to implement
animation-timing-function.
We achieve this by making properties that accept a custom-ident value
skip the "someone else's vendor prefix" check for values that start with
a `-` character.
This fixes an issue where e.g `font-family: Arial, -apple-system` would
be rejected by the parser completely. We now treat `-apple-system` like
an identifier in such cases.
Also add `valid-types` metadata for the `font-family` property so this
actually works. :^)
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.
