🏠 back to Observable

Window height

We have the reactive variable width that returns the width available to the application we are working on; it’s evidently a significant fraction of window.innerWidth. Is there something similar but for height?

Note that window.innerHeight returns a number that is generally much larger than the actual height appears to be. Using my browser’s inspector, it looks likewindow.innerHeight tells us the height of an iframe that actually holds the notebook.

Unfortunately there is not (because of the way the sandbox works). You can get the screen height with window.screen.availHeight or window.screen.height, or you can derive a height from the width using a fixed aspect ratio (e.g., width * 16 / 9). You can also pop-out and control a window using window.open…

Can you provide a little more detail on what you’re use a reactive height variable for?

3 Likes

Sure! I’m thinking of building brackets for the NCAA tournament. I’d like to have the option fit it all on one screen so space will be at a premium. It’d be nice to know width and height so I can pack it in as tightly as possible.

I was already planning on falling back on screen.height. I didn’t know of screen.availHeight; I can make it work well enough with that.

Thanks!

1 Like

While it’s not quite done yet, here’s a look at the NCAA Brackets I was talking about:

Again, vertical space is at quite a premium so it’s nice to have a reasonable way to pack it onto the screen as tightly as possible.

I think it might be worth pointing out that, while window.innerHeight doesn’t work so well here on Observable, it still works as expected when embedded on an external page. For example:

2 Likes

I’m also stump by this, and find it very difficult to implement the same canvas for various situations (observable cell, observable fullscreen, embed, embed fullscreen, embed with an horizontal orientation)…

The fact that a div styled height:100vh creates a cell of “infinite” height seems like a bug. If it worked we could measure it and be done.

I’m testing various things here https://observablehq.com/d/4c93b0a38746440c
the notebook embed is here http://visionscarto.net/obs/height/

It’s half-working, but still not good in the sense that on iPad and iPhone, if you change the orientation of the screen two times, you end up with a square canvas…?? I’m clearly missing something, and I don’t see what.

It would be really cool if we had a simple reactive height() to do this, but i’m looking for any kind of solution :wink:

2 Likes

From what I understand, the problem is that viewport (and in that respect vh) refers to the size of the parent browsing context (a.k.a the “initial containing block”). For an iframe, this is not the parent document, but the iframe itself.
In Observable, the worker iframe is always displayed at a fixed height that is the sum of the cell content heights as reported by the worker, and the editor heights.

To see the offset_node messages, check out this notebook and disable the option “ignore offset_node events”.

I imagine that a (very, very hackish) solution could abuse IntersectionObserver, in a way similar to how it’s done here:

Here’s my solution: https://observablehq.com/@fil/height

it’s a bit wild but I’ve been able to test it on these scenarios:

  • observable cell
  • “observable fullscreen”
  • fullscreen
  • embedded on iPad/iPhone, horizontal & vertical

Let me know if you have suggestions.

PS: The application I’m working on is at https://madmeg.org/delizie/test.html (contrast with the older version under leaflet https://madmeg.org/delizie/). I needed height to be able to use exactly the space that’s available—and avoid loading useless tiles.

3 Likes