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.
