Previously we only supported a subset of the predefined counter styles,
we now respect counter styles defined by `@counter-style` rules when
resolving the value of `counter()` and `counters()` functions
There are some predefined counter styles (such as the longhand east
asian ones) which are too complex to be defined here and will need to be
implemented ad-hoc, this remains as a FIXME for now.
The tricky bit of this is resolving cycles in extending rules and
ensuring that counter styles are registered in the required order for
extension (i.e. for any pair of extended/extending rules the extended
one should be registered first).
This serves as an intermediate step between `CSSCounterStyleRule` and a
fully built counter style which will be helpful for:
- Determining whether a rule defines a counter style
- Resolving extends cycles
- Determining registration order
This exposes an existing issue with interpolation where it is not clear
in what situations zero-valued dimensions should be excluded from the
interpolated value of a dimension-percentage mix (e.g. `calc(50% + 0px)`
vs `50%`) - but this is just a serialization issue as both
representations are resolved to the same used value
Instead of using a custom paintable to draw the controls for video and
audio elements, we build them out of plain old HTML elements within a
shadow root.
This required a few hacks in the previous commits in order to allow a
replaced element to host children within a shadow root, but it's
fairly self-contained.
A big benefit is that we can drive all the UI updates off of plain old
DOM events (except the play button overlay on videos, which uses the
video element representation), so we can test our media and input event
handling more thoroughly. :^)
The control bar visibility is now more similar to how other browsers
handle it. It will show upon hovering over the element, but if the
cursor is kept still for more than a second, it will hide again. While
dragging, the controls remain visible, and will then hide after the
mouse button is released.
The icons have been redesigned from scratch, and the mute icon now
visualizes the volume level along with indicating the mute state.
The CSS content property's alt text (after `/`) was incorrectly
accepting any content value. Per the CSS Content Module Level 3 spec,
alt text only accepts <string>, <counter>, and <attr()> values. This
change adds type validation in the alt text parsing branch to reject
URLs, quote keywords, images, and other non-alt-text value types.
This fixes 64 subtests in the content-invalid WPT test.
Move grid area rectangle computation and validation from layout to the
CSS parser. Named grid areas that don't form filled-in rectangles now
correctly invalidate the declaration per spec.
Move all the simple bool query methods (is_table_inside,
is_table_cell, is_none, is_block_outside, etc.) from Display.cpp into
Display.h as inline definitions. These are trivial one-liners called
in very hot painting and layout paths.
Keep only to_string() and from_short() out-of-line.
CSS::Display::Type and CSS::Display::ListItem defaulted to int (4
bytes each). Give them explicit u8 underlying types, shrinking
CSS::Display from 12 bytes to 4 bytes.
The grammar groups this component together meaning that all
sub-components must occur together i.e.
`ordinal slashed-zero small-caps` is valid but
`ordinal small-caps slashed-zero` is not.
We also reuse the logic for parsing from the longhand
`font-variant-numeric` property for simplicity.
The grammar groups this component together meaning that all
sub-components must occur together i.e.
`common-ligatures no-contextual small-caps` is valid but
`common-ligatures small-caps no-contextual` is not.
We also reuse the logic for parsing from the longhand
`font-variant-ligatures` property for simplicity.
The grammar groups this component together meaning that all
sub-components must occur together i.e. `jis78 full-width small-caps` is
valid but `jis78 small-caps full-width` is not.
We also reuse the logic for parsing from the longhand
`font-variant-east-asian` property for simplicity.
Many CSS grammars call for us to parse `Foo || Bar` but we don't have a
good way to represent this unless we have a custom style value. Usually
we store the values in a `StyleValueList` but since that can only store
non-null elements we have to manually recheck which elements we have at
which index whenever we use it.
This style value holds a Vector of `RefPtr<StyleValue const>` so that we
can represent null values and know what values are at what index without
manually rechecking.
No callers of draw_painting_surface remain after the previous commits
migrated canvas, video, and SVG to use ExternalContentSource or
ImmutableBitmap snapshots.
The stacking context tree rebuild had an optimization that skipped
rebuilding when a property changed between two values that both create
stacking contexts. This is correct for most properties (e.g. opacity
0.5 -> 0.8 doesn't change tree structure), but incorrect for z-index.
During tree construction, elements with z-index 0/auto are placed in
m_positioned_descendants_and_stacking_contexts_with_stack_level_0,
while elements with other z-index values are painted from m_children
(negative at step 3, positive at step 9 per CSS 2.1 Appendix E).
When z-index changed between non-auto values (e.g. 0 -> 10), the
optimization skipped the rebuild, leaving the element in the wrong
list and causing it to be painted from both step 8 and step 9.
This was visible on pages like shopify.com where elements with
transition-all would transition z-index, producing a flood of
"Painting commands are recorded twice for stacking context" messages.
