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.)
We don't support all parts of the font formats we assume as "supported"
in the CSS parser. For example, if an open type font has a CFF table, we
reject loading it. This meant that until now, when such an
unsupported-supported font url was first in the list of urls, we
couldn't load it at all, even when we would support a later url.
To resolve that, try loading all font urls one after each other, in case
we are not able to load the higher priority one.
This also resolves a FIXME related to spec compliant url prioritization.
Our CSS parser already filters and prioritizes font src urls in
compliance with the spec. However, we still had to resort to brittle
file extension matching, because some websites don't set the `format`
and if the first url in a src list happened to be one we don't support,
the font could not be loaded at all. This now is unnecessary because we
can try and discard the urls instead.
Use FlyString::from_deprecated_fly_string() in these instances instead
of FlyString::from_utf8(). As we convert to new FlyString/String we want
to be aware of these potential unnecessary allocations.
This relied on pulling the current realm from the main thread VM, which
requires an execution context to be on the VM's stack. This heavily
relied on the dummy execution context that is always on the stack, for
example, when parsing the UA style sheets where no JavaScript is
running.
This requires Parser to be movable, so we remove the `default`
destructors from Parser and TokenStream, and give them both move
constructors. Since TokenStream only holds a reference to its tokens,
(and it needs to, to avoid copying when given eg a function's contents,)
we add a manual move constructor for Parser which creates a new
TokenStream from the new Parser's tokens, and then manually copies the
old TokenStream's state.
Instead of constructing a Tokenizer and then calling parse() on it, we
now call `Tokenizer::tokenize(...)` directly. (Renamed from `parse()`
because this is a Tokenizer, not a Parser.)
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
Like the name suggests this pointer type compares its pointees by value
rather than just by the pointer. This is needed for the defaulted
struct Properties equality operator.
This commit also contains a few changes to StyleValue such as replacing
the operator==()s with a .equals() again. This is done to avoid the new
reversed operator==()s ambiguity in C++20.
DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so
let's rename it to A) match the name of DeprecatedString, B) write a new
FlyString class that is tied to String.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Prevent media query parser from falling back into
MediaQuery::create_not_all() for queries with unknown media type.
With this change following test works correctly:
http://wpt.live/css/css-conditional/at-media-001.html
This parses conic-gradient()s while also attempting to share the bulk
of the parsing code with linear-gradient()s. This is done by extracting
the <color-stop-list> parsing to a "fill in the blacks" generic
function. This is a little awkward but cuts down on a lot of copy
pasting of code.
This parses <position> according to the following grammer:
<position> = [
[ left | center | right ] || [ top | center | bottom ]
|
[ left | center | right | <length-percentage> ]
[ top | center | bottom | <length-percentage> ]?
|
[ [ left | right ] <length-percentage> ] &&
[ [ top | bottom ] <length-percentage> ]
]
The code is a little hairy and simply tries each alternative in turn,
manually checking the possible orders. There may be a better way to
represent this.
Refactor various classes in the GridTrackSize file for the incoming
named_tracks feature.
Previously the ExplicitTrackSizing had mixed responsiblities with the
newly-named GridRepeat class. This made it so it was not possible to
have multiple repeats within a single 'GridTrackSizeList' definition.
The MetaGridTrackSize class had both the responsibilities of being a
container for minmax values as well as for simple GridSizes. By uniting
the different possible values (repeat, minmax, default) into the
ExplicitGridTrack class are able to be more expressive as to the
different grid size modalities.
The GridTrackSizeList will be useful as compared to a
Vector<ExplicitGridTrack> since this way can keep track of the declared
line names. These same line names are able to be declared within the
values of a repeat function, hence the presence of a GridTrackSizeList
inside the GridRepeat class.
Add classes ExplicitTrackSizing and MetaGridTrackSize which will allow
for managing properties like auto-fill and minmax.
In the following CSS example there are 3 classes that will be used:
grid-template-column: repeat(auto-fill, minmax(50px, 1fr) 75px);
ExplicitTrackSizing - will contain the entire value. e.g.
repeat(auto-fill, minmax(50px, 1fr) 75px)
With a flag if it's a repeat, as well as references to the
MetaGridTrackSizes which is the next step down.
MetaGridTrackSize:
Contain the individual grid track sizes. Here there are two:
minmax(50px, 1fr) as well as 75px.
This way can keep track if it's a minmax function or not, and the
references to both GridTrackSizes in the case it is, or in just the one
if it is not.
GridTrackSize:
Is the most basic element, in this case there are three in total; two of
which are held by the first MetaGridTrackSize, and the third is held by
the second MetaGridTrackSize.
Examples: 50px, 1fr and 75px.
Add ability to use values passed to grid-template-columns and
grid-template-rows for CSS Grid layout within a repeat() function.
E.g. grid-template-columns: repeat(2, 50px); means to have two columns
of 50px width each.
These changes improve the parsing of the span property, including
handling negative values for the span (defaults to 1), as well as when
no number is passed (also defaults to 1).
Implement span correctly when indicated in the grid-column-start,
grid-row-start, etc. CSS properties. Previously it had been implemented
as if span was something that went alongside the position property, but
actually it seems like if you do 'span 3' in the grid-column-start
property, for example, this means it literally spans 3 blocks, and the
3 has nothing to do with position.
When matching selectors in HTML documents, we know that all the elements
have lowercase local names already (the parser makes sure of this.)
Style sheets still need to remember the original name strings, in case
we want to match against non-HTML content like XML/SVG. To make the
common HTML case faster, we now cache a lowercase version of the name
with each type/class/id SimpleSelector.
This makes tag type checks O(1) instead of O(n).
I don't see any indication in the spec that an empty prelude should be
disallowed. This fixes rules like `@font-face{...}` (note the absence
of whitespace before the `{`.)
To follow spec more closely, only set the has_span value if there is a
number immediately following, like "span 2". Otherwise the span value
should be ignored.
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
This commit fixes a bug found when passing exotic values in the
grid-template-columns (or grid-template-rows) which are not yet
supported.
The bug seems to have been something like:
grid-template-columns: 0 minmax(0, calc(10px - var(--some-color)));
Add functionality to begin parsing grid-template-columns and
grid-template-rows. There are still things to be added, like parsing
functions, but I would say a couple of the major points are already
adressed like length, percentage, and flexible-length.
The only accepted syntax for these seems to be
<color> <length percentage> <length percentage>, no other order.
But that's just gathered from looking at other browsers as though
these are supported by all major browsers, they don't appear in
the W3C spec.
The -webkit version of linear-gradient does not include the `to`
before a <side or corner>. The angles of the <side or corner>
for the webkit version are also opposite that of the standard one.
So for the standard: linear-gradient(to left, red, blue)
The webkit version is: -webkit-linear-gradient(right, red, blue)
Adding the `to` in the -webkit version is invalid, omitting it in
the standard one is also invalid.
These will be needed for styling progress bars, sadly this can
only be done with these non-standard selectors. These are, hovever,
in use on real sites such as https://rpcs3.net/compatibility.
As noted, we should probably handle calc() parsing as part of parsing
other values. eg, any `<length>` can be a `calc()` that returns a
length, but we currently have to manually handle that everywhere that
doesn't use the `Parser::parse_css_value(ComponentValue)` method.
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This commit has no behavior changes.
In particular, this does not fix any of the wrong uses of the previous
default parameter (which used to be 'false', meaning "only replace the
first occurence in the string"). It simply replaces the default uses by
String::replace(..., ReplaceMode::FirstOnly), leaving them incorrect.
The lack of the commit() before returning the x_value here meant,
that in parse_background_value() the token stream would be one token
behind after parsing the background-size. This led to it to returning
null, after it sees the unexpected 'second' contain / cover token.
With this change all of backgrounds.html is working again.
This prevents font-face rules without a block statement from crashing
LibWeb during CSS parsing.
The issue was discovered by Lubrsi during CSS parser fuzzing. :)
Fixes#14141.
Implement parsing of rgb(..) and hsl(..) in both the modern level 4
syntax without commas, and the legacy syntax with commas.
The parser accepts non-integer numbers but rounds to integer values
for now.
Previously, `var()` inside functions like `rgb()` wasn't resolved.
This will set the background color for badges in the New category on
https://ports.serenityos.net. :^)
When parsing <ndash-dimension> <signless-integer>, we tried to parse
a new token from the stream instead of using the value we had already
extracted. This caused pages that used the syntax to crash.
...and change how the two parsing steps fit together.
The two steps were previously quite muddled. Both worked with the
TokenStream directly, and both were responsible for rewinding that
stream if there was an error. This is both confusing and also made it
impossible to replace the rewinding with StateTransactions.
This commit more clearly divides the work between the two functions: One
parses ComponentValues and produces a string, and the other parses that
string to produce the UnicodeRange. It also replaces manual rewinding
in the former with StateTransactions.
This should be a bit easier to follow.
parse_media_query() no longer rewinds if the media query is invalid,
because it then interprets all the tokens as a "not all" query.
`a` and `b` had to be declared at the top of the function before since
they were used by the `make_return_value()` lambda. But now that
doesn't exist, we can move them to where they are used - or eliminate
them entirely.
parse_a_n_plus_b_pattern()'s job is to parse as much of the TokenStream
as it can as a An+B, and then stop. The caller can then deal with any
trailing tokens as it wishes.
...using a ParseErrorOr type alias.
This lets us replace a bunch of manual error-checking with TRY. :^)
I also replaced the ParsingResult::Done value with returning an
Optional. I wasn't happy with treating "Done" as an error when I first
wrote this, and this makes a clear distinction between the two.
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.
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.
The goal here is to move the parser-internal classes into this namespace
so they can have more convenient names without causing collisions. The
Parser itself won't collide, and would be more convenient to just
remain `CSS::Parser`, but having a namespace and a class with the same
name makes C++ unhappy.
This is used to skip downloading fonts in formats that we don't support.
Currently we only support TTF as far as I am aware.
The parts of a `src` are in a fixed order, unusually, which makes the
parsing more nesty instead of loopy.
Like, An+B, this is an old construct that does not fit well with modern
CSS syntax, so things get a bit hairy! We have to determine which
tokens match the grammar for `<urange>`, then turn those back into a
string, and then parse the string differently from normal. Thankfully
the spec describes in detail how to do that. :^)
This is not 100% correct, since we are not using the original source
text (referred to in the spec as the "representation") of the tokens,
but just converting them to strings in a manual, ad-hoc way.
Re-engineering the Tokenizer to keep that original text was too much of
a tangent for today. In any case, we do parse `U+4???`, `U+0-100`,
`U+1234`, and similar, so good enough for now!
"Component value" is the term used in the spec, and it doesn't conflict
with any other types, so let's use the shorter name. :^)
Also, this doesn't need to be friends with the Parser any more.
We're calling this in a way that is incorrect, and so the algorithm's
assumption that the next token is an `<ident-token>` is wrong, and we
have to handle that failing. Ideally we would just stop calling this
incorrectly, but until then, let's actually document what is happening.
The code had to change a bit to match. Previously, we appended an empty
sub-list immediately, but now we append it at the end. The difference
is that if there are no tokens, we now correctly return an empty
list-of-lists, instead of a list containing an empty list.
We now correctly call convert_to_rule() outside of this function.
As before, I've renamed `parse_as_rule()` -> `parse_as_css_rule()` to
match the free function that calls it.
This is not actually used by anything currently, but it should be used
for `@media` and other at-rules.
Removed the public parse_as_list_of_rules() because public functions
should be things that outside classes actually need to use.
`parse_a_stylesheet()` should not do any conversion on its rules. This
change corrects that. There are other places where we get this wrong,
but one thing at a time. :^)
CSS Values and Units Module Level 5 defines attr as:
`attr(<q-name> <attr-type>?, <declaration-value>?)`
This implementation does not contain support for the type argument,
effectively supporting `attr(<q-name>, <declaration-value>?)`
When parsing the "style" attribute on elements, we'd previously ask the
CSS parser for a PropertyOwningCSSStyleDeclaration. Then we'd create a
new ElementCSSInlineStyleDeclaration and transfer the properties from
the first object to the second object.
This patch teaches the parser to make ElementCSSInlineStyleDeclaration
objects directly.
When I wrote the An+B parser, it was guaranteed to have no
non-whitespace tokens after it. This is no longer true with the `of
foo` syntax, so this patch corrects the logic when there is no `+B`
segment.
This makes this case shown on Twitter work correctly. :^)
https://twitter.com/simevidas/status/1506657566012678151
`text-shadow` does not support this, so this way we can still use the
same parsing code.
It's OK that we still assign a ShadowPlacement value to the
ShadowStyleValue, since it will just get ignored when painting
text-shadows, but if it appears in the property value then that is a
syntax error.
The `text-shadow` property is almost identical to `box-shadow`:
> Values are interpreted as for box-shadow [CSS-BACKGROUNDS-3].
> (But note that the inset keyword are not allowed.)
So, let's use the same data structures and parsing code for both. :^)
There's really no reason to use doubles here, except at the time I
wanted to use doubles everywhere in CSS. I now realize that is
excessive, so everything can be floats instead.
There was no real benefit to creating the SimpleSelector early and then
modifying it, and doing so made this code harder to follow than it
needs to be.
