Show HN: A tool to build real websites built exclusively in SVG

Fun story-- awhile back some troglodytes living somewhere in the Linux font stack tripped some switch in their magical rendering engine. Whatever the change was, it caused even a mono-spaced font like DejaVu Sans Mono to have a significantly fatter width. So pre-trog Ubuntu perhaps would have X width for "Hello World This Should Fit Perfectly An SVG Rect" at size 10px, while post-trog Ubuntu would have X+7.

For my SVG-based UI, this meant I had to do a startup feature test for pre or post-trog Linux and scale the font accordingly on post-trog machines to make sure it fit properly into the box.

But honestly, I don't think you could do any kind of feature test like that with impunity. E.g., if the user created a page with no visible border lines drawn at the right edge of the text, they'd probably be surprised/irritated that the text is slightly scaled in a feeble attempt at cross-platform compatibility.

Anyway, all these problems go away when the fonts are converted to paths-- the user simply sees static output based on the rendering engine on the dev's machine.

Edit-- but of course if you convert to paths, you don't get text and text selection. Nevertheless, converting vector graphics output to SVG-with-text-content is not actually WYSIWYG, and that subtle truth will probably come back to bite your users.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...

very 1999 :)

• Page is rather heavy to load.

• Page load felt a bit sluggish on even a fast device; but on review I think the massive background JPEG at the top (4000×8047!) was a large part of this: you should have an approximation of it (background colour plus radial gradient) underneath it so that its potentially slow loading and rendering isn’t so obvious.

• Resizing the window has a habit of breaking things, seeming to attempt reflowing most of the time but normally making a mess of it. (Not factoring scrollbars in may be contributing to this.)

• I’m getting horizontal scroll bars, sometimes for substantial amounts and sometimes because you’ve measured the wrong thing that doesn’t take scrollbar width into account: to experience that on macOS so you can fix it, you can disable overlay scrollbars somewhere in the system settings.

• I found myself disappointed that the document is served as HTML rather than SVG, though it probably makes sense because of things like meta tags that I don’t imagine most tooling will understand how to consume within SVG.

• Where text flow is concerned, it may be worth switching back to HTML with . It would probably allow code size reductions and performance improvements in reflow, and would improve accessibility, hopefully to the point where you could stop maintaining a separate HTML alternative section, instead weaving it throughout the SVG.

But all up, I like the concept. It’s good to see experiments in doing things differently. I myself am preparing to start publishing content handwritten and -drawn via my reMarkable tablet, and will be toying with making it reflowable at some point, though I suspect I’ll only ever reflow very sparingly. (If anyone else is interested in the concepts, take a look at http://www.styluslabs.com/ and https://developer.myscript.com/docs/concepts/responsive-layo....)

Lol wut? Does the author advocate keep their money under their couch?