🏠 back to Observable

Observable Inputs

I’m excited to announce the release of Observable Inputs, our first-party inputs that are designed to work with viewof:

This includes both basic inputs (sliders, dropdowns, and the like) and some fancy inputs for working with tabular data. Our goal is to help you explore data and build interactive displays. Here’s a quick tour:

We’d love your feedback. Thanks for using Observable!


I like that there are {} options for the inputs

One thing that I would like the adjust is the ‘label width’ as it seems to be too wide or too narrow.

Anyway, I really like these new inputs, thanks.

1 Like

Discussion here: Support for wider labels (without wrapping) · Issue #57 · observablehq/inputs · GitHub

Thanks for the feedback!


Love the inputs, especially the table.

I use tables in UIs a lot , but with buttons on the rows to provide context sensitive actions. E.g. a list of uses in a project for a table and column of actions like kick them from the project (can’t be done to OWNER etc).

Seems like the table is pure data ATM are you open for PRs.

I also tend to have buttons at the bottom for adding rows, but I guess that can go in a distinct cell.

Is there any obvious way to get table columns to all have the minimum width necessary for the data, all pushed to the left, with extra space to the right left blank?

Right now tables with 2–5 columns seem to often end up with unnecessarily wide columns, which makes them less legible than they would be if more compact.


The horizontal scroll position is lost when the sort order changes. It would be nice to stay approximately at the same scroll position.


Are you using auto or fixed layout? You can also specify a width object to give certain columns explicit widths.

This has been fixed in 0.7.3. Thank you for the report.


The new inputs are awesome! I can finally retire the Grand input Bazaar from my bookmarks tab!

I have one question on how to import this:

import {Button, Checkbox, Toggle, Radio, Range, Select, Text, Search, Table} from "@observablehq/inputs"


Inputs = require("@observablehq/inputs@0.7.3/dist/inputs.umd.min.js")

One common problem I had with several of my notebooks every few months is that they break when new versions launch and I had to go to npm versions page to look at the release history and the notebook publisj date for all dependencies to update the version number, if I import from the nookbook, wont it be more difficult to pin it? or this is recommended because the api will never make break changes in the future? i.e. what if someone makes a cell that styles the component in a particular way based on current version etc.,

Also, will the inputs also be part of stdlin anytime in the future?

The recommended way is to import from “@observablehq/inputs”, and to ensure your notebook doesn’t behave differently from a change in the inputs notebook, you can version pin the import like so:

import {Button} from "@observablehq/inputs@461" 

Where 461 is the version number of the notebook. You can find the version number by looking at the notebook history.

1 Like

I don’t think it’s possible to see the history of a notebook unless you have edit access. It’d be nice if the current version of an arbitrary notebook was more accessible, see e.g. this feature request thread:


These two questions are related. :slight_smile:

As @Cobus says, you can use version-pinned imports, or you can use a version-pinned require from npm. Unfortunately Observable doesn’t do much yet to help you figure out what version to specify. And worse, these approaches only help with direct dependencies and don’t protect you from transitive dependencies changing. (You can pin transitive dependencies using require.alias, but that’s even more cumbersome.)

There’s also not currently a way to specify the desired version of the standard library, which is why we haven’t yet made Hypertext Literal (the new html and svg tagged template literals) and Observable Inputs available by default in the standard library.

We’re working on it. Our long-term plan is to incorporate something akin to yarn.lock (or package-lock.json) into notebooks, so that both direct and indirect dependencies are automatically versioned, including notebook imports, requires, and the Observable standard library. With this in place, we’ll be able to make improvements to the standard library without breaking existing notebooks, and notebooks will be resilient to their dependencies changing. It’ll take some time to implement this (and it will likely mean you’ll have to be more explicit about when you want to upgrade your dependencies), but it should make Observable a better platform for collaboration and hence a worthwhile effort.


Ah yes, indeed. It is a bit trickier to find the version number than I mentioned!

At this point, the methods described in the thread you mentioned are probably your best bet to get the version of the imported notebook. I personally find the download method easier, since the version numbers are in the .js filenames in the download.

1 Like

My go-to is to edit the URL to https://api.observablehq.com/author/notebook.js?v=3 and then read the version number from the comment.

1 Like

If you don’t mind another bookmark, here’s a handy little tool that shows you the relevant data:


Going back to the original topic, I have a feature request for which I have provided some examples here:


Tom, can you use the formatter to accomplish this? See this quick mock:

1 Like

I’ve updated the Table documentation to give an example of a format function that generates HTML, and also published this as an applied example:


Is it possible to format rows presented using the Table input, such as adding a CSS class to every cell in a particular row (or to the row itself, e.g. to highlight a specific row in the table)?

It looks like the format function is called with the value as an argument. If it were passed a row index, then I think this would be possible to do using column format functions.

I filed and fixed an issue for this:

1 Like