@mcmcclur I knew you’d come through on this! Thank you!!!
FWIW, could you explain one detail about how the “yield in one cell” method you demonstrate in your notebook works?
Specifically, midway down the cell you do yield svg.node(). I know (from your fantastic response to another forum post) that this transforms the D3 selection svg into instructions to the browser/DOM resulting in html rendered in the cell. (Of course, correct me if I’m wrong about that!)
But I don’t understand why the block of code immediately after the yield (i.e. pretty_math.each…etc.) works. In my brain, the variable pretty_math at that moment in the code points to a D3 selection. And in my brain, any given selection is not the same thing as DOM nodes returned by selection.node() nor is it the same thing as the actually-rendered HTML resulting from yield selection.node(). So how would the correct information about the rendered widths and heights of the math nodes be returned when the function called by each does this.getBBox()? At that point in the code, this (I think) points to the the selection prettymath, not to the nodes returned by prettymath.node() or the HTML rendered into the cell by the previous lines.
Now, as I write all that out, I guess the answer must be something like…“rendering a selection with return selection.node() or yield selection.node() has the side-effect of updating the data referenced by the selection. Specifically, when you return selection.node(), d3 renders the selection, collects all the data about the rendered html (such as the now-populated objects returned by node.getBBox()) and updates the object in memory pointed to by selection with that new data.”
Is that correct? What’s the full and correct story about how return selection.node() or yield selection.node() alters selection?
Feel free to just point me to a book or documentation I should read!
Thanks!