Previously we were starting the variable expansions before the starting
'$' and calculating the wrong length, this commit makes it so we
calculate the right range for them.
We previously did not notify the listener about entering the root node,
which caused the following snippet to produce the wrong output:
a = new DOMParser
a.parseFromString("<x/>", "text/xml").documentElement // != null
This makes Piano exactly as usable as when I started the large refactor
some years ago, which *sounds* like I'm a terrible person but now it (1)
looks nicer and (2) has a flexible backend that can already deal with
aribtrary kinds of processors on any track.
These were part of the postcreate script previously, but with the new
powers of sed, we can text-replace the library name and make changing
them much more convenient.
Namely, the window title and size are carried over, since a larger
window with a more readable "Example Application" title is better to
understand. I also took the opportunity to add a missing trailing
newline to the generated CMake file.
Our current `peek_bits` function allows retrieving more bits than we can
actually provide, so whenever someone discards the requested bit count
afterwards we were underflowing the value instead.
The actual cause for the "missing bits" is currently unknown, and this
test case doesn't actually start obviously breaking yet unless we start
reporting errors about missing bits. However, since we are touching the
BitStream implementation already, let's add the test early to make extra
sure that we aren't breaking anything.
This follows on from the SVG linear gradients. It supports the same
features (xlink:href, gradientUnits, gradientTransform).
With this commit I have now implemented all web gradients :^)
(Though we are still missing a few parameters for SVG gradients,
e.g. spreadMethod).
This also slightly refactors things to share more implementation with
the SVG linear gradients, and improve accuracy (which fixes some banding
issues).
Since this FIXME was added the SVGFormattingContext has got a fair bit
more spec compliant. The other more specific FIXMEs in this file should
be more useful.
This is typically used as `class A extends EventTarget`. It's usage can
be found on websites such as https://loadout.tf/
This has the quirk that we don't do set the EventTarget prototype for
HTML::Window, as it would cause a null deref on startup. However, given
it wasn't doing this before, I don't think it should cause any issues.
The actual port is SeriousSamClassic, but only The First Encounter is
built and installed. It should be relatively easy to also build and
install The Second Encounter from this port in the future.
LutAToBTagData::from_bytes() and LutBToATagData::from_bytes() already
reject curves for which this isn't true with an error.
Ensure potential future callers of the constructors get it right too.
https://www.w3.org/TR/CSS22/visuren.html#floats says that when a box
establishes BFC it should not overlap with floats. The way to avoid
overlaps is up to implementor. This change implements avoiding overlap
by narrowing width of a box because it seems like what other engines
do (in the scenarios I tested).
Calculating width of a box in BFC requires having resolved y to be able
to check if a box overlaps with any floating boxes.
This change makes compute_width() to be called after finding y
position. That also required to move resolving of vertical metrics
in the beginning of a box layout process to have vertical margins
resolved before finding y position.
Resolves#18618.
8134dcc changed `JsonArray::set()` to insert elements at an index
instead of changing existing elements in-place. Since no behavior
such as `Vector::try_at()` exists yet, it returns nothing.
When there are floats present inside an IFC, we must coordinate with
the parent BFC to calculate the automatic width of the IFC's block box.
This is because the IFC is not directly aware of floats. Only the BFC
knows enough about them to account for them in automatic sizing.
