By the tiniest of margins, 115. Deleted two spaces and an `l`. Largely inspired by `svgo`. Using `rsvg-convert` to render them both to PNG shows identical output between this and the 118 version. https://rjp.is/hn-svg.html seems to render them identically in Safari and Chrome.

    <svg viewBox="-32-32 64 64" style="background:#f60"><path fill="#fff" d="m0-5-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

viewBox can be comma-separated, so you can loose the quotes but only for inline SVG

Well, that seems to work in everything (Firefox, Safari, Chrome, rsvg-convert) and drops it down to 114. Ta!

But not in Firefox :(

That appears to be trigged by "-32-32" (broken) vs "-32 -32" (working). Looks like this has been a long-standing weirdness in Firefox[1] where it is allowed somewhere but not other places.

On the other hand, the spec[2] does specify whitespace or commas between the viewbox numbers.

I rescind my 115 claim and reset it back to 116.

[1] https://github.com/svg/svgo/issues/12

[2] "a list of four numbers <min-x>, <min-y>, <width> and <height>, separated by whitespace and/or a comma"

We can move the fill to the style attribute and get it back down to 114:

  <svg viewBox="-32 -32 64 64" style="background:#f60;fill:#fff"><path d="m0-5-8-12h-7L-3 1v16h6V1l12-18H8z"/></svg>

Oh, if you then switch to the comma-style for viewBox, drop the / from the path tag, and drop the quotes from the style attributes, that takes it down to 109.

Safari, Chrome, and Firefox are all perfectly happy with it but then rsvg-convert chokes on all of those changes. 114 is probably the best that can be done and still be "conforming" (for want of a better word.)

It doesn't need to be valid XML if you embed it in the HTML, which was their point.