[foob]

This is pretty awesome. I'm a big fan of both SVG animations and terminal recorders, so this is right up my alley. I previously built a small library called svganimator for creating smooth animations between static SVG images [1], used generated SVG animations to help design the Wayback Machine loading animation [2], and also put together a fairly comprehensive comparison of terminal recording solutions [3]. I'll need to update the comparisons to include termtosvg, I can't wait to try it out and see what the file sizes look like.

As others have mentioned, the major issue with SVG animations is that Microsoft doesn't plan to ever include support for them in Edge. This means that you either need to create fallbacks specifically for Microsoft browsers, or to disregard that portion of the market on your website. It's a real shame because SVG/SMIL allows you to create high quality animations which require a fraction of the bandwidth that would be necessary for comparable GIF or video files.

[1] - https://github.com/sangaline/svganimator

[2] - https://intoli.com/blog/designing-the-wayback-machine-loadin...

[3] - https://intoli.com/blog/terminal-recorders/

[OskarS]

Honestly, if you're recording terminal sessions, it's probably fine to not support Edge. I doubt any significant portion of your audience is going to be using it, and even if they do, they're going to be perfectly understanding when you say "sorry, Edge doesn't support SVG animations, use a different browser".

Shitty of Microsoft, though. If they aren't going to support it, it's not going to be widely deployed. I expect better of the new and improved Microsoft.

[amelius]

W3C should have a rule that a web browser which does not intend to support the standard may not call itself a "web browser".

[wilg]

Those web browsers would probably also not support your new standard, and continue to call themselves web browsers.

[thecrazyone]

good catch :)

[chrisseaton]

> W3C should have a rule that a web browser which does not intend to support the standard may not call itself a "web browser"

They've got no authority to do that. There is no trademark on 'web' that they could enforce.

[bufferoverflow]

I'm pretty sure no browser supports 100% of SVG spec.

[fullstackchris]

Facts like these always drives me crazy... these companies (namely Microsoft, but I guess Google/Mozilla as well a bit) have huge teams and resources, and can't build a browser that follows specs that have been hammered out only after years of work.

[kbenson]

There's a reason why some bodies ship a reference implementation with the standard. Sometimes what's specified is infeasible, or even impossible (if the spec contradicts itself) to implement.

[amelius]

But what if the other vendors do have an implementation?

[drb91]

That doesn’t mean they can’t be expected to support a meaningful subset. Honestly I don’t even know what they’re thinking here: they have no real alternative.

[leni536]

The least to say. SVG support is abysmal in many browsers. PDF support in browsers seems to be much more complete, even though it's much more complex.

[nbe]

OP here. Sadly, SVG file size is not as small as I'd want it to be. The main problem is that a few attributes (x, y and lengthAdjust) have to be repeated on each text tag to position each character at the right place. I can't use CSS for this since those attributes are not styling attributes.

Using SVG definitions efficiently to avoid duplication is also not as easy as I thought it would be.

I have a few ideas on how to reduce file size, this is the next improvement I'm planning to work on.

For the examples shown at [1], file size ranges from 56kB to 252kB, the worst case scenario being lots of single characters with different colors.

[1] https://github.com/nbedos/termtosvg/blob/master/examples/exa...

[bonyt]

How about with gzip? I feel like SVG files should compress well. I’d imagine most HTTP servers already just use gzip for these files.

[wes-k]

Was curious myself. 252K -> 17K. Yes it compresses well :)

[fla]

What about embedding a mini ECMAScript player and apply values to the DOM on the fly ?

[nbe]

I'd rather stick to plain SVG for the animation part, in case ECMAScript is stripped from the SVG for security reasons. ECMAScript might be worth adding for additional features though (play/pause, progress bar, frame seeking...)

[ramses0]

Why not `zip blah.zip blah.html` and do it all as a single html doc?

http://pieroxy.net/blog/pages/lz-string/index.html

https://github.com/pieroxy/lz-string/blob/master/libs/lz-str...

~5kb gets you an lz-decoder, and you should be able to pull a bunch of trickery with blobs and compressed strings to get somewhere?

[kirjavascript]

it's actually possible to reduce duplication in this case with the <g> element, see this example;

https://jsfiddle.net/2kc6tqy1/2/

[d_]

> the major issue with SVG animations is that Microsoft doesn't plan to ever include support for them in Edge.

And here I thought the Edge team left behind the mistakes of IE.

[WorldMaker]

Edge doesn't have an infinite budget, and they say they've tried to prioritize based on how common the standards are found used in the wild and how active the requests on UserVoice are. Doesn't look like there is even currently a tracked UserVoice for it:

https://developer.microsoft.com/en-us/microsoft-edge/platfor...

[foob]

It is on UserVoice [1], and it has over two thousand votes there. They've marked that as "sorry, no plans," and they've marked previous issues as "by design" [2]. They use Chrome announcing plans to deprecate SVG animations as their primary justification, but Chrome backtracked on those plans after realizing that there were important use cases that mattered to the community [3].

> In the 15 months since we announced our intention to deprecate and eventually remove SMIL, we’ve heard a variety of opinions from members of the community. We value all of your feedback, and it's clear that there are use cases serviced by SMIL that just don’t have high-fidelity replacements yet. As a result, we’ve decided to suspend our intent to deprecate and take smaller steps toward other options.

I understand that they don't have an infinite budget, but it really seems like they made their mind up here years ago and haven't been interested in listening in the community since then. It's also a bit circular to "prioritize based on how common the standards are found used in the wild" when they're single-handedly responsible for preventing developers from using SVG animations "in the wild" in the first place.

[1] - https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...

[2] - https://developer.microsoft.com/en-us/microsoft-edge/platfor...

[3] - https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

[WorldMaker]

It is fascinating the interplay between the Chrome team, and WHATWG on SMIL. It's one of those W3C standards from the W3C's "XML all the things" years that you can tell browser teams aren't entirely thrilled with. Quick searches seem to indicate that WHATWG's overall take seems to be that all SVG animation support would be better in CSS Animation and that they'd also prefer to punt SMIL.

> It's also a bit circular to "prioritize based on how common the standards are found used in the wild" when they're single-handedly responsible for preventing developers from using SVG animations "in the wild" in the first place.

It certainly is a chicken-and-egg bootstrapping problem. Though the increasing prevalence of "Works Best in Chrome"/"Works Only in Chrome" dominance may suggest that Edge is still in a position to follow the trends than attempt to lead them on ancient W3C standards like SMIL.

[laurent123456]

It's in there under "SVG+SMIL Animation" but the status is "Not currently planned". Here[0] they say that they consider the feature deprecated.

[0] https://developer.microsoft.com/en-us/microsoft-edge/platfor...

[tambourine_man]

That it a bummer. Any thoughts on the feasibility of outputting js canvas instead? And the performance file size tradeoffs

[e12e]

My first thought was "this seems neat", and my second thought was: how hard would it be to write a small js script to play back "script"[s] output? Or, to take script output, convert it to some pre-tags and add js animation on top of that...

I suppose the main barrier would be lack of recorded timing information in script logs, so either pre-procesding or pause for input (say 50ms/keystroke + 200ms pr return/line-feed) and/or output (say 50ms pr line feed).

Although, now I see there's a -t option for a timing file.

So would seem one should be able to take logs from script, and produce svg, gif, png, webm, mp4... js output.

[s] http://man7.org/linux/man-pages/man1/script.1.html

[Pawamoy]

I did that in another way: write a demo script, and make it execute in another terminal. Snippet on GitLab [1].

Simply call it with "shell-demo DEMO_SCRIPT", and follow the instructions.

Demo scripts examples are given aside the snippet.

[1]: https://gitlab.com/snippets/1730340

[jquast]

the timing information you want is what 'ttyrec' is for http://derpi.tuwien.ac.at/cgi-bin/man/man2html?1+ttyrec