We were hard-coding "about:blank" as the document URL for parsed HTML
documents, which was definitely not correct.
This fixes a bunch of WPT tests under /domparsing/ :^)
On any `display: list-item` Node a CSS pseudo element (`::marker`) needs
to be created. This commit allows the ::maker pseudo element to be
nested within other pseudo elements (e. g. ::before or ::after).
This fixes this WPT test:
http://wpt.live/css/CSS2/generated-content/after-content-display-003.xht
This resolves all WPT timeouts in html/canvas/element/manual/imagebitmap
We can now run an additional 6 tests and 126 subtests :)
This also adds regression tests for this behavior.
InlinePaintable was an ad-hoc paintable type required to support the
fragmentation of inline nodes across multiple lines. It existed because
there was no way to associate multiple paintables with a single layout
node. This resulted in a lot of duplicated code between PaintableBox and
InlinePaintable. For example, most of the CSS properties like
background, border, shadows, etc. and hit-testing are almost identical
for both of them. However, the code had to be duplicated to account for
the fact that InlinePaintable creates a box for each line. And we had
quite many places that operate on paintables with a code like:
```
if (box.is_paintable_box()) {
// do something
} else (box.is_inline_paintable()) {
// do exactly the same as for paintable box but using InlinePaintable
}
```
This change replaces the usage of `InlinePaintable` with
`PaintableWithLines` created for each line, which is now possible
because we support having multiple paintables per layout node. By doing
that, we remove lots of duplicated code and bring our implementation
closer to the spec.
CSS fragmentation implies 1:N relationship between layout nodes and
paintables. This change is a preparation for implementation of inline
fragmentation where InlinePaintable will be replaced with
PaintableWithLines corresponding to each line.
Always create a new formatting context for <math> elements. Previously
that didn't happen if they only had inline children, e.g. mtable.
This fixes a crash in the WPT MathML test
mathml/crashtests/children-with-negative-block-sizes.html
A couple of parts of this:
- Store the source text for Declarations of custom properties.
- Then save that in the UnresolvedStyleValue.
- Serialize UnresolvedStyleValue using the saved source when available -
that is, for custom properties but not for regular properties that
include var() or attr().
This is in a weird position where the spec tells us to discard the
comments, but then we have to preserve the original source text which
may include comments. As a compromise, I'm treating each comment as a
whitespace token - comments are functionally equivalent to whitespace
so this should not have any behaviour changes beyond preserving the
original text.
Previously we would serialize these as the empty string. eg, this:
```
<div style="grid-auto-columns: auto"></div>
```
would have a computed `grid-auto-columns` value of ``.
In order to know whether `calc(2.5)` is a number or an integer, we have
to see what the property will accept. So, add that knowledge to
`Parser::expand_unresolved_values()`.
This makes `counter-increment: foo calc(2 * var(--n));` work correctly,
in a test I'm working on.
Selectors and at-rules both made assumptions about their indentation
level, which made it difficult to read the dump output. It'll become
even worse once rules can be further nested within each other, so let's
fix it now. :^)
This will be the first step is making better use of system libraries
like fontconfig and CoreText to load system fonts for use by the UI
process and the CSS style computer.
This reverts 6d25bf3aac
Invalidating the style here means that transitions can cause an element
to leave style computation with its "needs style update" flag set to
true. This then causes a VERIFY to fail in the TreeBuilder.
This invalidation does not otherwise seem to have any effect. The
original commit suggests this was to fix a bug, but it's not clear what
bug that was. If it reappears, we can try to solve the issue in a
different way.
I had made a stab at implementing this to determine whether it could
assist in fixing an issue where scroll_to_the_fragment was not getting
called at the appropriate time. It did not fix that issue, and actually
ended up breaking one of our in tree tests. In the meantime, factor out
this method into a standalone function.
These don't have to worry about the input not being valid UTF-8 and
so can be infallible (and can even return self if no changes needed.)
We use this instead of Infra::to_ascii_{upper,lower}_case in LibWeb.
