fivium / jquery-tagger Goto Github PK

The suggestions drop down list should have a high z-index set to keep it on top of other elements possibly on the page.

Reads v3 but is actually v4 - might want to sort out with the next release.

Split out from #4...

If a tag is focussed and the user starts typing, we should consider what we want the behaviour to be. Currently nothing will happen. Potentially the focus could be placed back into the input textbox and the keypress(es) could be carried over.

Considerations - what should happen when:

• You start typing and you've focussed on (for example) the left-most tag.
• You have focus on a tag, start typing, but there is already text in the input field.

There is a script of mine which updates the original <select>, but I can find a way to update the tagger interface to reflect it.

I have tried something like (in the examples page)

$("select#sel3").val("item0").change()

If the underlying select element receives a focus event, this should be passed to the generated widget (i.e. the filter input). Currently nothing happens.

Whilst you can navigate through the expanded list of results using the up and down arrow keys on the keyboard it is only possible to do this one item at a time.

When pressing and holding either the up or down arrow key the user should be able to quickly navigate through the list rather than having to press the buttons repeatedly.

Currently we load suggestions in full - while the user waits - if there are up to 300 possible tags to choose from. If there are more than 300 possible tags, then suggestion list loading is performed asynchronously via a 300ms setTimeout. This has two downsides; the user has to wait and it's all very hardcoded, baked-in logic.

A better way to do this would be to always load the first 20 or 30 items, followed by a loading div in case the user ever reaches it by scrolling. We could then continue loading items asynchronously into the list and eventually remove the loading div.

If the user starts typing to filter, we should just cancel our processing at whatever point it got to.

When focus is placed outside of the tagger, or Esc (etc) is pressed to hide the menu, the suggestion filter (input inside the suggestion menu) is not cleared. This is a bit counter-intuitive as you can't see it any more and probably wouldn't expect the value to remain.

When pressing the backspace key to highlight an already selected entry there is no way of exiting this action without using either the mouse or following through with the delete.

If the user decides that they dont want to delete then it would be nice to be able to start typing again or press the right arrow key to deselect the entry and carry on. Currently you either have to delete the selected entry or click back in the text box.

A long tag name will overflow the widget bounds when selected. A long tag does however work fine in the search suggestions.

I receive the following error for various resources when browsing the gh-pages hosted examples:

Mixed Content: The page at 'https://fivium.github.io/jquery-tagger/examples.htm' was loaded
over HTTPS, but requested an insecure stylesheet 'http://code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css'.
This request has been blocked; the content must be served over HTTPS.

Any labels that previously referenced the underlying select field should focus the tagger widget when selected.
Could do this by modifying the for attribute of the label to point to the input of the tagger widget or see if there's an event we could override.

We are currently rebuilding the HTML for the suggestions list every time it's updated, which means (at minimum):

• sorting the list
• creating the HTML for every suggestion
• binding the event handlers for every suggestion
• dealing with hierarchy / existing selected tags

It seems like there are some decent performance gains to be had here - we could definitely look at at least caching the objects in memory so that we can re-insert them to the DOM faster. Another option is always leaving all suggestions in the DOM, but manipulating which are shown / not shown / not selectable.

The input box that the user types into allows for browser based autocompletion which gets in the way of the suggestions list. See attached image.

The code is a little bit clunky and should probably be refactored to be more robust.

A known issue with it is that when the drop-down menu is first displayed, the first item is focussed but does not look visibly focussed. This works on subsequent opens of the same drop-down menu.

In the drop-down, an ampersand renders correctly (i.e. using suggestion-display HTML fragments). When the tag is selected, the ampersand appears as "&" instead of "&".

In a single select if I start typing I get a list of autocomplete suggestions. I use the arrow key to move to an item and hit enter key. This does not select the highlighted item as you might expect and the suggestion list now empties.

There should be a way to specify that a selection must be made - i.e. the first value is selected by default and the remove button (the "X") is hidden.

In single-select mode, the widget should act more like the standard select element, in that if you click any part of it, the drop-down menu should be triggered.

As seen from the example below, hint icons are being displayed below the selector, even when there is plenty of room for it.

When the drop-down arrow is focussed, by keypress or click, pressing tab does not take you to the first item in the list.

Much like a regular combo box the keyboard 'home' and 'end' keys should be able to be pressed to jump to the top and bottom of the expanded list of results.

If you click on the drop-down arrow of a tagger operating in single select mode, then start typing, the list is not filtered (and likely the browser handles the keypresses as typing to search within the page).

This should be changed so that if the drop-down arrow is pressed and the user starts typing, focus is placed into the input field and the text is used to filter the menu as you would expect.

Add a right-aligned search icon.

It appears that the tagger widget determines if the "tag" can fit on the line but it doesn't seem to cater for the drop down arrow on the first line.

In the attached screenshot you can see that the "add_permission" item is small enough to fit if it weren't for the drop down arrow and instead is has been pushed down and causes a whitespace gap.

To assess whether changes made to address #38 and #39 are beneficial / find out which method is optimal, we will need some rudimentary performance metrics. I propose building a small page that automatically runs tests on tagger widgets with different amounts of data so that we have some idea of current performance and can tell if we're improving it or not.

As most of our time goes in either building the widget (because we need to know what values are selected) or building the suggestions list, I'm planning to start with those as the major focus and use the same configuration (a multi-select) with differing numbers of values.

With the new AJAX suggestion loading, only a successful response is handled: https://github.com/Fivium/jquery-tagger/blob/master/src/jquery.tagger.js#L518

There should be something to catch an error, console.log it and display an optional message as well