What I’m running into is that 5vw (or other relative sizing) work well loading the app on mobile/smaller screens (i.e. ensuring the text isn’t too big), but they get WAY too big when loading on a big monitor/desktop.
If values like that can be assigned specifically to HTML Canvas text properties, then it seems like it would straightforward feature request material. If canvas text properties are special and don’t work with those kind of CSS values, then things are more complicated. However, I think @mateusz is working towards making text use DOM rendering more generally, so there might still be a path to support those (just a longer term one).
It appears that when you assign relative sizing to html canvas text, specifically axes/titles, the plot width/height size calc is not done correctly (i.e. it doesn’t get sized to accomodate the text):
I’m not sure if this intended or some unavoidable thing → I’m just trying to learn how to deal.
If I go back to say “pixel-based”:
attrs:
Axis:
axis_label_text_font: arial
axis_label_text_font_size: 18px
axis_label_text_font_style: bold
axis_label_text_color: '#17648D'
major_label_text_font: arial
major_label_text_font_size: 16px
major_label_text_font_style: normal
Title:
text_font: arial
text_font_size: 20px
text_color: '#17648D'
With “scale_width” for sizing mode, I get a nicely shrinking plot, but the fonts don’t go with it:
Now where it gets “interesting” is that if I instead style something with an InlineStyleSheet , and set the sizing mode to scale width on them, I can get the behaviour I want. Example with a slider:
I did not express my thoughts as clearly as I could have. My questions was a very specific one about what values the browser’s underlying ctx.font accepts. If ctx.font could accept those kinds of “min” specifications, then I think it would be a trivial matter to loosen Bokeh’s property validation to allow those values to be passed down to the browser.
However, having thought about it a little more, I do think it is doubtful that ctx.font can use these kinds of values. The HTML canvas text rendering APIs are very simplistic, unfortunately. So I don’t think this will be an avenue forward as long as plot text is rendered using HTML canvas APIs.