| Age | Commit message (Collapse) | Author |
|---|
|
It's not enough to only relayout here, since the API can substantially
change the DOM. We have to rebuild the layout tree.
|
|
We were incorrectly placing them relative to the BFC root, but CSS2
says they are relative to their own containing block.
|
|
This now also takes a FloatPoint instead of an IntPoint to avoid
excessive rounding when multiple transforms apply on top of each other.
|
|
Since there is currently no easy way to handle rotations and skews
with LibGfx this only implements translation and scaling by first
constructing a general 4x4 transformation matrix like outlined in
the css-transforms-1 specification. This is then downgraded to a
Gfx::AffineTransform in order to transform the destination rectangle
used with draw_scaled_bitmap()
While rotation would be nice this already looks pretty good :^)
|
|
|
|
|
|
|
|
|
|
- background properties
- box-shadow
- cursor
- SVG fill/stroke properties
- image-rendering
- outline properties
- pointer-events
- user-select
This should be basically all of them. I skipped `opacity` and
`transform` since establishing a stacking context feels like a
layout-affecting thing, but I could be very wrong on that!
|
|
The previous implementation used relative X offsets for both left and
right-side floats. This made right-side floats super awkward, since we
could only determine their X position once the width of the BFC root was
known, and for BFC roots with automatic width, this was not even working
at all most of the time.
This patch changes the way we deal with floats so that BFC keeps track
of the offset-from-edge for each float. The offset is the distance from
the BFC root edge (left or right, depending on float direction) to the
"innermost" margin edge of the floating box.
Floating box are now laid out in two passes: while going through the
normal flow layout, we put floats in their *static* position (i.e the
position they would have occupied if they weren't floating) and then
update the Y position value to the final one.
The second pass occurs later on, when the BFC root has had its width
assigned by the parent context. Once we know the root width, we can
set the X position value of floating boxes. (Because the X position of
right-side floats is relative to the right edge of the BFC root.)
|
|
This will allow us to override the available space correctly when doing
intrinsic sizing.
|
|
Using the intrinsic size cache means we only perform the nested layout
to determine intrinsic size *once* per root layout pass.
Furthermore, by using a throwaway FormattingState, details of the nested
layout can't leak into and mutate the outer layout.
|
|
Instead of caching them with the current state, we can cache them at the
root of the state tree. Since intrinsic sizes are immutable during the
same layout, this allows layout to take advantage of intrinsic sizes
discovered during nested layout (and avoids a *lot* of duplicate work.)
|
|
FormattingStates can have parents, in case we're performing nested
layouts to determine something's intrinsic size. In those cases, it will
soon be useful to find the outermost (root) state.
|
|
Use first_ancestor_of_type<BlockContainer>() instead of implementing a
custom traversal lambda.
|
|
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.
|
|
A simple wordle clone.
|
|
|
|
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.
|
|
This is identical to :is() except for specificity, so we can use the
same code paths. :^)
|
|
This lets us finally get rid of a FIXME in the default style sheet. :^)
|
|
`<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.
|
|
I think this now looks very nice :^)
|
|
Follows the efficient algorithm from this paper:
https://cs.uwaterloo.ca/research/tr/1984/CS-84-38.pdf
Can be extended ellipses in future.
|
|
Noticed the TODO in `Attribute.h` and realized we have as solution
to this problem already. :^)
|
|
I found these by running SoundPlayer under UserspaceEmulator.
After boot we attempt to read from these values before they
are initialized.
|
|
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.
|
|
If the previous active glyph is outside the currently selected
block range, reset GlyphMap to show all glyphs. This is less
disorienting when undoing changes outside the visible range.
|
|
Previously the glyph undo stack saved an array of bytes representing
the restore state of an individual glyph when modified. Now the
selection undo stack saves a byte buffer of the entire selection,
letting us restore changes to multiple glyphs at once.
|
|
Makes copy history a bit more informative by showing the code point
range of the selection copied, or the individual character if the
selection contains only one glyph.
|
|
Iterating over each glyph to set bits was rather slow in large
selections. This lets us edit the entire character set almost
instantly.
|
|
|
|
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.
|
|
|
|
There is no second step to complete after activating this action.
|
|
|
|
|
|
This expands the previously added settings for the asymmetric radii of
th FastBoxBlurFilter to allow the user to specify an angle and the
desired magnitude of blur.
The given values are then calculated forward to corresponding x and y
blur radii.
|
|
This allows the user to blur the image not uniformly, but to specify
different radii for the x and y component.
|
|
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.
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
|
|
This matches behavior of text selecting
|
