The font property now resolves into its various parts:
- font-family
- font-weight
- font-size
- font-style
- line-height
The font-variant and font-stretch parts are left unparsed since LibWeb
doesn't know how to render those.
Added `fonts.html` as a test for various forms of `font` declarations,
based on the examples in the spec.
This resolves the three sub-properties, appearing in any order:
- list-style-image
- list-style-position
- list-style-type
Added `list-style-position` values to support this, though they are not
yet used in rendering.
This was broken when we switched away from using StringStyleValues.
While I was at it, I have implemented hsl/a() and the percentage
syntax for rgb/a().
As a bonus, added `colors.html` as a test page for the various CSS
color syntaxes, since nothing was testing rgb() or rgba() before.
Much of the parsing code in LibGFX/Color.h seems to be centered
around CSS color values, but this is not used by the new Parser.
(And can't be used, because it requires a String value and we have
a list of Tokens of some kind instead.) Maybe that should be removed
from there when the new CSS parser is operational.
This implements a lot of cases, but not all of them. The following
need more infrastructure first:
- Flex
- FlexFlow
- Background
- BackgroundImage
- BackgroundRepeat
- ListStyle and parts
- Font
Also, colors are not parsed correctly. This will be handled next.
Now that StyleResolver is going to deal with StyleComponentValueRules,
it will need to be able to parse those into StyleValues, using
`parse_css_value()`.
Also added StyleValue::is_builtin_or_dynamic(), which returns true for
values that are valid anywhere - things like `initial` and `inherit`,
along with `var()`, `attr()` and `calc()` - which we want to test for
easily.
We skip whitespace tokens while doing this. As far as I can tell,
whitespace is not useful once we get to this point, and it legally
may or may not appear between any two tokens. By not including it
in the ValueListStyleValue, we make the "if it has 3 parts"-type
checks a lot more straightforward.
As the new CSS parser tokenizes its input, we can no longer easily
rely on a StringStyleValue for multi-value properties. (eg, border)
ValueListStyleValue lets us wrap all of the ComponentValues that
the Parser produced for one declaration, as a single StyleValue, to
then be parsed into StyleValues by the StyleResolver.
Originally, I wanted it to be a list of StyleValues, but several
properties use syntax that makes use of non-StyleValue tokens, eg:
```css
/* Syntax using a / */
font: 12px/14px sans-serif;
/* Multiple values separated by commas */
background: url(catdog.png), url(another-image.jpg), blue;
```
Passing the ComponentValue tokens themselves means that all that
information is carried over. The alternative might be to create a
StyleValue subclass for each property and parse them fully inside
the Parser. (eg, `FontStyleValue`)
I decided against `ListStyleValue` as a name, to avoid confusion
with list styles. It's not ideal, but names are hard.
Rather than parsing the selector every time we want to check it, we
now parse it once at the beginning.
A bonus effect of this is that we now support a selector list in
:not(), instead of just a single selector, though only when using
the new parser.
The end goal is to make the PseudoClass::not_selector be a Selector
instead of a String that is repeatedly re-parsed. But since Selector
contains a Vector of ComplexSelectors, which each have a Vector of
SimpleSelectors, it's probably a good idea to not be passing them
around by value anyway. :^)
Same reasoning again! This is the last one.
While I was at it, I added the two remaining CSS2.2 pseudo-elements,
::first-line and ::first-letter. All 4 are handled in the new CSS
parser, including with the compatibility single-colon syntax. I have
not added support to the old parser.
Previously, SimpleSelectors optionally had Attribute-selector data
as well as their main type. Now, they're either one or the other,
which better matches the spec, and makes parsing and matching more
straightforward.
Calling is_valid_escape_sequence() with no arguments hides what it
is operating on, so I have removed that, so that you must explicitly
tell it what you are testing.
The call from consume_a_token() was using the wrong tokens, so it
returned false incorrectly. This was resulting in corrupted output
when faced with this code from Acid2. (Abbreviated)
```css
.parser { error: \}; }
.parser { }
```
Had to adjust some places that were using Token.to_string() for
non-debug-logging purposes. Changed its name to to_debug_string()
to make the usage clearer.
Whitespace marks the end of a compound-selector, no matter where
it occurs. `check_for_eof_or_whitespace()` reconsumes the whitespace
token for convenience.
The entry points for CSS parsing in the spec are defined as accepting
any of a stream of Tokens, or a stream of ComponentValues, or a String.
TokenStream is an attempt to reduce the duplication of code for that.
The end goal here is to make the two classes mostly interchangeable, as
the CSS spec requires that the various parser algorithms can take a
stream of either class, and we want to have that functionality without
needing to duplicate all of the code.
Rather than passing a ComponentType, and then manually modifying the
data fields, we now create them initialized.
The constructor that takes a Token is intentionally left implicit,
so that we can automatically convert when using the TokenStream later.
AtStyleRule being a subclass of QualifiedStyleRule was causing
problems when trying to distinguish between them. Combining them
and then distinguishing between them with a Type enum makes that
check simpler, and is in line with how similar checks are done
elsewhere in the parser.
The new one is the same as the old one, just in the new Parser's
source files. This isn't the most elegant solution but it seemed
like the best option. And it's all temporary, after all.
Previous implementation was returning everything in a single Vector,
when what we really want is a Vector of Vectors, one for each comma-
separated part of the list.
Optional seems like a good idea, but in many places we were not
checking if it had a value, which was causing crashes when the
Tokenizer was given malformed input. Using an EOF value along with
is_eof() makes things a lot simpler.
This is very much stubbed out for now. Most notably is
Parser::convert_rule() where most of the conversion will happen
from the parser's internal rule classes to CSSRule and its children.
