Security-wise, it's a rather bad idea to build a web browser on top of the Atom Electron framework at the moment , at least unless you are willing to fork or contribute patches to Electron each time when a new Chrome version with security fixes is released.
I had never heard of quaternions so I Googled the book title you suggested. In addition to the Amazon link , I also found a question on the gamedev SE where they talk about building a mental model of quaternions , which I found informative.
The main size is dealing with libxml, but that's readily handled by smaller xml libraries [http://pugixml.org]. I mean, maybe you don't want to do SVG on an arduino.
Directly comparing SVG and PNG libraries purely based on library size is misleading. PNG's aren't layered, don't contain semantic information, etc. For me librsvg is lightweight since its way better than installing phantomjs as I have been doing to generate embedable PNGs for documents.
Have you tried them though? Now check it out with kerning and/or italics. Do you see overhanging when you draw the rectangular box found via the API? Good example is strings that end with a character like f.
Works in theory. In practice, it does not. That is what I found but again, I'd be happy to be wrong.
When working on it a year ago at another employer, we had a list of edge cases. I don't recall them all but some were off by quite a bit. Enough so that the work around was to do everything in SVG except text and use plain DOM position on top for text. That was a bit better. It would be wonderful to do everything in SVG.
You forgot that it also requires XML and CSS. I'm surprised PDF is just marginally bigger, considering that it's carrying around lots of legacy stuff is so much more than just a vector graphics format.
Removing sections that are standardized somewhere else doesn't make a file format easier, especially if you want to implement it outside of a browser.
There's still tons of features in SVG that are probably not used or not really needed:
Mandating IEE 754 binary floating point coordinates, while representing them as decimals that are usually rounded to 0.001 or 0.0001. This causes rounding errors all the time. The 16.16 fixed point format used in ttf seems more sensible for this usecase.
Including (parts of) external SVGs with <use>. <use> doesn't seem to be supported in Safari, Firefox or Inkscape anyway.
<switch> to make an SVG render differently on computers with different locale.
ARIA (accessibility) support, what happened to a description of the image?
Commas as optional separators in paths, but only at certain locations and only at most one of them. There have been several bugs in programs using SVG concerning the parsing path strings that were related to white space.
Basic shapes that can just as easily can be constructed using <path>, especially the polygon and polyline.
The total absurdity that is <text>. Text usually isn't the main content of images, yet the chapter about text is the longest in the SVG specification, containing stuff like text flowing along a path. And all this without supporting multi-line text. Just use <path> instead, bitmap graphics also uses rasterized text. If fonts aren't installed it may cause overlapping, or it might not get rendered at all.
XML dependence will become optional in SVG 2 and hopefully it will be deprecated in SVG 3. Chrome team is already considering switching to HTML parser no matter whether the SVG document uses XML or HTML serialization.
<use> elements with external references are tricky due to the same origin policy restrictions and various browser bugs, but referencing local IDs works just fine. Inkscape for example creates clones and symbol instances with <use> elements.
The most obscure part of the paths specification, i.e. the pathSegList interface, is gone in SVG 2. There were some plans to deprecate the "d" attribute and instead introduce a nicer function-based syntax such as data="move(10, 10) line(20, 20)", but AFAIK this idea has been dropped. Still, the path data grammar is clearly defined in the spec, I'm not sure why browser vendors don't follow it.
SVG 2 will support multi-line text and embedded WOFF fonts. This feature is important when you are authoring e.g. UI mockups or posters. Even low level drawing APIs such as canvas have the text primitive. If you express textual content with <path> instead of <text> element then it will not be editable and selectable, screenreaders won't recognize it and search engines won't index it.
I'm not really into the geopolitics and recent news, but what's wrong with this plan? Hopefully the future European governments will be up to something along those lines rather than balkanization followed by the final solution.
1. Move all illegal migrants to a heavily guarded area akin to the Gaza Strip. All EU members would pay for building and maintaining the camps. Base the camps in a non-EU country so that drastic measures could be taken in case situation gets out of control.
2. Don't grant any new citizenships to legal migrants from high-risk countries, instead issue permanent residence permits and then deport anybody suspected of radicalization.
3. Perform full-scale military intervention in the Middle East to restore the old order. Ideally make deal with Russians and Syrian government to take care of the most dirty tasks.
It is challenging to make a large app with lots of state be performant when you manually mutate the DOM, and there's no way for the browser to fix that because of the way things work.
For example, if you move an element, and then request the position of another element immediately after, the browser will be forced to recalculate layout before giving you an answer. With lots of state and lots of updates, it's very challenging to keep this in the right order.
As virtual DOM is an abstraction over the DOM, you can make a vanilla app that is much faster, but as your app grows, that quickly reverses.