This moves LibWeb to using the list of hidden elements from the spec.
Concretely, the following things are now explicitly marked
`display: none` in addition to before:
- elements with the `hidden` attribute
- area
- base
- basefont
- datalist
- param
- rp
The spec also wants `noframes` and `noembed` to be `display: none`,
but since support for frames and embeds doesn't exist yet, these
are omitted for now.
With this, everyone's favorite website http://45.33.8.238/ no longer
displays spans with attribute hidden. (Whitespace handling still
looks a bit off though.)
Despite looking like it was still needed, it was only used for passing
to other calls to Length::resolved() recursively. This makes the
various `foo.resolved().resolved()` calls a lot less awkward.
(Though, still quite awkward.)
I think we'd need to separate calculated lengths out to properly tidy
these calls up, but one yak at a time. :^)
A lot of this is quite ugly, but it should only be so until I remove
Length::Type::Percentage entirely. (Which should happen later in this
PR, otherwise, yell at me!) For now, a lot of things have to be
resolved twice, first from a LengthPercentage to a Length, and then
from a Length to a pixel one.
The flexbox logic confuses me so regressions are possible, though our
test page looks the same as before so it should be fine.
Renamed FlexBasis::Length -> LengthPercentage too, for clarity.
This does undo the changes in 88c32836d8,
which accounted for our bitmap fonts being a different size than the
`font-size` property requests. I think this would be better handled
inside Length::to_px(), which would then apply to all font-size-relative
lengths (eg, em and rem) instead of only for the line-height property.
Layout::Node still treats border radii as having a single value instead
of horizontal and vertical, but one less hack is nice, and helps with
conversion to LengthPercentage. :^)
This is in a slightly weird state, where Percentages are sometimes
Lengths and sometimes not, which I will be cleaning up in subsequent
commits, in an attempt not to change all of LibWeb in one go. :^)
Length and Percentage are different types, and sometimes only one or the
other is allowed in a given CSS property. This is a first step towards
separating them.
This is in line with this recent change to Conditional-3:
> Removed the “unknown” value in CSS feature queries’ boolean logic,
> defining unrecognized syntaxes as “false” instead.
> https://github.com/w3c/csswg-drafts/issues/6175
This means you can now do queries like:
```css
@media (400px <= width < 800px) { }
```
Chromium and Firefox which I tested with both don't support this yet, so
that's cool. :^)
Past me decided that the grammar was overly verbose and I could do it
better myself. Which seemed fine until the spec changed and I didn't
know how to integrate the changes. Lesson learned! :^)
Rather than have a function for every single part of the grammar, I have
written some as lambdas, and combned `<media-condition>` and
`<media-condition-without-or>` into one function. But otherwise it's
close to the spec, with comments listing the part of the grammar being
parsed, so hopefully it will be easier to make future adjustments!
This does not add any new functionality.
Web::CSS::MediaQuery::MediaFeature::Type was getting a bit ridiculous!
Also, this moves the detection of "min-" and "max-" media-features into
the MediaFeature itself, since this is an implementation detail, not
part of the spec.
Having these in here was a hack to support the other hack of making
media-queries use StyleValues. Now they don't do that, so we can remove
these again and keep things hygienic.
Previously, we were using StyleValues for this, which was a bit of a
hack and was brittle, breaking when I modified how custom properties
were parsed. This is better and also lets us limit the kinds of value
that can be used here, to match the spec.
This means we can get rid of the hacks where we were peeking a code
point instead of getting the next one so that we could peek_twin()
later. Now, we follow the spec more closely. :^)
This fixes the crash that Luke found using Domato:
```css
. foo {
mso-border-alt: solid .-1pt;
}
```
The spec distinguishes between "If the next 3 code points would
start..." and "If the input stream starts with..." but we were treating
them the same way, skipping the first code point in the process.
These correspond to "If the input stream starts with..." in the spec,
which up until now we were not handling correctly, which led to some fun
bugs.
As noted, reconsuming the input code point in order to read its value is
hacky, but works. Keeping track of the current code point in Tokenizer
would be nicer, when I'm feeling brave enough to mess with it!
This option is already enabled when building Lagom, so let's enable it
for the main build too. We will no longer be surprised by Lagom Clang
CI builds failing while everything compiles locally.
Furthermore, the stronger `-Wsuggest-override` warning is enabled in
this commit, which enforces the use of the `override` keyword in all
classes, not just those which already have some methods marked as
`override`. This works with both GCC and Clang.
We now detect situations like this, where variables infinitely recur,
without crashing:
```css
div {
--a: var(--b);
--b: var(--a);
background: var(--a);
}
p {
--foo: var(--foo);
background: var(--foo);
}
```
We now stop processing variables once a length of 16384 tokens is
reached. This is an arbitrary number, but should be far beyond what
anyone will reasonably use, and small enough to not crash.
If a property is custom or contains a `var()` reference, it cannot be
parsed into a proper StyleValue immediately, so we store it as an
UnresolvedStyleValue until the property is compute. Then, at compute
time, we resolve them by expanding out any `var()` references, and
parsing the result.
The implementation here is very naive, and involves copying the
UnresolvedStyleValue's tree of StyleComponentValueRules while copying
the contents of any `var()`s it finds along the way. This is quite an
expensive operation to do every time that the style is computed.
This represents a property value that hasn't been converted to a
"proper" StyleValue yet. That is, it's either a custom property's value,
or a value that includes `var()` references, (or both!) since neither of
those can be fully resolved at parse time.
Now that we can serialize CSS tokens, we can just hold a string and then
re-parse it when the Supports is evaluated. This feels a little weird,
but it only happens once so it's not going to slow it down much, and it
keep the API cleaner.
