when `submit` is true, the range value label won't get update when a user drag the slider. This is probably intended but lose the ability to "preview" the current range. It would be more intuitive to preview the range while using slider even the final value can only take effect after submit button is pressed. Is it possible to separate "update slider value label" and "assign final range (e.g. either via submit button or mouse release event"?

@easz rangeSlider() uses the input widget from https://observablehq.com/@jashkenas/inputs which handles both the submit button and the text output. So unfortunately it's not possible to change the current behavior without reimplementing input(). For what it's worth, you can built your own widget around rangeInput() (like I did in https://observablehq.com/@mootari/gen-what-goes-up). I also plan to add a version that matches Observable's Inputs library. Don't know when I'll get to that, though.

@mootari thanks for the suggestion. I will try to make one. :p

Let me know if you run into any problems, or if the documentation is unclear. :)

a quick attempt: https://observablehq.com/@easz/range-slider#cautious

I think the cautious option should be implemented in rangeInput(), as rangeSlider() merely decorates it.

yes, that would be much cleaner and elegant. My current "fix" is to directly manipulate `action` parameter from `@jashkenas/inputs` object which is declared in rangeSlider(). It is not the best way... :(

On second thought, rangeSlider() is the right place, but rangeInput() should dispatch a synthetic "change" event on release.

Once I had the 'cautious' option implemented, I found out that the "mouseup" event or handleDragStop() is not fired if I release mouse outside the input elements. Of course it is not relevant without 'cautious' feature. Just a comment.

rangeInput now dispatches change events.

Is there a way to use this one with Dates?

something like this? https://observablehq.com/@easz/range-slider#timeRangeSelected

pretty much! thanks!

Not to second guess you, but is it worth the trouble? If the majority of importers are importing rangeSlider, which depends on @jashkenas/inputs anyway, it seems like a shame to use a dynamic import here and load a duplicate version of the runtime. Not to mention the hassle the require conflicts. And if you used a static import, importers of this notebook could use Observable version locking and have control over what version of @jashkenas/inputs is loaded. And if they’re using @jashkenas/inputs too (which isn’t unlikely), they could avoid loading a duplicate version of it, too. And in the near future, it’s more than likely that standard static imports will be lazily evaluated in Observable also, as you suggested here: https://github.com/observablehq/feedback/issues/74

> If the majority of importers are importing rangeSlider, which depends on @jashkenas/inputs anyway, it seems like a shame to use a dynamic import here and load a duplicate version of the runtime Agreed. I've inlined `input` and removed the dependency on @jashkenas/inputs entirely. The docs also received a major overhaul so that the other inputs widgets are no longer needed. > importers of this notebook could use Observable version locking and have control over what version of @jashkenas/inputs is loaded. And if they’re using @jashkenas/inputs too (which isn’t unlikely), they could avoid loading a duplicate version of it, too That seems unlikely, because I had it pinned anyway. Unless the locking options allow one to override transitive pinned versions. Some background: The idea behind lazyImport() has always been to enhance a notebook's documentation without adding bloat to imports. An extreme example is `@tomlarkworthy/view`, where prior to adding lazyImport() the notebook would always import 4+ additional notebooks for its tests, docs and footer. In this case I tried to hit two birds with one stone, because I intended to deprecate rangeSlider() in favor of interval() anyway. > And in the near future, it’s more than likely that standard static imports will be lazily evaluated in Observable also That's great news, and once it's in I'm more than happy to rip out lazyImport().

Stay tuned. I’ve got it working and if I can get it reviewed it should be available this week.

That's amazing news! Can you ping me as soon as it's published? I expect I'll have to update https://observablehq.com/@mootari/observable-ast to match the new source structure.

the lazyImports approach was great for dev dependencies like unit testing, by lazy importing it you avoid at least one network round trip to the API endpoint. But you still ended up shipping the actual unit test code and documentation in the module though, so it was not totally ideal still, just better than static imports.

First off, thanks for building this it's super useful! (I used it in this notebook: https://observablehq.com/@mpkhinda/nyc-pothole-politics) I ran into the issue that if you slide the range slider to the last value with a range of 1 (so handles overlap) it becomes impossible to slide back because you can only grab the end handle on top that won't move downwards. Not sure if there's a super elegant solution to this behavior, but thought I should mention it.

You can click to the left of the range to move it, so that the right side becomes draggable again. This is where the behavior deviates from other range sliders which reposition the handles on click, because I found it more useful to move the range as a whole. Some solutions I can think of: - allow handles to be moved past each other - assign a higher z-index to the handle that's closer to the center of the range - provide an option to set a minimum range

... though iirc I made sure that the handles never fully overlap, and as far as I can tell that's true for your case as well. There should always be at least a small slither that lets your grab the left handle.