Closed juba closed 4 years ago
@juba I really like these changes. I tried to test as best I could but not sure we can ever capture every potential combination/use. Are there any Observablehq notebooks that you like best to demonstrate the effect of the change? Maybe we should include a couple as examples. I'll keep trying to find some. Most of the @d3
notebooks use viewBox
which masks the change.
If you are looking for approval, you have mine :)
Thanks for your approval ! :)
I think there are several cases of examples :
the notebooks that define an height
variable, for which this change allows an easy embedding in Shiny and Rmarkdown document (of course there are many, like this horizontal bar chart)
those who don't define an height
variable and rely on the width
from the standard library, so you have to add an height
argument to adjust the widget height to its output height, such as this one. Those benefit from the change nevertheless, as fixing the width
avoids them to be resized when the page is, even if their parent element is not.
I think there may be other cases, such as when width
and height
are explicitly defined. I didn't check with this kind of notebook yet...
Not totally sure about this one yet but after a bit of tinkering I think it may be the best default.
If the new R
update_width
argument isTRUE
(which is the default), andinput$width
is not defined, theninput$width
is replaced by the actual width of the widget root HTML element. The same forheight
. The replacement is done both at widget creation and when resizing.width
will always be an actual notebook value, as it is either defined in the notebook or by the Observable standard library. This is not the case ofheight
, but we try to update it anyway (just displaying a JS warning if the variable doesn't exist).The aim of this is to provide, as much as possible, convenient out of the box behavior when
robservable
is used inside Rmarkdown documents or Shiny applications.