Age | Commit message (Collapse) | Author |
|
|
|
Update the tests after adding minmax(), auto-fill and auto-fit
functionality to the LibWeb implementation of the CSS Grid.
|
|
Created a simple page where you can check
that the exceptions appear in the JS console.
|
|
Add ability to use values passed to grid-template-columns and
grid-template-rows for CSS Grid layout within a repeat() function.
E.g. grid-template-columns: repeat(2, 50px); means to have two columns
of 50px width each.
|
|
When the indicated column-span is greater than the implicit grid (like
in cases when the grid has the default size of 1x1, and the column is
supposed to span any number greater than that), then previously were
crashing.
|
|
|
|
Add some tests to the test page to make sure that different combinations
of GridTrackPlacement don't cause out of bounds issues.
|
|
If a grid item has as its position value a 0 then it should be
invalidated.
|
|
Ensure that when a grid item is passed with a span and a fixed end
position, that if the resulting start of this item is less than 0 then
it won't throw. This is a temporary measure until the correct
functionality is implemented.
|
|
Implement span correctly when indicated in the grid-column-start,
grid-row-start, etc. CSS properties. Previously it had been implemented
as if span was something that went alongside the position property, but
actually it seems like if you do 'span 3' in the grid-column-start
property, for example, this means it literally spans 3 blocks, and the
3 has nothing to do with position.
|
|
|
|
|
|
|
|
Layout box offset coordinates are always relative to their containing
block. Therefore, the functions that convert between coordinate spaces
should only visit containing blocks and apply their offsets, not *every*
box in the parent chain.
This fixes an issue where some floating boxes were unexpectedly far away
from their containing block.
|
|
We have to check that there's enough space at both the top and bottom of
the float's margin box, otherwise we risk overlapping existing content.
|
|
This allows us to print messages in inline scripts. Also add an example
of this in the welcome page to test this.
|
|
|
|
This patch combines a number of techniques to make inline content flow
more correctly around floats:
- During inline layout, BFC now lets LineBuilder decide the Y coordinate
when inserting a new float. LineBuilder has more information about the
currently accumulated line, and can make better breaking decisions.
- When inserting a float on one side, and the top of the newly inserted
float is below the bottommost float on the opposite side, we now reset
the opposite side back to the start of that edge. This improves
breaking behavior between opposite-side floats.
- After inserting a float during inline layout, we now recalculate the
available space on the line, but don't adjust X offsets of already
existing fragments. This is handled by update_last_line() anyway,
so it was pointless busywork.
- When measuring whether a line can fit at a given Y coordinate, we now
consider both the top and bottom Y values of the line. This fixes an
issue where the bottom part of a line would bleed over other content
(since we had only checked that the top Y coordinate of that line
would fit.)
There are some pretty brain-dead algorithms in here that we need to make
smarter, but I didn't want to complicate this any further so I've left
FIXMEs about them instead.
|
|
|
|
This adds the existing `@font-face` test page to the welcome page.
|
|
Spelling fixes found by `codespell`.
|
|
|
|
- Use the border box of the floated element when testing if something
needs to flow around it.
- Take the floated element's containing block size into account (instead
of the BFC root) when calculating available space on a line where a
right-side float intrudes.
|
|
Also added a local test for ensuring this behavior since it is unique to
browsers. Since we don't actually use WindowProxy anywhere yet we just
test on location for now.
|
|
|
|
|
|
|
|
Neither of the tests here actually passes properly right now. It's a
little more aspirational...
In the first one, the circle draws in the wrong place due apparently to
existing bugs in `CanvasRenderingContext2D::ellipse()`.
In the second, I just haven't yet implemented creating a Path2D from an
SVG path string, because that's going to take a fair bit of untangling
first.
|
|
Clean up the Clip test page after adding the logic necessary so that
absolutely positioned divs are correctly positioned.
|
|
This adds a demo of making a 'rainbow' with hard edges using
transition hints, along with an animated demo of moving the
transition hint.
|
|
This restores the demo to being the same as on css-tricks.com.
|
|
The previous demo didn't work that well, not due to any LibWeb
issue (same in other browsers), it just was a broken demo.
This demo shows the neat tricks you can do with linear-gradient()s
much better.
|
|
|
|
|
|
See: https://css-tricks.com/html5-progress-element/ this is a neat
demo of a pure CSS progress bar that makes use of linear-gradients,
background-repeat, and background-size. All of which now work :^)
|
|
|
|
|
|
* A border-radius + a border on a <img> tag
- The border-radius on the <img> should shrink to line up with
the border.
* A border-radius + a border on a div with overflow: hidden
- The clipping border-radius should shrink (same as the image).
|
|
The button color here now just creates issues on dark themes,
and the margin on the progress bar does nothing.
|
|
This adds an example of a progress bar with just `appearance none`,
and one with `appearance none` and some custom styling.
|
|
This adds a test for overflow: hidden + border-radius clipping
child positioned elements, and child backgrounds.
|
|
Adds tests for:
- Multi-stop gradient at arbitrary angles (CPU brr)
- Default/calculated color stops
- to <corner>
- Pre-multiplied alpha mixing
|
|
|
|
|
|
|
|
This will allow this demo to be reused for other tests.
|
|
|
|
`calc(<percentage> + -<length>)` did work before, but a direct
`calc(<percentage> - <length>)` was broken. Let's have a test for both.
|
|
|
|
|