Yeah, the whole iframe thing is funky, right? The issue here is that your preview code runs in sort of a sandbox (the iframe). So, it doesn’t share any code with what’s going on in the editor page.
So, if you desired to show a font there, you’d have to load it in the preview routine, which becomes a little bit crazy. (Even if, like me, you write all of your code in the initialize routine and then just call the functions defined there in other places.)
And since there’s no mechanism for loading scripts your need in the iframe, you have to bootstrap everything in the preview function. This gets double-plus-crazy really fast.
Like, Bubble almost surely uses Google Font Loader to load fonts. But you don’t have that loaded in the preview iFrame. So you’d have to do something like what my LOADERR plugin does and manually add Google Font Loader to the page (which in this case is the iframed page) and then call it. It’s just crazyballs and probably won’t work because it seems like there are limits on how long the code in preview can be?
(Can anyone confirm if that was ever fixed/changed?)
Basically, the preview function as envisioned now is useless-ish. You can use it to do cute tricks like what I do in LOADERR and the latest version of List Shifter, but you can’t build an accurate preview of a dom-rendered element (which would seem to have been the motivation for this… so, it’s a little hard to understand why we have it at all).
Maybe the team at Bubble could enlighten us a bit with some video docs about how the heck you’re supposed to do anything useful (by which I mean – representing a preview of a graphical element) with the preview function. (There’s lots of neat stuff you can do with it, but you can’t – for example – build a preview of something like Calendar Grid Pro – or even your simple, styled button without a LOT of chicanery.)
Aside: Somebody prove me wrong, please, and give us a lil’ demo of how you do this.