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.
This fixes stucking in a loop at the end of the file, as
(a) custom block sizes are usually placed there, as the remaining
size might not be simply calculated as a power of two, and
(b) the number of bytes to read was incorrect (the program said
the block size was 32525, where flac -a said it's actually 3200).
Unfortunately, I couldn't trigger the bug for the sample rates,
so it may be not true, but I'd doubt it, giving the fact that flac
almost everywhere uses big endian numbers.
This removes all the hard-coded kernel base addresses from userspace
tools.
One downside for this is that e.g. Profiler no longer uses a different
color for kernel symbols when run as a non-root user.
This also implements the CodePointAt abstract operation. This is needed
to handle invalid code units specific to the JavaScript spec, rather
than e.g. inserting replacement code units. This abstraction is public
because RegExp.prototype will also need it.
LibJS parses JavaScript as UTF-8, so when creating a string, we must
transcode it to UTF-16 to handle encoded surrogate pairs.
For example, consider the following string:
"\ud83d\ude00"
The UTF-8 encoding of this surrogate pair is:
0xf0 0x9f 0x98 0x80
However, LibJS will currently store the two surrogates individually as
UTF-8 encoded bytes, rather than combining the pair:
0xed 0xa0 0xb8, 0xed 0xb8 0x80
These are not equivalent. So, as String.prototype becomes UTF-16 aware,
this encoding will no longer work for abstractions like strict equality.
These methods did not require UTF-16 views, so just add test cases to
ensure they remain correct.
This also adds a couple of FIXME comments on tests that will fail even
with UTF-16 String.prototype support (for reasons such as lack of UTF-16
support in RegExp.prototype and Unicode case folding).
