3 ms·

Actually there is very important 4th point about implementation (browser) A few years ago a made a Monopoly-Deal-Clone game using mostly SVG + CSS + Svelte. I

Actually there is very important 4th point about implementation (browser) A few years ago a made a Monopoly-Deal-Clone game using mostly SVG + CSS + Svelte. I was intrigued by the promise of SVG: - Loss-Less Scaling - Looks the same (or somewhat) the same on all browsers - Text would also scale and be readable up and down. Build playing cards on the fly with SVG elements dynamically (base-card-svg + text + icon/image/glyph) All of these were never true-enough even for even a card-based game. The SVG text never looked good-enough or readable at all sizes used. Depending on scaling the text/icons and lines got blurred worse. The "fix" for many of these were endless and browser version-dependent magic-css properties and values. TL;DR I wouldn't use SVG for more than 50% of your game or professional product that uses images/visual-elements. Its not worth the pain and effort !

myfonj 2y ago
I went the rabbit hole of exploring SVG "decimal precision-related" glitches in browser implementations and to my grief I must confirm that there really are blatant cross-browser issues. It's fact that my tests went a bit over-the-top with dimensions -- who would make 1e9 or 1e-9 wide viewBox in real world anyway? -- but since refraining from doing so is not discouraged in the specs, one would expect it would scale (pun intended) at least few orders of magnitude. The results for my particular testcase showed that "safe" range was only between 2e3 and 2e5: [1]. https://myfonj.github.io/tst/SVG-decimal-precision-results.html https://myfonj.github.io/tst/SVG-decimal-precision-results.h...
- michaelt 2y ago
  > who would make 1e9 or 1e-9 wide viewBox in real world anyway? Back in about 2008 I made an SVG diagram showing the height of various satellite orbits above earth, specifying the SVG at 1:1 scale - making the image 84,000 km wide. Sadly a load of file viewers choked on it, so I had to settle for a downscaled version. It seems the 'scalable' in 'scalable vector graphics' only goes so far.
  - myfonj 2y ago
    Ha, nice! I secretly hoped someone would mention their real-world usage of "ridiculously" large SVG dimensions, so thanks for the reference! Your story implies there actually were some viewers that could handle it correctly? Could you recall more details what were they? (My testing was pitifully limited to current browsers only, but I know there must be vast amount of other viewers.) And if I may ask, did you map one SVG "point" to some length unit (e.g. meter, so getting 84e6 wide wiewBox), or did you assume 90 DPI "pixel" mapping to ~0.2822 mm?
    - codetrotter 2y ago
      From looking at the following pages - https://docs.aspose.com/svg/net/drawing-basics/coordinate-systems-and-units/#svg-viewport https://docs.aspose.com/svg/net/drawing-basics/coordinate-sy... - https://www.w3.org/TR/SVG2/coords.html https://www.w3.org/TR/SVG2/coords.html - https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Positions https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Po... You can use “cm” and “mm” in SVG. It will then be up to the viewer program (web browser or which ever program you are using) to make it correct for the DPI of your display.
    - michaelt 2y ago
      I've just re-tested, and you're right. This SVG won't display properly with chrome, firefox, inkscape or imagemagick <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg width="84000000000mm" height="84000000000mm" viewBox="0 0 84000000000mm 84000000000mm" version="1.1" id="svg5" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <ellipse style="fill:none;stroke:#000000;stroke-width:0.812697;stroke-opacity:1" id="path111" cx="42000000000mm" cy="42000000000mm" rx="42000000000mm" ry="42000000000mm" /> </svg> However the browsers don't crash or run out of memory, so they've got that going for them. And if you embed the image in a web page with <img src='84km.svg' width=1000 height=1000> chromium almost manages to display it. SVG lets you specify sizes in a bunch of different units, but there's actually a fixed ratio between them - in SVG, 1mm means is 3.78px regardless of your display or printer's DPI. So I didn't scale mm to SVG's arbitrary length units - but the standard did.
- masfuerte 2y ago
  Also, browsers seem to render svg circular arcs using bezier curves. At high zoom levels there can be quite a discrepancy between the actual curve (drawn using lots of straight line segments, say) and what the browser renders for a circle.
  - myfonj 2y ago
    Do they? I thought this is more issue on the source code side, rather than implementation: this is actually my pet-peeves, that most SVG *authoring tools* never output circular arcs and always use cubic béziers approximations instead. So we nearly ever see real circles or their segments, even though authors use them in their designs all the time. // Coincidentally played with this test yesterday: https://myfonj.github.io/sandbox.html#%3C!doctype%20html%3E%3Chtml%20lang%3D%22en%22%20style%3D%22color-scheme%3A%20dark%20light%3B%22%3E%0A%3Cmeta%20name%3D%22viewport%22%20content%3D%22width%3Ddevice-width%2C%20initial-scale%3D1%22%3E%0A%3Ctitle%3E%0ACubic%20b%C3%A9zier%20%22circular%20arcs%22%20versus%20real%20circular%20segments%0A%3C%2Ftitle%3E%0A%3Cstyle%3E%0Asvg%20%7B%0A%20position%3A%20fixed%0A%7D%0Asvg%3Alast-child%20%7B%0A%20color%3A%20canvas%0A%7D%0A%3C%2Fstyle%3E%0A%3Cbody%3E%0A%0A%3Cscript%3E%0A%2F%2F%20https%3A%2F%2Fpictogrammers.com%2Flibrary%2Fmdi%2Ficon%2Fcheck-circle%2F%0A%3C%2Fscript%3E%0A%0A%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2024%2024%22%3E%3Ctitle%3Echeck-circle%3C%2Ftitle%3E%3Cpath%20d%3D%22M12%202A10%2010%200%200012%2022%2010%2010%200%200012%202M10%2017%205%2012%206.41%2010.59%2010%2014.17%2017.59%206.58%2019%208Z%22%20fill%3D%22currentcolor%22%20%2F%3E%3C%2Fsvg%3E%0A%0A%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2024%2024%22%3E%3Ctitle%3Echeck-circle%3C%2Ftitle%3E%3Cpath%20d%3D%22M12%202C6.5%202%202%206.5%202%2012S6.5%2022%2012%2022%2022%2017.5%2022%2012%2017.5%202%2012%202M10%20%0A17L5%2012L6.41%2010.59L10%2014.17L17.59%206.58L19%208L10%2017Z%22%20fill%3D%22currentcolor%22%20%2F%3E%3C%2Fsvg%3E%0A https://myfonj.github.io/sandbox.html#%3C!doctype%20html%3E%...
    - masfuerte 2y ago
      It was a few years ago and I'm unable to reproduce it. Circles and circle approximations from straight lines seem to coincide exactly in Firefox and Edge now. I was generating diagrams using my own code so I'm positive they were circular arcs. Tangents weren't tangent and it took me a while to realise that the problem was the browser rendering something that wasn't quite a circle. I assumed it was a bezier approximation but I didn't verify that. Whatever it was it seems to be fixed.
- myfonj 2y ago
  (Missed edit:) I even asked about formalized precision SVG limits on SO: https://stackoverflow.com/q/78692079/540955 https://stackoverflow.com/q/78692079/540955
mort96 2y ago
Another thing I've noticed is that Chrome doesn't seem to render SVGs with anti aliasing (at least not always?). This makes SVGs unsuitable for lots of kiosk-style systems, where you often have Chrome showing a web page on a relatively large low resolution screen.

myfonj 2y ago

I went the rabbit hole of exploring SVG "decimal precision-related" glitches in browser implementations and to my grief I must confirm that there really are blatant cross-browser issues. It's fact that my tests went a bit over-the-top with dimensions -- who would make 1e9 or 1e-9 wide viewBox in real world anyway? -- but since refraining from doing so is not discouraged in the specs, one would expect it would scale (pun intended) at least few orders of magnitude. The results for my particular testcase showed that "safe" range was only between 2e3 and 2e5: [1]. https://myfonj.github.io/tst/SVG-decimal-precision-results.html https://myfonj.github.io/tst/SVG-decimal-precision-results.h...

michaelt 2y ago
> who would make 1e9 or 1e-9 wide viewBox in real world anyway? Back in about 2008 I made an SVG diagram showing the height of various satellite orbits above earth, specifying the SVG at 1:1 scale - making the image 84,000 km wide. Sadly a load of file viewers choked on it, so I had to settle for a downscaled version. It seems the 'scalable' in 'scalable vector graphics' only goes so far.
- myfonj 2y ago
  Ha, nice! I secretly hoped someone would mention their real-world usage of "ridiculously" large SVG dimensions, so thanks for the reference! Your story implies there actually were some viewers that could handle it correctly? Could you recall more details what were they? (My testing was pitifully limited to current browsers only, but I know there must be vast amount of other viewers.) And if I may ask, did you map one SVG "point" to some length unit (e.g. meter, so getting 84e6 wide wiewBox), or did you assume 90 DPI "pixel" mapping to ~0.2822 mm?
  - codetrotter 2y ago
    From looking at the following pages - https://docs.aspose.com/svg/net/drawing-basics/coordinate-systems-and-units/#svg-viewport https://docs.aspose.com/svg/net/drawing-basics/coordinate-sy... - https://www.w3.org/TR/SVG2/coords.html https://www.w3.org/TR/SVG2/coords.html - https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Positions https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Po... You can use “cm” and “mm” in SVG. It will then be up to the viewer program (web browser or which ever program you are using) to make it correct for the DPI of your display.
  - michaelt 2y ago
    I've just re-tested, and you're right. This SVG won't display properly with chrome, firefox, inkscape or imagemagick <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg width="84000000000mm" height="84000000000mm" viewBox="0 0 84000000000mm 84000000000mm" version="1.1" id="svg5" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <ellipse style="fill:none;stroke:#000000;stroke-width:0.812697;stroke-opacity:1" id="path111" cx="42000000000mm" cy="42000000000mm" rx="42000000000mm" ry="42000000000mm" /> </svg> However the browsers don't crash or run out of memory, so they've got that going for them. And if you embed the image in a web page with <img src='84km.svg' width=1000 height=1000> chromium almost manages to display it. SVG lets you specify sizes in a bunch of different units, but there's actually a fixed ratio between them - in SVG, 1mm means is 3.78px regardless of your display or printer's DPI. So I didn't scale mm to SVG's arbitrary length units - but the standard did.
masfuerte 2y ago
Also, browsers seem to render svg circular arcs using bezier curves. At high zoom levels there can be quite a discrepancy between the actual curve (drawn using lots of straight line segments, say) and what the browser renders for a circle.
- myfonj 2y ago
  Do they? I thought this is more issue on the source code side, rather than implementation: this is actually my pet-peeves, that most SVG *authoring tools* never output circular arcs and always use cubic béziers approximations instead. So we nearly ever see real circles or their segments, even though authors use them in their designs all the time. // Coincidentally played with this test yesterday: https://myfonj.github.io/sandbox.html#%3C!doctype%20html%3E%3Chtml%20lang%3D%22en%22%20style%3D%22color-scheme%3A%20dark%20light%3B%22%3E%0A%3Cmeta%20name%3D%22viewport%22%20content%3D%22width%3Ddevice-width%2C%20initial-scale%3D1%22%3E%0A%3Ctitle%3E%0ACubic%20b%C3%A9zier%20%22circular%20arcs%22%20versus%20real%20circular%20segments%0A%3C%2Ftitle%3E%0A%3Cstyle%3E%0Asvg%20%7B%0A%20position%3A%20fixed%0A%7D%0Asvg%3Alast-child%20%7B%0A%20color%3A%20canvas%0A%7D%0A%3C%2Fstyle%3E%0A%3Cbody%3E%0A%0A%3Cscript%3E%0A%2F%2F%20https%3A%2F%2Fpictogrammers.com%2Flibrary%2Fmdi%2Ficon%2Fcheck-circle%2F%0A%3C%2Fscript%3E%0A%0A%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2024%2024%22%3E%3Ctitle%3Echeck-circle%3C%2Ftitle%3E%3Cpath%20d%3D%22M12%202A10%2010%200%200012%2022%2010%2010%200%200012%202M10%2017%205%2012%206.41%2010.59%2010%2014.17%2017.59%206.58%2019%208Z%22%20fill%3D%22currentcolor%22%20%2F%3E%3C%2Fsvg%3E%0A%0A%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2024%2024%22%3E%3Ctitle%3Echeck-circle%3C%2Ftitle%3E%3Cpath%20d%3D%22M12%202C6.5%202%202%206.5%202%2012S6.5%2022%2012%2022%2022%2017.5%2022%2012%2017.5%202%2012%202M10%20%0A17L5%2012L6.41%2010.59L10%2014.17L17.59%206.58L19%208L10%2017Z%22%20fill%3D%22currentcolor%22%20%2F%3E%3C%2Fsvg%3E%0A https://myfonj.github.io/sandbox.html#%3C!doctype%20html%3E%...
  - masfuerte 2y ago
    It was a few years ago and I'm unable to reproduce it. Circles and circle approximations from straight lines seem to coincide exactly in Firefox and Edge now. I was generating diagrams using my own code so I'm positive they were circular arcs. Tangents weren't tangent and it took me a while to realise that the problem was the browser rendering something that wasn't quite a circle. I assumed it was a bezier approximation but I didn't verify that. Whatever it was it seems to be fixed.
myfonj 2y ago
(Missed edit:) I even asked about formalized precision SVG limits on SO: https://stackoverflow.com/q/78692079/540955 https://stackoverflow.com/q/78692079/540955

mort96 2y ago

Another thing I've noticed is that Chrome doesn't seem to render SVGs with anti aliasing (at least not always?). This makes SVGs unsuitable for lots of kiosk-style systems, where you often have Chrome showing a web page on a relatively large low resolution screen.