Allow the constructor to be called with an optional parameter that turns the carousel into a vertical container.

Need to have an easy way for a user to add carousels to their document without them worrying about pasting several wrappers with unique IDs and class names.

Ideally, the user would just include a single div in their markup which will be replaced by JS with the appropriate elements that are marked with unique IDs for appropriate styling.

In addition to just progressing the carousel, the two control buttons should be able to be interacted with, giving the programmer an interface to add more event listeners. Should be careful not to remove them when creating new carousel instances, and shouldn't forget to add them to the state or options so that they are carried over into the next instantiation.

• Z-index change does not affect the chevron icon within the button.
• If there is no background color to the carousel, the button will still be visible.

May be better to completely remove these buttons from the DOM and just have the click event handler be called by the auto-scroll interval.

Though likely uncommon, there is still the possibility that an HTMLElement of the carousel (anywhere from the largest container to one of the wrappers or even an individual item) could be modified or removed. Proper action should be taken to ensure that this does not occur.

• Add exception handling for parts of the code that access a specific child element (.children[1].children[0] type of code).

The code in Carousel.ts is starting to get quite long and even a little messy. Should really go ahead and look through the entire file and organize what can be organized, potentially moving some lesser-used and larger methods out into some utility folder. Variable names, method calls, and comments need to be more consistent in order to increase the longevity of the project.

For example, many of the styling and configuration methods can likely be moved into their own designated files. This removes the one-time methods from clogging up most of the class's implementation file.

Need to determine the sections and subsections that are needed for each of the documentation pages. Maybe a good idea to record these onto some markdown file first.

Test pictures, unused SVGs, and other test directories should be removed in order to clean up the repository before version 1.0.0 goes live.

For example, the complexity involved with changing between wrapping methods means that it is likely not practical to implement this as an option that can be changed on-the-fly. Other methods including the ability to change resizing modes are questionable: for the most part, the resizing strategy for a carousel is likely to remain the same.

By limiting the number of options that can be changed on the fly, the amount of bugs that can appear is decreased significantly. It also reduces the amount of redundant code and possible combinations of options that need to be checked when others change.

Either way, this should be formalized somewhere (some markdown file) and eventually integrated into the informational webpage.

Should provide some way of adding or removing carousel items after the instantiation of the Carousel object. This cannot be done by just adding them to the originally named containing div, since its children will have been modified by the constructor.

May want to implement some instance methods within the Carousel class that accept an element to add or remove. When an element is added or removed, the carousel may need to be reinitialized. The position of the carousel should try to be preserved so that adding an element does not reset the position back to the start.

The readme has been mostly for development notes, but should now give actual project documentation and eventually link to the project's webpage.

Though a transition is required to fire the transitionend events, it can be set to 1ms if the user wants instant movement, or the transition time, delay, or functions could be customized to the user's exact specifications.

Implement automatic scrolling through a Carousel with the following features:

• Specify and change the amount of time to scroll from one page to the next.
• Whether or not scrolling should stop if the user mouses over the Carousel.
• Which direction the automatic scrolling should occur.

Give the user the option to disable scrolling in a carousel, either from the start or on the fly.

As mentioned in #18, containers with carousels need to either always or never show a scrollbar or risk having some of the content of their carousels cut off. One strategy to try and fix this issue could include comparing the starting width and the ending width of the container, and if they are different, continue to resize.

The constructor currently doesn't have any validation for invalid Carousel values. Some of these include negative dimensions or scrolling by 0 elements.

Some of the testing styles in the .carousel-item CSS class such as background color, color, line height, etc. need to be removed in order to prevent styles from being carried over into the child elements.

Currently, all carousels share the same properties including size, number of visible items, and the number of items to scroll by. Each carousel should ideally be styled on its own without conflicting with other carousel items.

Before documentation can begin being added to the webpage, a good design should be created for it. Notable features include:

• Home page with simple demos
• Getting started page
  • Downloading and installing
  • First carousels
• Detailed demonstration page with most of the offered carousel effects
• Detailed documentation page with all of the important interface options

First mentioned in #37.

Adding and removing defaults to the last index means that if we are viewing wrapped items, they are technically placed behind them. This is caused by the top and bottom pointers never changing if they go above the length of the carousel or below 0, and relying on modulo to perform the operations. The fix would just be to set the pointers correctly if they move too far in the other direction.

This issue is marked as a bug and an enhancement because while the issue does not break the code, it is undesirable.

Should also take a look at the code from #40 that sets the bottom pointer to 0 if the length of the carousel items is 0 to avoid infinite looping; this solution may no longer be required with the resolution of this issue.

Need to implement a few things to ease the user's Carousel management experience:

• Rename the CarouselManager class to Carousel, and the Carousel class to something else (maybe CarouselInternal?).
• Provide different setters for changing the properties of a Carousel, as well as setters that take in any combination of the parameters, the object itself, etc.
• Add getters to what is now the CarouselManager class so that the user can get a full report of the current state of their Carousel.

Using Bootstrap as the framework, the webpage should start to be implemented using the design from #35. Specifically, the main container for each page as well as the general set of columns for each page should be responsive for each device, with content appearing, disappearing, and repositioning correctly based on the viewport width.

The variable updating should only occur if the passed values are different from those that currently exist.

If the left and right arrow buttons are larger than the containing div, this div should grow in order to fit the buttons. If the buttons are smaller than the height of the div, they should be centered, rather than pushed to the bottom like they are now.

With resizes implemented in #15, the stretch-scale resizing method means that the height of a carousel can change, so the button sizes will need to be checked with this type of carousel.

Need to change the transitionend event listener on the carouselItemContainer in order to ensure that the target of the transition is the container itself and not one of its children.

If a carousel has a number of items visible that is not a multiple of the total number of items, the wrapping causes elements to lose their grouping on the screen. For example, imagine a carousel shows 3 elements at a time and has 4 items:

[ 1 2 3 ] 4

Scrolling by 2 now would result in:

[ 3 4 1 ] 2

Rather than the idealized behavior after this issue is implemented:

[ 2 3 4 ] 1

This would make the eventual carousel timeline in #29 much more clear, as there are two pages that can be generated by scrolling by 2:

[ 1 2 3 ] 4
[ 2 3 4 ] 1

Add an optional 'timeline' that shows the user's current progress through a carousel. Will need to keep the following in mind:

• Maybe let the user choose where to position this in relation to the Carousel.
• How to style the timeline.
• How the timeline should handle uneven scrolling positions (show 4, scroll 3, total 8). May just show the current page based on the original breakdown, and if there are more items on the screen from that fraction of the total items.

Button styles, background colors, etc. should be additional options that the user has the ability to configure from the Carousel constructor.

Currently, the implementation for multiple carousels involves arrays of almost every required property. Rather than deal with this confusion, a single Carousel class should be created, that way each carousel can maintain its own state within a single object.

This issue also makes room for the resolution of #2, which will essentially serve as the constructor of the class.

One of the originally-planned resizing methods included the following:

• stretch-populate: This is like stretch-gap, except when there is enough space to add a carousel item, the carouselItemsVisible attribute can increase or decrease to add or remove items in the carousel.

This task should be its own issue, as opposed to being lumped in with #15. This task also seems to naturally follow from #16, since making the carousel too large or small will end up calling one of these methods to add or remove carousel items.

If the auto-scroll direction is not specified, for some reason, auto-scroll will not work when including an interval in the options.

Should implement a way of scrolling through the carousel without using the buttons, and instead dragging the entire carousel to the right or left. Should still only move the currentScrollBy amount.

With the resolution of #76, the documentation section can now begin to be populated with different section links. Should wait as long as possible before adding actual content to these pages to allow for changing the navigation styles across all pages.

Because 'gap' is not a supported property on iOS Safari, it means that items are slightly off in their positioning when a carousel of type stretch-gap is constructed. The easy fix is to require the latest version of iOS, but alternatively, margins or some other workaround may be implemented.

Rather than just having slides translate along the X-axis, it may be a good idea to introduce a few alternatives, such as a fade-in, that can be offered to the programmer.

A really cool idea for the project webpage is to have a freight train carousel at the very top, with some of the language's features included in little shipping boxes. In order to make this look right, need to find or create some simple SVGs for the engine as well as some freight cars to show the features.

When the user scrolls through the carousel, the DOM must be manipulated in a way where items from the front of the carousel are moved to the back and vice-versa in order to allow for the wrapping functionality.

Will need to base some of this implementation on #4 in the case that the user has fewer carousel items in their carousel than the number of visible items at a time.

As mentioned in #44 and #48:

• wrap-none: Once the carousel hits either of the two ends, scrolling will not be allowed to continue. This will take wrap-smart as a base, since it stops scrolling past the ends early. Once this end is reached, the canScroll flag can be set to false to prevent further navigation.
  • The beauty in this method is that pointer values don't need to be modified beyond how they are in wrap-smart.

Rather than restricting the user to a single scrollBy value, allow the user to pass an array in as this option. The program will then alternate between values in this array to determine the next scrollBy amount.

In order to prepare for the implementation of the timeline in #29 as well as the wrap-jump wrapping method in #53, some method for jumping to the desired page in the carousel should be created. Doing this before the issues mentioned above means that the process will be more streamlined.

In order for the carousel to be able to change size with the window, basic methods should be provided that allows a user to change most of the attributes of a carousel. This will require more than just reassigning object attributes: the carousel may need to be reinitialized if visibility amounts change.

First mentioned in #44 and #49, this makes more sense to keep in its own issue. Requires the completion of #52 beforehand, and will likely be done as a part of the 2.0.0 release milestone due to the amount required and the small amount that it really adds.

For responsiveness, a carousel should be able to resize appropriately according to its containing parent element. Below are a few of the resize methods that should be implemented, listed in their expected order of complexity:

• none: The size of the carousel is fixed according to the size of the elements.
• stretch: The carousel stretches horizontally. Only the height of each carousel item is changed in order to fill the entire width of the carousel.
• stretch-gap: The carousel stretches horizontally. The size of each carousel item is preserved, but the gap increases/decreases. The gap provided to the constructor, in this case, serves as the minimum gap between carousel items.
• stretch-scale: This is like stretch, except the original aspect ratio of the carousel items is preserved. This means that the height of the carousel changes.

The methods and attributes in the Carousel class could do with some better documentation in the form of comments.

Currently, adding and deleting carousel items creates a 'flashing' effect due to a new carousel being constructed. This only seems to occur with the resize mode of stretch-scale, since the height has to flex-shrink and grow again. Perhaps there is a way to avoid flex shrinking and growing when adding new items only with this resizing method.

Need to be careful not to mess with any other features while making this change. Specifically, changing the resizing method of a carousel requires these resizing functions to be called.

As briefly discussed in #41, the introduction of a carouselTotalWidth property seems appropriate. The user can just have items cut off if they do not fit within the carousel, rather than wanting a strict number of items to be shown at a time.

Rather than checking for the window to be resized to change the size of a carousel, the parent element of the carousel should be checked. This would cover cases where there are resizeable containers within the document that contain carousels.

This will likely be a large feature to implement, but I think it is an important one. A carousel should be able to progress just by the width of the next carousel item and allow for multiple different widths of carousel items. With this comes a whole slew of potential issues, including how to deal with preserving the number of carousel items that are visible when the width of each can vary.

Now that the carousel demo with the train seems to be working well, it may be time to begin thinking about the home page of the site. The hero section should feature the demo carousel with both automatic and manual scrolling features, potential resize methods, and wrap-smart.

Currently, the ID and class names are pretty generic and likely to be used by the client. To avoid any kind of namespace collision, these should either be documented or made very specific and unlikely to be used by a programmer.