4 ms·

I brought SVG to WebKit, back in 2005. So I guess I'm part of the problem. I generally agree with the article, SVG is bloated and confused about what it's try

I brought SVG to WebKit, back in 2005. So I guess I'm part of the problem. I generally agree with the article, SVG is bloated and confused about what it's trying to do. You're not alone in wanting something better. We had this same problem in Flutter. Ian Hickson (of HTML5 fame) made some attempts at seeing a better future you might be interested in: https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit#heading=h.8crpi5305nr https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...

airstrike 2y ago
IconVG was looking promising but it seems abandoned at this point... The README doesn't mention anything and the repo isn't archived, but the last real commit is from 3+ years ago https://github.com/google/iconvg https://github.com/google/iconvg
- hgs3 2y ago
  There is also TinyVG [1]. See the previous discussion on HN [2]. [1] https://tinyvg.tech/ https://tinyvg.tech/ [2] https://news.ycombinator.com/item?id=35227635 https://news.ycombinator.com/item?id=35227635
  - Lammy 2y ago
    And HVIF: http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html http://blog.leahhanson.us/post/recursecenter2016/haiku_icons... https://news.ycombinator.com/item?id=40196333 https://news.ycombinator.com/item?id=40196333
rikroots 2y ago
That document has a really good summary of all the problems surrounding text rendering onto a canvas[1]. Having been through the pain of implementing such a system for my canvas library earlier this year I can sympathise with the decision not to include it in the proposed format's MVP. What did disappoint me when reading the doc was the decision to place accessibility at the bottom of the list of priorities for the proposed format. There's a footnote that says "Accessibility being low on this list reflects that the needs can be met outside the format as well, and supporting them inside the format would be beneficial only to the extent that it provides greater flexibility to designers", but to me that seemed back-to-front: why not tell the engine/device that will display the image the (preferred) requirements for accessibly rendering (or describing) that image by including such data in the format, rather than hoping that the engine/device will make "best efforts" to support people with accessible needs in some unknowable way? [1] Text section in doc - https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit#heading=h.2fvcp5gqzghd https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...

airstrike 2y ago

IconVG was looking promising but it seems abandoned at this point... The README doesn't mention anything and the repo isn't archived, but the last real commit is from 3+ years ago https://github.com/google/iconvg https://github.com/google/iconvg

hgs3 2y ago
There is also TinyVG [1]. See the previous discussion on HN [2]. [1] https://tinyvg.tech/ https://tinyvg.tech/ [2] https://news.ycombinator.com/item?id=35227635 https://news.ycombinator.com/item?id=35227635
- Lammy 2y ago
  And HVIF: http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html http://blog.leahhanson.us/post/recursecenter2016/haiku_icons... https://news.ycombinator.com/item?id=40196333 https://news.ycombinator.com/item?id=40196333

rikroots 2y ago

That document has a really good summary of all the problems surrounding text rendering onto a canvas[1]. Having been through the pain of implementing such a system for my canvas library earlier this year I can sympathise with the decision not to include it in the proposed format's MVP. What did disappoint me when reading the doc was the decision to place accessibility at the bottom of the list of priorities for the proposed format. There's a footnote that says "Accessibility being low on this list reflects that the needs can be met outside the format as well, and supporting them inside the format would be beneficial only to the extent that it provides greater flexibility to designers", but to me that seemed back-to-front: why not tell the engine/device that will display the image the (preferred) requirements for accessibly rendering (or describing) that image by including such data in the format, rather than hoping that the engine/device will make "best efforts" to support people with accessible needs in some unknowable way? [1] Text section in doc - https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit#heading=h.2fvcp5gqzghd https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...