I have tested some very basic SVG sample (stroked circle filling square viewport with dash-array producing quarter slices) in varying viewBox dimensions, and observed some spectacular rendering and behavioural discrepancies across implementations, which — while somewhat expected along the lines of thought that ‘there will inevitably be some floating point precision loss involved somewhere’ — happened surprisingly early, either in rendering or in calculated “interactive hit-box” of the rendered shape.

I have skimmed though SVG specs several times, whether there are at leas some guidelines how much “scalable” the SVG world has to be without losing precision to be baseline compliant, but didn’t find any authoritative stance about that.

I understand that the spec might be deliberately “murky” about this, putting my questions in “it depends” territory, but anyway. My questions are namely:

• Is (was) there ever such guideline (be it formalized or even merely discussed), ordering implementers for what dimensions they have to produce interoperable outcome and from what values on they are allowed to diverge?
• If there was, where can we read that?
• If not, would it make sense to open this topic in the working group?
• Does it make sense to fill bugs for implementers with ridiculously large/small values in STRs (today)?

Exploration and results

SVG template, where each ${exp} is to be interpolated with exponent, from e+9 to e-7, so effectively making viewBox from 2_000_000_000 to 0.0000002 points wide and tall.

<svg xmlns="http://www.w3.org/2000/svg"
 viewBox="-1${exp},-1${exp} 2${exp} 2${exp}"
>
 <circle r=".5${exp}"
  stroke-width="1${exp}"
  pathlength="4"
  stroke-dasharray="1,1"
  stroke="currentcolor"
  fill="none"></circle>
</svg>

Basically anything above 20_000 and below 200 produced some error in one implementation or other.

Full results / Testing playgound

Excerpts:

Showing rendering (black) and computed hit-box (half-transparent green) from three SVG engines, where at least one “fails”::

From 200_000_000 2_000_000, ideally, every single capture should look like the leftmost e+6 from here:

From 200 to 0.2: