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.
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.
- 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.
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).
This improves our spec compliance by allowing the user to click
non-element nodes (like text) and having the click be registered with
the parent element (like a div or button). This makes Fandom's cookie
accept button work if you click the text. Additionally, the events test
page contains a test to check the target element, which would previously
not exist when we fired the event at a non-element.
Previously, `var()` inside functions like `rgb()` wasn't resolved.
This will set the background color for badges in the New category on
https://ports.serenityos.net. :^)
The spec grammar for `text-decoration-line` is:
`none | [ underline || overline || line-through || blink ]`
Which means that it's either `none`, or any combination of the other
values. This patch makes that parse for `text-decoration-line` and
`text-decoration`, stores the results as a Vector, and adjusts
`paint_text_decoration()` to run as a loop over all the values that are
provided.
As noted, storing a Vector of values is a bit wasteful, as they could be
stored as flags in a single `u8`. But I was getting too confused trying
to do that in a nice way.
