And here’s the code we use on the host page to create and resize the iframe: https://github.com/asciinema/asciinema.org/blob/7250aaca1cc739bf53de9c3e804dbe6a431b4ef2/app/assets/javascripts/widget.js#L54-L84
Thank you for your feedback. Maybe @sam has an opinion for which option we should go:
- use the iframe API and find a yet unclear workaround to set the height of the iframe
- stick to the current script tag-based embed and ask the core team how script tags can be allowed from within oneboxes. Currently, they are stripped out of the cooked html.
This is going to be a nightmare, iframe is far preferable if possible.
@sickill, I suggest the following:
- we use the iframe API
- we let the onebox gem built an iframe tag that has the height already as an css attribute
- in order to know the height, the preferred height could be a parameter fetched using e.g. the oembed API.
The thing with width/height (in pixels) of the player is tricky. We don’t store/know this until the player gets actually displayed in user’s browser. The reason is, each browser/device renders fonts slightly differently (no matter how specific you are with line-height, paddings, and other CSS vooodoo, there’s lots of inconsistency). That’s why our embed script tag code doesn’t initially set iframe’s width/height (it’s not known yet!) and it receives the actual one from the initialized player within the iframe.
I would love to have a simpler way of solving this but after years of tries this seems to be the only way to have the embedded player with correct size in all browsers.
In other words there isn’t good way to know and set the height of the iframe when creating it 
(I was thinking about calculating some approximated width/height, assuming specific line-heights, font-sizes etc so we can use these numbers when building an iframe. That would clip the player for most users though, due to differences in rendering engines)
(If we used canvas tag for rendering it would be simpler and we could control the size better, but we use span etc in order for the text to be copy-pastable)
3 Likes
Hey @sam and @sickill, what do we do in this situation. Should I remove the code from the onebox gem so that we get at least a generic onebox without the “video” embed?
I still wonder that with all these new CSS features it is infeasible to get the height correctly set for some font. However, I am not an expert and cannot contribute here. 
Even setting a “roughly correct” size and then adjusting it later is preferable to “YOLO WE CAN BE ANY SIZE AT ALL FROM ZERO TO INFINITY PIXELS!”
Surely there’s not that much variance in size.
Ok, let’s assume we have a way to set “roughly correct” size when building the iframe. What options for adjusting it “later” do we have (if any)?
Hey guys, should I prepare a merge request to remove the acsiinema onebox code so that we have the fallback generic box or should I just wait a bit longer to fix the code? At the moment, it is just broken.
2 Likes
Generic box is probably best for now.
I am trying to embed a asciinema link.
But it does not work.
I see that this commit by @rriemann was already merged.
Was this merge reversed ?
Nothing has been done.
We are somehow stuck due to the resize issue of asciinema embeds.
I had an idea; why don’t you render a clickable pre rendered image of correct size for the font and height by width in characters – which when clicked can switch to the necessary text viewport in the browser? This way at least for the typical case when passively not clicked you can guaranteee 100% accurate size independent of local browser rendering.
Because a PNG of text will compress fairly well, the image would be small and efficient – and totally pixel perfect in size!
3 Likes
asciinema.org can already generate PNG preview, you just append .png to asciicast URL. Example:
http://asciinema.org/a/113463.png
These pngs are optimized with pngquant and cached.
So your idea is that asciinema.org has a page (displaying image which switches to JS player on click) which you embed in iframe? Or discourse does the png->player swapping, doing that directly in the page, skipping iframe indirection?
1 Like
We would need a pretty custom onebox to do all of this ourselves. Ideally you could just provide the custom iframe that handles the click event and loads up all the javascript stuff it needs on click.
2 Likes
I think I now have a pretty good solution for this. See here: https://github.com/asciinema/asciinema.org/pull/286
There’s one gotcha with this (I described it in the PR description) but I think we can live with that.
I deployed this to asciinema.org already so you can give it a shot maybe. About iframe width/height: I suggest making the iframe 100% width and some sensible fixed px height (like 350px) by default, with the option of overriding it.
It doesn’t support any customization options yet (changing color theme, font size, auto-play, loop etc) like the script-tag does, but I’ll add them soon, as query parameters to the iframe URL.
4 Likes
What is the current status on this?
Right now, it embeds (and displays) properly while editing a post, but once posted, it’s not being embedded.
More precisely, the following happens.
If I one-line link embed say
https://asciinema.org/a/632251
then, while editing the post, in the right side panel I see the oembed image advertised by https://asciinema.org/oembed?url=https%3A%2F%2Fasciinema.org%2Fa%2F632251&format=xml which is https://asciinema.org/a/632251.png
<oembed>
<type>rich</type>
<version type="float">1.0</version>
<title>Running pintos using Bochs and gdb</title>
<author-name>godmar</author-name>
<author-url>https://asciinema.org/~godmar</author-url>
<provider-name>asciinema</provider-name>
<provider-url>https://asciinema.org</provider-url>
<thumbnail-url>https://asciinema.org/a/632251.png</thumbnail-url>
<thumbnail-width type="integer">1540</thumbnail-width>
<thumbnail-height type="integer">888</thumbnail-height>
<html><a href="https://asciinema.org/a/632251" target="_blank"><img alt="Running pintos using Bochs and gdb" src="https://asciinema.org/a/632251.png" width="1540"></a></html>
<width type="integer">1540</width>
<height type="integer">888</height>
</oembed>
Once I submit the post (like right now), this will disappear.
It seems that there’s no asciinema integration at all at this point, just a buggy display of some oembed-referenced images (!?)