This does a few things, that are hard to separate. For a while now, it's
been confuzing what `StyleValue::is_foo()` actually means. It sometimes
was used to check the type, and sometimes to see if it could return a
certain value type. The new naming scheme is:
- `is_length()` - is it a LengthStyleValue?
- `as_length()` - casts it to LengthStyleValue
- `has_length()` - can it return a Length?
- `to_length()` - gets the internal value out (eg, Length)
This also means, no more `static_cast<LengthStyleValue const&>(*this)`
stuff when dealing with StyleValues. :^)
Hopefully this will be a bit clearer going forward. There are lots of
places using the original methods, so I'll be going through them to
hopefully catch any issues.
Previously any children would be layout using a BlockFormattingContext.
Now we at least differentiate between IFC and BFC if the sizes in
question are not constrained by other things.
Negative margins are a headache anyways, and allowing them to be
negative lead to weird behavior.
This patch avoids vasty wrong height-calculations by limiting the
allowed margins to positive numbers when evaluating the height of a
block.
This fixes the issue where an `<img>` set to its native size would
sometimes still appear blurry, because it had a fractional position,
causing `enclosing_int_rect()` to expand by 1px.
The logic here is needed by InlineNode too. Moving it into a
`paint_all_borders()` function makes it available to them both, as well
as anyone else who wants it. :^)
Doing so was causing the background to be painted twice, which looks
ugly if the background is semi-transparent. The painting is a bit of a
hack, as some situations apparently relied on it. This commit is ripping
the band-aid off to find where those are and fix them. :^)
We were computing the padded rect of the box during every paint phase,
despite only needing it in the Overlay phase.
Since this is an expensive call, let's take care not to make it
unnecessarily.
This is a hack, but it seems to do quite okay.
What we should do is to find the largest size the Box could want in its
main axis. To do that we have to layout the Box according to the needed
LayoutMode. For flex-rows we do as requested and try to make the Box as
wide as we want.
However, for flex-columns we simply assume the Box is a Block and we
calculate their height according to this.
Instead of trying to layout SVG boxes as if they are regular CSS boxes,
let's invent an "SVG formatting context" and let it manage SVG boxes.
To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox,
and is instead a simple, "inline-block" style BlockBox.
If our parent in the FlexFormattingContext also was a flex-container, we
didn't give our children any meaningful width to play with into
layout_inside(), which resulted in way too narrow layouting.
Now the width of the parent gets borrowed if the own width isn't
specified.
The previous VERIFY_NOT_REACHED() could be reached when there were equal
coodinates. This could be the case for a small radius which lead to
rounding making the two coordinates equal.
This now uses the values in `InitialValues`, which is not ideal, but
it's better to have our defaults defined in two places, than in 3.
The default for `border-colors` is `currentcolor`, so we shortcut that
here and just grab the value of the `color` property. As noted, this is
not perfect, but it's somewhat better.
In the spec, `fill` and `stroke` are supposed to be a shorthands for
various properties. But since the spec is still a working draft, and
neither Firefox or Chrome support the `fill-color` or `stroke-color`
properties, we'll stick with `fill` and `stroke` as simple colors for
now.
Also, note that SVG expects things in "user units", and we are assuming
that 1px = 1 user unit for now.
In the past, the base class implementation of this was used to descend
into subtrees and paint children. That is now taken care of by
StackingContext::paint_descendants() instead, and nothing used this.
Computing the absolute rect of a box requires walking the chain of
containing blocks and apply any offsets encountered. This can be slow in
deeply nested box trees, so let's at least avoid doing it multiple times
when once is enough.
