You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ I have **used and carefully analyzed a lot of carousel/slider components**. I su
43
43
13. Some of them disable pinching to zoom, while some others glitch when pinching with 2 fingers. Besides, when the window is zoomed in, most of them still detect for touch swiping to move to the previous, or the next slide, while the intention of most users in this scenario is panning to see other parts of the current slide.
44
44
14. Some of them will cause the slides to stuck its position on window resize or on mobile device orientation change, until another user interaction.
45
45
15. Some of them can only have predetermined images (i.e. before the carousel component mounts).
46
-
16. Most of them do not provide a solution for fallback image (for when an image is not available).
46
+
16. Most of them do not provide a solution for fallback/placeholder image (for when an image is not available).
47
47
17. Some of them get zoomed in when the user double taps on the control, while the intention of most users in this scenario is to quickly go to the next after the next slide.
48
48
18. Some of them remove the left or right button to indicate that there are no more slides in that direction. However, user is likely to click that spot where the button used to be, which causes undesired behaviours e.g. clicking on a link or button which is also at that spot.
49
49
19. Some of them use the method of cloning the first, and the last slide to achieve looping (or infinite mode). I think that method is not great semantically.
0 commit comments