Hacker News Reader

Comment by egeozcan | Hacker News Reader

The problem is not just styling, but usability, the API, and even accessibility too.

Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ :

Usability is bad because I can't select multiple non-consecutive items by using just my mouse. It's very narrow by default, and doesn't allow me to resize.

API: Your typical HTMLInputElement.value doesn't give me all the selected values. I need to map the .selectedValues to their values, or innerText if no value exist. Horrific.

Accesibility: At least in Firefox, using ctrl+arrows to be able to focus on elements to select them do not render any focus targets. In Chrome, the contrast is not there.

Don't even get me even started with the date/time-picker.

View on HN

To be fair, multi selection is a disaster on any platform.

It is a hard concept that isn't completely solved by any of the standard GUI widgets.

There are problems even with the single selection (searching for an option in mobile, consistent contrast, copying selected value etc.).

Depending on the application, sometimes to fix such problems, you need to reimplement the component in js or you start won't fix'ing tickets.

So articles like this really underestimate the problems with the existing controls and the lack of some.

I would probably use a series of checkboxes for the same effect.

Hilariously, lots of good implementations on mobile. Long tap to start, checkbox next to each item that is then selected. Confirm button when done selecting.

I actually really dislike this.

I find that I often have half second hangups due to not remembering if in select mode or not.

Much prefer the "Hold shift/ctrl" model used often in file managers.

Parent is talking about mobile. And on Android it's working rather well I'd say. The only downside I see is that selecting longer spans (shift click) is not possible.

In the context of the parents comment I thought they were comparing that model to others where multi selct exists.

I don't think there is a much better model on mobile, except possibly adding a button to each item to select a longer span.

Browser requires very fine degree of dexterity, and has 0 discoverability.

Mobile ones often have a "start multi-select" button in the UI.

Neither is an amazing experience, but IMHO the mobile one is somewhat better.

There are Android apps where you can select two items in a list and then there's a button that selects all of the items between them, which is equivalent to a shift-click.

A separate multi-select control is just a bad idea from 1990s; it should be disused and forgotten. The proper way is a list of checkboxes. Checkboxes are easy to recognize, easy to style, and easy to navigate and operate.

Now make that a set of 200 checkboxes and see how practical it is compared to one combobox-style multi-select input.

200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable. The multi-select dropdown is additionally hard to check for the selections made.

An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative.

Another, larger alternative is the typical two-lists control, with selected items moved from the source list to the target list; this idiom was widely used in Windows since 1990s. It's not mobile-friendly though.

> 200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable.

Multi-select is okay there, apart from the problems I mentioned above: https://jsfiddle.net/z0Ltxh47/2/ . I can navigate to i19 with a few key strokes. Only if it were then possible to easily select a1...

> An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative

And we are back at implementing our custom controls again.

> And we are back at implementing our custom controls again.

Sadly, yes. Not everything was anticipated at the times of Netscape 2.

HTML5 added a number of native controls, like video players and calendars. I wish a better "native" multi-select alternative surfaced, too. OTOH I suppose that browsers are going to blur the line between "native" controls and web components and such.

I think there's an initiative to improve these... but I can't find it at the moment. Googling anything with "native" just turns up react-native crap.

> And we are back at implementing our custom controls again.

Are we? Why wouldn't we just push OS vendors to add "input box with pill-style auto-completion" as a native toolkit widget, and then have browsers expose it? The OS vendors have proven willing to add stuff like native OS date/time/number-picker widgets, so why not this one?

I like the pattern of drop downs where you can type to filter. But I've found there isn't great UI in that it's not super obvious you can type.

I was actually implementing exactly this today in Angular and went with a <mat-autocomplete>

https://v5.material.angular.io/components/autocomplete/overv...

An input box like SO's isn't discoverable though, it's not good for things that you "want but don't know exist yet"

You just need a fuzzy text filter at the top to hide the checkboxes you don't care about.

I think this thread just about proved how insufficient the available controls are.

Multiselect over a range of 200 arbitrary values isn't something that will ever be solved by a single control, so that's a complete straw man.

If you actually need to multi-select over 200 arbitrary values (you almost certainly don't), the best way to do it I've seen is a way to filter the displayed items, a "Select All" button for what's visible based on that filter, and maintaining the "checked" state through filter changes, allowing you to select anything matching multiple filters.

this problem was solved around 1986 by Norton Commander and one of the main reasons why two-panel file managers (FAR, mc, TotalCommander) are still in use.

When you decouple selection with cursor and make selection "permanent", so you can move around this list without fear to lose accumulated selection, you could pick needed elements one-by-one, sort list by any attributes to simplify selection, apply filters, etc.

Yep. When marking many files for selection the twin-pane file managers let your mind (and your stomach) rest easy. I sometimes use ranger with two or more tabs to similar effect.

There was/is a Tcl/TK twin-pane file manager I liked called FileRunner. It's showing it's age now and needs a rewrite -- not for beauty, which I'm not too concerned about, but for some glitches that have crept in with time and lack of maintenance. It seemed more mouse friendly than some other twin-pane FMs (or maybe it's just rose-tinted memory).

I'm using FAR in Windows (10 now) every day. I'm using it as my command-lime shell, really, never run cmd or powershell. For everything my console needs (and I'm using a lot of coretools/filetools in the form of mingw64).

I don't know how to live on Windows without it, it is first program I install, even earlier than alternative browser.

Usually with 200 or so values there is some categorization of values that exists - maybe it's counties in a state that can be divided into regions or songs by an artist that can be divided into album or period. Large multi-selects seem to necessitate a multi-step selection process where the user can drill down (All of this category, none of this one and some of this other one - specifically this, this, not this and that). I think it's feasible for such a tag proposal to make its way through various working groups but it'd be pretty opinionated and we'd likely end up dividing multi-select inputs into several different classes (which would probably be a good thing).

If your UI has 200 checkboxes displayed at once, in an ideal world you’re rethinking your requirements and redesigning the UI.

The only way to make a 200 item select box usable is to make it not a 200 item select box somehow.

By filtering to search, which is also a UI fraught with inaccesiblity if not very carefully designed. I think custom elements aren't the issue here really, it's the lazy implementations.

Think bigger even. In an ideal world, if you have that many options you might want to rethink the entire workflow. I understand in the real world that may not be an option, but it’s still probably the ideal state.

Multi-select is what you have in File Explorer. You can select multiple files and folders for copying or deletion or moving. It is not a disaster

The most robust solution is to individually toggle selected state on each item, and don't unselect all on a new click. Like a checkbox. Click once for selected, once to unselect, don't unselect all on any click.

A multi-select drop down is just solving the problem of a checkbox list being too long, or not what the designer wants it to look like. The most clear UI for this input type is a set of checkboxes in my opinion. Same for a single item select and radio buttons.

Drop downs have a lot of caveats, and unique compositions in the wild, so many of them are inaccesible and it's essentially just because someone wanted it to look pretty. I think that is bad software.

The js fiddle example works great on iOS. I didn’t realize mobile safari supported a multi-select sheet!

Yes it really is. And now imagine someone would instead use a custom multi-select, because their browser has a bad implementation. Actually the best example why custom form elements shouldn‘t be used.

You can still write one as an add-on for your browser and help others or use it as poc for a ticket to the browser vendor.

Even in desktop Firefox (on linux) I immediately tried to:

- Multi-select by Ctrl+clicking on other items I want selected. (works)

- Shift-click to expands the selection linearly from the focus (works)

- Select one item, then Shift+Up/Down arrows to expand the selection. (Works)

I bet a custom control would be missing most of that behaviour as well.

Mind you, those affordances are completely unknown to most users. I bet if you asked most users (even developers) how to select multiple items in that control, 9/10 would struggle. The input control doesn't make its affordances obvious at all.

So in all, I'm confused what the browser vendors expect people to do here. I'd love to use the built in controls. But as others have said, they're often ugly, they confuse people, their APIs are a mess and they're difficult to style.

How about some checkboxes and labels with the for attribute then?

Aren't we then back at the problem? Creating a drop down selectable list using checkboxes and labels?

...And then to make that drop down pretty, and the checkboxes look neat, we'll set their opacity to 0 and remove pointer events, use CSS to style the label and set a nice looking tick using the 'before' content, which changes when the checkbox is selected... And oh, there again!

Which becomes a nightmare to look at with no styling: https://jsfiddle.net/wdqjyvsu/

and then it gets complicated very quickly: https://jsfiddle.net/wdqjyvsu/1/

You also have still undiscovered problems: How to let people filter the options if you have lots of them (and don't say ctrl+f because it doesn't restrict the search within the element)? What about lazy-loading if you have lots and lots and lots of them?

Usability is not improved, it takes too much space now. API is even worse. Accessibility is improved contrast-wise but all the tabbing is not very friendly, and try using that with a screen-reader. It takes ages to make a selection.

No offense, but this feels like trying too hard to make the argument that a perfectly normal pattern is somehow too obtuse to be considered.

I'm guessing you're trying to argue that something like a pill autocompleter is more appropriate for specific use cases (e.g. the `to:` field in email clients). And sure, sometimes some controls are better suited than others depending on the use case, but that doesn't necessarily mean that it's impossible to implement similarly complex controls by leveraging standard controls as opposed to reinventing headless behaviors on top of div soup[0]

[0] https://codepen.io/lhorie/pen/xxPJpeB

Your implementation has a lot of accessibility problems AND requires javascript AND doesn't work on firefox mobile.

Also: Congratulations, we collectively proved the article wrong. It says, "The browser’s built-in controls are quite sufficient". Here we see that you usually can't "just use standard controls", and even when you do, you need a lot of JS on top to make them accessible, usable, nice to look at with an acceptable API.

> has a lot of accessibility problems AND requires javascript

I'm not sure what you're arguing for then, it feels like you're just hating for its own sake. Because obviously not using standard controls and auto-including aria attributes will require JS too. Turn off javascript and CSS as you're arguing for, and then come back with a proper working implementation and then let's talk :)

I'm arguing that you DO need custom controls. Did you read the thread?

Of course I did. You're the one going on about unstyled elements and whatnot?

The article is about subtle behaviors that come built into standard UI elements. My point is you can get those behaviors from leveraging these elements instead of literally writing custom code to handle a series of keypresses in a div-soup-based <select>-lookalike.

As far as I can tell, nobody here is arguing for things like no-JS no-CSS solutions. The point is that custom controls implemented on top of div soup are usually much heavier and worse in terms of subtle behavior support than custom controls implemented on top of standard form elements, in the same way that using a sledgehammer as a nail gun is likely to yields sub-optimal results, because details.

Ah, okay now I get the subtlety, I stand corrected.

I'd still argue that there are times that you do have to use completely custom controls, like the case with the date-pickers. Not only because you cannot style them, but they also have a lot of API constraints, and accessibility problems. Even the example in the article, the beloved text area, has a lot of constraints like it's quite cumbersome to get the selection coordinates and it's impossible to offer any highlighting, so welcome to the world of contenteditable!

I completely agree that we should try to compose the native UI controls instead of reinventing the wheel when possible (like the text-input for that date-picker modal).

Yeah I can see why people get torn on date pickers. This was especially egregious back when they weren't as well supported/implemented across different browsers. The problem with them, as some people alluded in some comments, is that often times when people reinvent that wheel, they do an objectively worse job at it.

Because of my bad experience with these poorly implemented controls in the wild, these days I quite appreciate the way the <input type="date"> inputs appear on mobile (i.e. it's a completely different UI than desktop that optimizes against fat fingering/tiny hit areas/etc). Certainly beats implementations that rely on trapping input events and rewriting `input.value` on a plain text input...

You can hide multiple checkboxes in a <details> if it gets to messy: https://jsfiddle.net/3mohuw7e/

<details> is pretty easy to style and shouldn’t be to complicated to add extra features like filter fields by search etc.

>I can't select multiple non-consecutive items by using just my mouse

Well you can with ctrl-click. A well hidden feature though.

> using just my mouse

Say what you will about ActiveX, but it allowed a much more native feel for web pages.

Native feel is not wanted (anymore). Branded appearance is.

(and I think this is unfortunate. I wish developers didn't attempt to replace my browser's perfectly fine-looking, accessible checkboxes by their own often ugly custom implementations for instance. And I'm not hating on web devs, I'm one of them)

XUL [1] seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been abandoned.

[1] https://en.wikipedia.org/wiki/XUL

I think both are wanted. People like it when they have the usability and familiarity of native widgets, but it’s nice when they also have theming and personality. A good example is TweetBot, which is a normal iOS app except it’s not, or OmniFocus which does things in a native way except everything is purple.

> XUL seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been abandoned.

Didn't XUL do roughly what React Native, and other similar frameworks, do today?

edit I see that XUL did its own rendering rather than using native widgets, but the overall goal seems about the same.

What is the problem exactly seems to work fine on Firefox mobile

Reply on news.ycombinator.com