Multiple range sliders #1355
Multiple range sliders #1355
Conversation
- add 'rangeslider.autorange' attribute - and rm _needsExpand flag - add range slider calcAutorange handler to compute range slider auto range during the calc step
src/components/rangeslider/draw.js
Outdated
| margin.t + graphSize.h * (1 - oppDomain[0]) + | ||
| tickHeight + | ||
| opts._offsetShift + constants.extraPad | ||
| ); |
There was a problem hiding this comment.
I think I got this right. I would appreciate having something take a second 👁️ at it though.
There was a problem hiding this comment.
I guess something in here is responsible for the small position differences in the mocks? I'm not bothered by the differences, except that some of the new ones look a little bit fuzzier than the old ones. Can you try and round it so that the outer edges of the range slider border are exactly on a pixel boundary, even if you have non-integers in layout.height, the margins, rangeslider.borderwidth and anything else that comes into the calculation?
There was a problem hiding this comment.
@alexcjohnson some improvements on:
multiple-rangesliders...rangeslider-crisp-round
I think the mocks look better to my 👀 , would you mind taking a look at them?
There was a problem hiding this comment.
Also, this isn't new but I'm just noticing it now while we're here: should we switch handleStroke to be Color.defaultLineColor = '#444' instead of #666 as it is now? And to avoid duplication, handleFill = '#fff' is already available as Color.background - to explicitly match how we define zoombox corners
There was a problem hiding this comment.
There was a problem hiding this comment.
The image you've pasted here is blown up (with browser zoom?), so the rounding isn't quite right and consequently there are still some odd 1-pixel effects at the corners. When I look at the rangeslider-crisp-round branch locally it looks almost perfect.
I realize this is a borderline obsessive ask (which side of the border?) so I did it myself in 29a31d5 and b49ea77. I just tweaked it a tiny bit to get the symmetry right: both handles the slightest bit more on the dark side. I suppose we could bump the width either up or down 1px so it would be possible to have them each exactly symmetric across the dark/light line, but to my eye anyway symmetry between the two handles is more important. Also included rounding of everything that goes into the grabber position before offsetting, because sometimes we were still getting a non-integer starting point, making the half-pixel offset moot. Kind of annoying but I think now it's really truly guaranteed to be an honest rectangle.
Seem reasonable?
There was a problem hiding this comment.
Aaand in case you weren't 100% convinced I'm being obsessive - I've got a retina display on my laptop, and a non-retina external monitor. The retina display still rounds off all the corners, since it doubles the real number of pixels displayed. I'd say this looks fine, perhaps even better than the perfect sharp corners on a non-retina display - because it's a consistent look and the missing pixels are smaller than the line width so the line really looks rounded, not broken like it did on regular monitors before. Screen shot blown up so you can see the individual retina pixels:
- increase handle width - add `Drawing.crispRound` for crispier 'stroke-width' for handles and mask regions - improve grabber positioning
Better looking range slider handles
|
💃 |
resolves #1250
This PR also:
xaxis.rangeslider.autorangeallowing users to turn on/off range slider autorange computations.