The spec says the result of this algorithm is undefined in such cases,
and it appears that other engines yield a zero size.
More importantly, this prevents us from leaking a non-finite value into
the layout tree.
This was crashing on google.com with the linux chrome user agent,
interestingly it seems like this behavior may have been accidental as
only two of the three `parse_number()` were changed in f7dbcb6
SVG presentation attributes are parsed as CSS values, so we also need to
handle CSS variable expansion when handling them.
This (roughly) matches the behavior of other engines. It's also used on
the web, for example on https://stripe.com/ :^)
There are a couple of things that went into this:
- We now calculate the intrinsic width/height and aspect ratio of <svg>
elements based on the spec algorithm instead of our previous ad-hoc
guesswork solution.
- Replaced elements with automatic size and intrinsic aspect ratio but
no intrinsic dimensions are now sized with the stretch-fit width
formula.
- We take care to assign both used width and used height to <svg>
elements before running their SVG formatting contexts. This ensures
that the inside SVG content is laid out with knowledge of its
viewport geometry.
- We avoid infinite recursion in tentative_height_for_replaced_element()
by using the already-calculated used width instead of calling the
function that calculates the used width (since that may call us right
back again).
This is far from perfect, but let's at least make an attempt at laying
out <svg> when encountering it inside another <svg>.
This makes https://awesomekling.substack.com actually load and render
instead of asserting. :^)
Per SVG2, any coordinate pairs following a moveto command should be
treated as implicit lineto commands with the same absoluteness as the
moveto command.
