since these links go to the same place and Input seems most useful with bind, i'd reframe this section to just talk about bind (instead of a list of "a few more advanced techniques"). bind is amazing!! having an officially supported path for synchronized inputs feels like a big reason to upgrade

I’m planning for this section to grow over time and include third-party notebooks. Added a “coming soon”.

Would it make sense to link @Toph's Custom Notebooks guide here? https://observablehq.com/@tophtucker/custom-input-example

Is there an easy way to make a slider that slides from the higher number to the lower number? I've had use for this in the past (https://next.observablehq.com/@borisvish/beyond-the-normal-distribution) and the trick that I used there needed to be explained to the person I was working with.

(the "Transform Normal to Skewed Distribution" slider slides from 1 to -1, since 1 makes the chart lean left and -1 makes it lean right)

@yurivish You can provide a transform function: Range([-1, 1], {transform: x => -x})

Oh cool, that works! Consider this resolved. Thanks @mootari!

Thanks for answering @mootari!

@yurivish if you do `{ var neg = x=>-x; neg.invert = neg; return Range([-1, 1], {transform: neg})}` you can save some root-finding. If no explicit inverse is provided it falls back to github.com/observablehq/inputs/blob/main/src/range.js#L70-L81

Maybe Range could detect the [max, min] case and automatically apply a negate transform, too. https://github.com/observablehq/inputs/issues/70

Good idea, thanks @jacobrus!

Perhaps add an explicit link to github.com/observablehq/inputs?

It’s down below where it says “please see our repository.”

Maybe I missed it, but is there a <textarea> input (for multi-line text)?

Not yet, but you can thumbs up the issue: https://github.com/observablehq/inputs/issues/10

Suggestion: move the `Text = Inputs.Text`, `Button = Inputs.Button` etc. cells to be at the top of the relevant sections, so that when someone clicks on e.g. the link to `Button` in the output of their `import {Button, Text} from '@observablehq/inputs'` cell in a different notebook, the link which points at https://observablehq.com/@observablehq/inputs#Button will scroll to a description instead of to the decontextualized assignment at the bottom of this page.

Is there any recommendation on how to style these inputs?

You can style it with external CSS, but this is not recommended. Observable Inputs are intended to provide a well-designed, consistent appearance by default. For more customization, see https://observablehq.com/@bartok32/diy-inputs

What's the API for customizing these inputs? same as [diy-inputs](@bartok32/diy-inputs)?

What is the current method to require Observable Inputs in my Notebook? I've been using: Inputs = require("@observablehq/inputs@0.7.21/dist/inputs.umd.min.js")

Inputs is included by default in all notebooks as part of our recommended libraries, so you don’t need to do anything: https://observablehq.com/@observablehq/recommended-libraries

Any plans to add the Scrubber as a first class input? As this range input only supports numbers, it'd be nice to have one that supports non-numeric ranges, especially with the "Play" functionality.

Yes, I think we should add Scrubber. I filed an issue. Thank you for the suggestion!

It is perhaps a bit misleading that in this notebook these components are not imported this way.

That’s because this is the notebook that defines the inputs. They have to live somewhere. 😆

Any chance of adding a datetime picker?

Feel free to thumbs up this issue: https://github.com/observablehq/inputs/issues/38

Hoping for a color input : https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input/color

Is there a way to distinguish between the empty selection and full selection? I have a use case for wanting to show some extra information for the selection, but my table has hundreds of rows and I don't want to show all details for all rows by default. I though that comparing rows === search might work but this is false when there is no selection.

Yes, I agree. The value of a table with selectable rows should default to empty (for consistency with e.g. multi-select inputs), possibly with all rows available via a separate name.

Maybe there should be a shortcut for pre-selecting all rows? (Or am I missing it?)

You can say viewof rows = Table(search, {value: search.slice(0, 2)})

The value of the Table is always an array, whereas the input can be an iterator, and also they can be in a different order if the table is sorted, so yeah, you can’t do an identity comparison to check whether the selection is empty. You can preselect all rows by passing {value: data} (above, {value: search}), but I don’t think that’s what you want here because you’ll see lots of checked checkboxes. We’re not going to change the default value to be the empty array, but I could see having an option, say {allowEmpty: true}, that when enabled would return the empty array when there is no selection, rather than all the data.

Is there a way to hide the column with the checkboxes, when the table is just used for displaying data?

@nitaku Not yet, but there is an open feature request: https://github.com/observablehq/inputs/issues/136

Could this include a "Friends & Family" section, similar to the old one, for third party inputs which adhere to the new look?

Done! Added a table of third-party inputs, and took the liberty of adding your new FineRange to the list. Thanks for the suggestion.

I'm pretty sure the dates here are inaccurate. Was every current state capitol really established exactly on Jan 1 of the relevant year? My guess is someone took the list of years from Wikipedia or similar and arbitrarily added -01-01 to the end of every one. *capital

JavaScript has no built-in type for representing ambiguity or imprecision with dates. We’re using the Date type here, but it isn’t intended to imply that the state was established on January 1 of the given year, or for that matter, at UTC midnight. Furthermore, the Table doesn’t know the precision of the date, and the minimum precision of the default format is YYYY-MM-DD: https://github.com/observablehq/inputs/blob/bf525033948bbdda452e65bc06c09a6b42f3b06c/src/format.js#L16-L27 This mirrors the behavior of d3.autoType, which is used by Observable’s typed: true option for CSV and TSV files, and needs at least YYYY-MM-DD to detect dates: https://github.com/d3/d3-dsv/blob/aba1cce0e59500db67eab8f1a07dbd6a7a175064/src/autoType.js#L9-L12 We could use a year number here instead, but a Date is preferred to indicate that it’s a date. (And numbers can’t inherently represent ambiguity either.) If desired, you can specify a custom format when rendering dates in a Table so as to drop the -01-01, or perhaps to indicate ambiguity explicitly. I did not do that above because it slightly complicates the example code. For example: Table(search, {format: {Since: d => d.getUTCFullYear()}})

I see these on npm. Could I use these outside of observable with the dependecny?

Yes.

Should searchFilter and the various format* helpers also get their own cells so that people become aware of these more easily?

I made 2 custom inputs few years earlier, maybe it can be useful for someone. One it's a color scheme and interpolator picker: https://observablehq.com/@zechasault/color-schemes-and-interpolators-picker And the other it's an Easing graph editor/picker, made with my brother: https://observablehq.com/@nhogs/easing-graphs-editor

Here is an input for loading data from CSV, JSON and MongoDump files, which also supports a default initial value https://observablehq.com/@john-guerra/data-input

Also two inputs for selecting multiple elements https://observablehq.com/@john-guerra/search-checkbox Searchable checkboxes with select all https://observablehq.com/@john-guerra/multi-auto-select Select multiple elements with a search input

Here's a quick crossfiltering input (a la Search input): https://observablehq.com/@gampleman/crossfilter-input

This is VERY cool @gampleman, thanks for sharing!

I made an input for selecting a part of an image: https://observablehq.com/@sanderevers/croppr

What about inserting both a lower and an upper bound?

I would be interested in a range slider for an interval, too!

Please upvote the tracking issue if you’re interested in this feature: https://github.com/observablehq/inputs/issues/53 It’s not trivial to implement because it would require implementing a custom control (user interface), whereas all the existing inputs build no native controls provided by the browser. It’s not quite as good, but you could also consider using separate range inputs for start and end, or offset and limit.

I made one here: https://observablehq.com/@andyreagan/sortable-list