No need to call the expensive establishes_stacking_context() here, as
we've already built the stacking context tree and can simply test for
the presence of existing stacking contexts.
This is preparation for allowing blocks with their own internal BFC to
flow around floating boxes in the parent BFC.
Note that IFC still has the available_space_for_line() API, which
returns space available within the IFC's own containing block, while the
BFC available_space_for_line() returns space available within its root.
In Selectors level 4, `:nth-child()` and `:nth-last-child()` can both
optionally take a selector-list argument. This selector-list acts as a
filter, so that only elements matching the list are counted. For
example, this means that the following are equivalent:
```css
:nth-child(2n+1 of p) {}
p:nth-of-type(2n+1) {}
```
This fixes the specificity for :not(), :is() and :where(). Also, we now
clamp the specificity numbers instead of letting them overflow, and I
sprinkled in some spec comments for good measure.
`<forgiving-selector-list>` and `<forgiving-relative-selector-list>` are
the same as regular selector-lists, except that an invalid selector
does not make the whole list invalid. The former is used by the `:is()`
pseudo-class.
For example:
```css
/* This entire selector-list is invalid */
.foo, .bar, !?invalid { }
/* This is valid, but the "!?invalid" selector is removed */
:is(.foo, .bar, !?invalid) { }
```
Also as part of this, I've removed the `parse_a_selector(TokenStream)`
and `parse_a_relative_selector(TokenStream)` methods as they don't add
anything useful.
C++20 provides the `requires` clause which simplifies the ability to
limit overload resolution. Prefer it over `EnableIf`
With all uses of `EnableIf` being removed, also remove the
implementation so future devs are not tempted.
This implementation of the secp256r1 elliptic curve uses two techniques
to improve the performance of the operations.
1. All coordinates are stored in Jacobian form, (X/Z^2, Y/Z^3, Z), which
removes the need for division operations during point addition or
doubling. The points are converted at the start of the computation,
and converted back at the end.
2. All values are transformed to Montgomery form, to allow for faster
modular multiplication using the Montgomery modular multiplication
method. This means that all coordinates have to be converted into
this form, and back out of this form before returning them.
Store a reference to the newly created execution context in an aptly
named variable, rename global_this_value to just this_value, and only
call set_global_object() in a single place.
It makes no sense to require passing a global object and doing a stack
space check in some cases where running out of stack is highly unlikely,
we can't recover from errors, and currently ignore the result anyway.
This is most commonly in constructors and when setting things up, rather
than regular function calls.
Use different specified radii for the two seperate passes.
The gaussian approximation is not changed to accept two parameters since
the math is not exactly straight forward and therefore something for a
later patch. For now, let's progress!
It isn't sensible to have a negative radius for blurring, so an unsigned
value is the right thing to do here.
Now we have to cast the radius to int a few times when actually doing
the calculations but I'm sure that can be done more intelligently, but
that optimization is a thing for the future.
It looked very goofy for the two different ways of invoking the Filter
to have differently signed arguments.
This patch makes background a bit darkened so that it is possible to
distinguish out of range area from glyphs that are just not drawn.
The default background color is also changed to Window so that it looks
good in more themes.
Right now the only functionality supported is getting/setting via JS
and resetting when browsing cross origin.
The HTML Specification (7.11 Browsing the web) also specifies how the
name should be restored from history entries, but we don't have those
yet.
This is a normative change in the Temporal spec.
See:
- 97d553c
- d53af7f
Note that we already implemented this correctly, so the only change is
updating the spec comment.
As noted, this is not 100% to the spec, but effectively the same -
`no-preference` is only allowed to appear in features that evaluate it
as false in a boolean context. This is also the only identifier besides
`none` that evaluates to false. If other identifiers gain this property
in the future, we can make it more robust then.
This adds (or at least stubs-out) the following:
- display-mode
- dynamic-range
- environment-blending
- forced-colors
- horizontal-viewport-segments
- vertical-viewport-segments
- inverted-colors
- nav-controls
- prefers-contrast
- prefers-reduced-data
- prefers-reduced-motion
- prefers-reduced-transparency
- scripting
- video-color-gamut
- video-dynamic-range
The `@media (inverted-colors)` CSS that the spec requires we add to the
UA style sheet does not actually do anything for us yet since we don't
support `filter`, but it seemed sensible to include it now to avoid
forgetting later. :^)
This was causing us to miss layout invalidations. With this fixed, we
can remove the invalidation from Element::recompute_style() along with
the associated FIXME.
Thanks to Idan for spotting this! :^)
By the time we're painting, we've already built the stacking context
tree. So instead of asking if a box establishes a stacking context, we
can ask if its paintable *has* a stacking context.
This was taking up ~6% of the profile when mousing around on the HTML
specification. With this change, it disappears completely. :^)
Instead of invalidating style for the entire document, we now locate the
nearest common ancestor between the old and new innermost hovered node,
and only invalidate that ancestor and its descendants.
This drastically reduces the amount of style update work when mousing
around on GitHub (and any other pages, really.) It's actually really
really snappy now. Very cool! :^)
Use the new CSS::property_affects_layout() helper to figure out if we
actually need to perform a full relayout after recomputing style.
There are three tiers of required invalidation after an element receives
new style: none, repaint only, or full relayout.
This avoids the need to rebuild the layout tree (and perform layout on
it) when trivial properties like "color" etc are changed.
This patch adds CSS::property_affects_layout(PropertyID) which tells us
whether a CSS property would affect layout if it were changed.
This will be used to avoid unnecessary relayout work when something
changes that really only requires us to repaint the page.
To mark a property as not affecting layout, set "affects-layout" to
false in the corresponding Properties.json entry. Note that all
properties affect layout by default.
