If you want a narrow table, you will have to do something like:
table.querySelector("table").style.width = "auto";
See an example here
If you want a narrow table, you will have to do something like:
table.querySelector("table").style.width = "auto";
See an example here
Great, thanks. Perhaps even better we can restrict the div’s width: Narrow Table / Jacob Rus / Observable
Another table idea: the lazy loading of table rows is nice, but should the height inside the div (used for the scrollbar) perhaps be set to reflect the full number of rows, so that the scrollbar doesn’t constantly reset as a reader scrolls down?
Not sure if these are bugs or just behaviors I find surprising, but here’s a notebook with two findings re. Range
: Range Test / Yuri Vishnevsky / Observable [edit: resolved; Mike left some comments in the notebook. Thanks!]
Using the inputs in an educational context, I’m getting complaints from the folks who look out for accessibility issues. Is there an easy way to make the inputs larger?
Yes, you can add a cell with this content:
html`<style>form, table { font-size: 1.5em !important }</style>`
Another candidate Observable Input is Jeremy’s Select Order Input.
Use case:
I’ve been especially enjoying using bind
to synchronize inputs, so here’s a little example of how to implement it in your own custom inputs:
And, using that, some textarea inputs that take a parser and formatter, for e.g. pasting from tables or spreadsheets: Structured Text Inputs / Toph Tucker / Observable
The numerical input to a Range input is not limited by the min. and max. values:
To me, this is unexpected. Stricter input validation helps avoid problems downstream. This is why html inputs allow for validation.
Correct. This matches the native HTML behavior; if you hit enter while the number input is focused, the browser will display an error, e.g.,
That said, I think it would be appropriate for the Range to not report the value while it is invalid. I recently added that for the Text input and it would nice to be consistent here. I’ll file an issue.
Thanks ! On my Chrome there is a error pop-up when hovering which I had not even noticed before because of the delay for the pop-up. The Range input is conceptually a bit different from the native number input because it is accompanied by the slider. So there is more of an expectation that the range is limited strictly.
It looks like all the other inputs do not require more validation checking. (sorry, edited)
What’s the best practice for combining multiple inputs on the same cell? I’ve seen a couple options:
I tend to leave these in different cells and only combine them in HTML after I embed the notebook using the Javascript runtime. That gives me maximum flexibility to embed it however I want.
Ongoing discussion of how best to do compound inputs here:
We don’t have an “official” recommendation yet, but we will hopefully have one soon.
Sounds interesting. Do you have an example you could share?
So here’s a webpage involving Fourier series that I’m working with right at the moment. It’s an embedding of this notebook:
The controls are all laid out linearly from top to bottom in the notebook.
In the webpage, though, they are all laid out in a tabular fashion. If you view the source code of the webpage, the key portion looks like so:
<div id="observablehq-top_matter-fb7854a9"></div>
<table>
<td id="observablehq-viewof-f_text-fb7854a9"></td>
<td class="right" id="observablehq-viewof-example-fb7854a9"></td>
</table>
<div class="interactive" id="observablehq-fourier_convergence_picture-fb7854a9"></div>
<table>
<td id="observablehq-viewof-n-fb7854a9"></td>
<td class="right" id="observablehq-viewof-L-fb7854a9"></td>
</table>
<div id="observablehq-viewof-type-fb7854a9"></div>
Now, it’s not necessarily good form to use a table
for layout. I do this for controls, though, which I view as data - which is what a table
is for. Plus, I think this gets the point across.
I personally view Observable as a development environment for clean, well documented Javascript code. Layout in a webpage is a separate issue and I prefer to keep that distinction clear. Furthermore, once you grab the Javascript Runtime embed code, you can take those DIVs in that code and style them and put them just about anywhere you want in a web page.
There’s a new Textarea input:
Having some trouble embedding these inputs into an HTML page. I have two inputs, both Radios, that control the scale type and the color scheme of a chloropleth map created using Vega-Lite. The map code takes the output of the two Radios and they become the values for scale-type and scale-scheme. When I embed the three cells in an HTML page, however, I get a RuntimeError:404.
Is there a guide or some examples on how to properly embed these inputs?
is the answer to your general question. I don’t see how to address your more specific questions without a link to to a shared notebook. A 404 (not found?) error sounds like a problem that’s not specifically related to embedding.
I notice something odd with the search. The first search has zero results.
But adding one character returns five results.
Is it the - that’s causing issues here.