A polyfill is available that allows you use to use it in browsers.
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...>.)
if the JavaScript isn’t run [...] you’d like the diagram to still be visible in some form.
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.
Comments
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—
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.
Fair point on the point on the term polyfill. Done, replaced it with "JS renderer" [1].
[1] https://github.com/google/typograms/commit/4270c0ad387a2b500...
I'd say that this is the perfect use case for a custom element