This isn’t a polyfill. Polyfills are about implementing new native stuff on old environments, but no browser is going to be including this any time soon, and certainly not in this form—
> <script type="text/typogram">
This should use <pre> instead, e.g. <pre class="typogram">. It’s content, not scripting, and if the JavaScript isn’t run (for whatever reason—JS is less reliable than people often think, especially third-party JS, even on environments that don’t try to block it) you’d like the diagram to still be visible in some form.
(Retaining the <pre> would also be a great improvement for selecting text—the current arrangement of “place single-character <text> elements” is almost useless for copy and paste (losing spaces and line breaks), which is the main reason I can imagine wanting such a thing. If character sizes and aspect ratios are a concern, control that stuff with scaling transforms or line-height, and detect and contain (e.g. <span style="overflow:visible;width:…">…</span>) individual characters that are falling out of the grid due to font fallback or bad ligatures like Nimbus Mono <https://github.com/ArtifexSoftware/urw-base35-fonts/issues/3...>.)
Yeah, that's one of the things that disappointed me about the linked page, I expected the diagrams to degrade gracefully into regular ASCII-art.
One of the ways I could imagine using this being useful is in markdown documents, following the principle that the source is good-enough to follow even if some additional processing could make it better.
[1] https://github.com/google/typograms/commit/4270c0ad387a2b500...
I'd say that this is the perfect use case for a custom element
https://news.ycombinator.com/item?id=32133345
Now, officially open sourced:
One more ASCII-based tool that you could add into your workflow is https://arthursonzogni.com/Diagon/#Sequence which can be used to generate the ASCII that you input into Typogram.
For example, input:
Renderer -> Browser: BeginNavigation()
Browser -> Network: URLRequest()
Browser <- Network: URLResponse()
Renderer <- Browser: CommitNavigation()
Renderer -> Browser: DidCommitNavigation()
.--------. .-------. .-------.
|Renderer| |Browser| |Network|
'--------' '-------' '-------'
| | |
| BeginNavigation() | |
|-------------------->| |
| | |
| |URLRequest() |
| |------------>|
| | |
| |URLResponse()|
| |<------------|
| | |
| CommitNavigation() | |
|<--------------------| |
| | |
|DidCommitNavigation()| |
|-------------------->| |
.--------. .-------. .-------.
|Renderer| |Browser| |Network|
'--------' '-------' '-------'
Renderer Browser Network
======== ======= =======
| BeginNavigation | |
|--------------------->| |
| | URLRequest |
| |------------->|
| | |
| | URLResponse |
| |<-------------|
| |
| CommitNavigation |
|<---------------------|
| |
| DidCommitNavigation |
|--------------------->|
|
"[...] that motivated me to rewrite it [- presumably: svgbob -] in JS (svgbob is written in rust)" [...]"
So, is "Typograms" a modified rewrite of svgbob in JS? IF yes, isn't it a Derivative Work of svgbob, and (per the Apache License, which seems to match the one used here) shouldn't "Typograms" keep the mention of the original author somewhere in the Licensing information, and notably their original Copyright note? (As present e.g. in svgbob's License file.)
IF NOT, then why mention a "rewrite"? What is actual relation of Typograms to svgbob? This becomes even weirder given that some of the examples in the Typograms demo seem reused verbatim from the svgbob demo - but rendered poorer (at least on Firefox); making it sound like it is a rewrite also makes it sound like it is a - sorry for this - crappy rewrite... and this under google's name... but then in the end is it actually not a rewrite? is it just a - still at first glance seemingly crappy, sorry - clone? (hm, at least I'd love to show some clearly highlighted improvements over svgbob, maybe? if I'm not to focus on the somewhat-broken parts of the demo?) aaaand still under google's name?... reeeeaaaaaallllyyyyy wierd and confusing case to me... (O_o)
If the same author wrote one version and then another, and only a minority of the code (if any) is shared between the two, it's a rewrite. Especially if the new thing is intended to replace the old.
If one employee at an organization produced the first version of something, and another one at the same organization produces the second, using very little of the original code, that's also rewrite. The organization is doing a rewrite, even though that second employee is writing it for the first time.
Someone not connected to the original who knows only the interfaces, or inputs and outputs, isn't doing a rewrite; they are "cloning" or "implementing" and such.
That said, I haven't seen this or the mentioned related work before, and it's really neat how easy it is to create good looking and very readable diagrams with this.
The examples don't show the source code next to them, but you can just view the page source in your browser (e.g. Ctrl-U in Firefox).
+---+ +---+
| A |-->| B |
+---+ +---+
┌─┐ ┌─┐
│A│→│B│
└─┘ └─┘
Also, the examples in the last 3 sections in "Scribbles" ("Small curved steps", "Parenthesis and spheres", "Diagonal Side-way Arrows") don't seem to actually render anything interesting, just showing what is presumably the original ASCII-Art behind them. I'm confused if that's what was intended there, or something is broken (?)
edit: The whole situation is even weirder given that half of the motivation claimed by the author in the "Related" section is apparently specifically: "ran into enough challenges with [...] the text rendering [in svgbob ...] that motivated me to rewrite it in JS (svgbob is written in rust)". I mentioned my confusion about relation to svgbob in a top-level comment here, but the quote above makes it even weirder to have Typograms actually render text poorly (in Firefox)... and the jokes and tropes just seem to want to write themselves here, whether about rewriting Rust in JS, or about Google ignoring Firefox...
But if the maintainer(?) is reading these comments it looks like the inductor in the circuit section isn't working correctly. I can separate "C" characters rather than the normal circuit symbol
In the "Circuit" section there is the text "30uH" and a few characters to the right of that there is a column with 3 "C" characters arranged vertically. Next to each "C" character is a pipe "|" character.
The standard unit of inductance is the henry (H) so I assume 40uH is the value of that component and therefore I would expect that arrangement of 6 characters to map to an inductor symbol: ( https://commons.wikimedia.org/wiki/File:Inductor_Symbols.jpg ) rather than staying as separate C characters with a vertical line next to it.
(If this is a bug with my browser then I can only say that I'm using Chrome on MacOS and everything else looks correct)
There is a small list (in spanish) in: https://tomatesasesinos.com/2020/06/11/anti-nocodetools-diag...
https://ascii.dataviz.gallery/
planning to grow it soon with a more thorough breakdown of what libraries are available for what programming languages
How can it be both “easy to change” and not be ergonomic?
If you look at the page source, this is what the grids look like for instance:
+----+ +----+
/ \ / \ .-----+-----+-----.
+ +----+ +----+ | | | | .-----+-----+-----+-----+
\ / \ / \ | | | | / / / / /
+----+ +----+ + +-----+-----+-----+ +-----+-----+-----+-----+
/ \ / \ / | | | | / / / / /
+ +----+ +----+ | | | | +-----+-----+-----+-----+
\ / \ / \ +-----+-----+-----+ / / / / /
+----+ +----+ + | | | | +-----+-----+-----+-----+
\ / \ / | | | | / / / / /
+----+ +----+ '-----+-----+-----' '-----+-----+-----+-----+
You could benefit from tooling to produce the underlying ASCII diagrams; this tool is just a renderer to make them look nicer.