Thanks for review, can you please explain what does “sloppy” means? Or attach a video demonstrating.

Upd. See attached video. It is very strange, cause i used for testing Samsung Galaxy J1 (not 7, but 1, very slow device) and it shows very decent zoom animation. At least far better than shown on your video. I recorded video from J1 to show you, please, check it.

First i think this is a fake screenshoot, but tested for myself and yep, bug, you are right.
Upd.: found the bug, it's on formatting, child's mistake, sprinkle my head with ashes

Thanks, will fix it.

I tried to pay attention not only to performance, but also to UX/UI details, sometimes they are on different sides of the barrikades and compromise need to be found. Btw, it's not minified (as was requested by the submit bot). Minified gzip version is 17KB.

1. That's why you can move tooltip vertically as you wish, to reveal all data you need to see. This is far better then jerking panel which tries to decide by itself where to position it to be all points visible.
2. Yes, have no time to implement all animations.

hard not to notice ;)

It's up to developer to set constraints. For hourly graph snappging/ magnetic behaviour to day bounds is by design (ft least at vide for last chart). But agreed, for 5th chart it is obvious, for another one it depends, i think that it is useful to snap to bound to quickly switch days

1. Can you please attach video demonstration
2. There is marnet behaviour of slider, it'is done not very well and for long swipes follows the fingers with some time trail.
But animations itself should be fast, again, can you provide video to see this issue
3. Yes, I don't like it :) leave it to the very end, and not even done main features, but have no regrets about this animations, as far as i can see it on another solutions, even done as expected it is very annoying
4. That is bad with this? It's normal for mobile devices to allow users to zoom.

I can't see "very laggy" on applied video, but if you stated this, let it be so, can agree that it could be done better.

Range is rounded, as was recommended by TG contest team in review for my app at first stage, by the power of ten multiplied with 1,2,5, as much power as possible to be chart as much visible as possible (this can be catched from mockups), i'v decided to use threshold 0.5 of lines step size to check is it suited rounding or we whoudl decrease rounding step. It gives nice numbers and quite good fullfillness of chart area.

Second line corresponds to the range of the first one (because main range line is certanly the left one), but when we switch first on/off it seems to be that second one could for now fill all available space as it wanted to, and so i do at first iteration, but in reality this behaviour simply looks weird, because then we switch the second one - first one never changed its scale, this is a confusing situation for user so i've decided not to adjust second line range on first one switching on/off too, it looks more logical and less confusing.

It is by desing exaclty, see JS_9.png, some padding outside main area, looks pretty in mobile devices

it's absolutely irrelevant, everyone has initital config and this values can be tuned, i simply use 25% of total data size, approach no worse than others

Can you explain in more details?

Thanks, i'v tried to do every tasks but underestimated whole task, and have no time to do pie chart, but i do it after deadline, to reabilitate me for myself ) http://chart.zavtramen.ru only morphing transition, as the most tricky part

But it loads after you stopped raping it ;) and no errors

1. This is done on purpose. For small range changes values switched without movement to prevent visually glitchy line-numbers shift and fade for a couple of pixels (because their shift is correlated with their position on the plot and range they represent), so i move them out only for big range changes, for small they stand still and do not distract user with endless inplace animation
2. Yes, I don't like it :) have no regrets about this animations, as far as i can see it on another solutions, even done as expected it is very annoying 

Yes, excluded adjacent day bars from view, but forgot to exclude them for selection.

Strange, did't see this artefacts nowhere. But i've tested a lot, including FF for windows 10.

1. subjectively, but yes, i also think it could be done nicer
2. first man wrote about it, i did it after deadline, if it means )
3. yes, font stack is no very safe, but in normal web app we are always using font-face, so this is not a big deal i think.

thanks for voting!

1. Witty Owl already issued this Apr 19 at 20:49
2. But i think that it'is in right position, bars shown outside main chart area are not included in trimmer selection. This is right behaviuor and can be easily proven: in the extreme positions, i.e. at the beginning and and at the end of the chart where there no overflowing chart data trimmer position is also at the beginning and and at the end of the preview. Attaching image from mockup.

This is usefull to move it vertically by yourself to reveal hidden points if they appear on the top of the chart, this is my UX decision. Btw, if you check JS_1 and JS_2 mockups you will see that tooltip is not always on the top.

Nope, it visible, small semi transparent lines on top.

And it shouldn't. Look closely to JS_1 mockup and you will see.

Due to a rounding we has some space to play within, to get nice looking numbers and good chart area fulfillness. If lowest visible line point will always be on the bottom Y line we will obviously can't get nice looking Y 
values