[HN Gopher] Custom JavaScript controls can't capture the nuance ...
___________________________________________________________________
Custom JavaScript controls can't capture the nuance of form fields
(2021)
Author : nitsky
Score : 309 points
Date : 2022-02-24 14:12 UTC (8 hours ago)
(HTM) web link (drewdevault.com)
(TXT) w3m dump (drewdevault.com)
| gjvc wrote:
| The sooner we stop attempting to fool each other that DOM + CSS
| is a suitable model for composing user interfaces which were
| previously implemented as native apps, the sooner we will get
| past the web era and on to something better.
|
| (25 years later... still trying.)
| stereocodes wrote:
| LOL
| rhdunn wrote:
| The main issue here is that the listbox on a select control is
| _not_ part of the DOM+CSS model. If it was then there wouldn 't
| be as big a problem, as they could be styled and customized
| while still taking advantage of native functionality.
| olliej wrote:
| I think a real problem here is that people (especially English
| only) do not understand the actual complexity of most standard
| input controls. They really think it's just "type letters". The
| number of times I've seen people showing their "fully functional"
| editors that flat out do not work with IM[E]s, do not handle
| basic keyboard controls, do not handle pasting or search propErly
| never ceases to amaze me.
|
| That's before consider breaking all the password or address auto
| fills, screen readers, non-keyboard text entry.
|
| Even if all you're doing is "restyling" controls, how do you
| interact with people who have vision difficulties like colour
| blindness? You're restyling overrides accessibility features that
| make controls visible.
|
| Seriously, you don't get to say "web apps should be just as
| capable as normal apps", and also say "I should break basic app
| functionality"
| awinter-py wrote:
| google docs reimplemented their whole UX in canvas, and this is a
| giant company that _controls browser standards_ as much as anyone
| does. can 't think of a louder way to admit defeat re advanced
| text entry on the web
|
| I wonder about unbundling the different pieces of the browser.
| Sandboxing + safe-ish remotely-managed code is really cool. Zero-
| install apps is cool-ish, but comes with slow loading (try
| opening a new tab in gmail on my poor linux firefox).
|
| But for UX things are tricky. The DOM is somehow simultaneously
| the best widgets library and a horrible widgets library. CSS
| isn't quite powerful enough, hence all the scroll jank tricks
| many sites are still doing, hence the difficulty of mixing
| classes and getting sane results.
|
| I'd want a browser-like execution context, but with something
| more like JSX than the DOM, pluggable layout engines with the
| default one more like modern constraints languages than CSS, SPA-
| aware RPC primitives, and more attention paid to the
| customizability of text entry and scroll.
|
| Electron IDEs are simultaneously great (so powerful and
| customizable) and really bad (built on the worst text entry tech
| you could pick).
|
| the author is 99% right about the difficult of interacting with
| custom controls, possible exception of companies like shopify and
| stripe that have put _massive_ investment into getting this stuff
| to work cross-platform.
| danschumann wrote:
| "The most efficient system is no system" -Elon Musk
| peterjmag wrote:
| _Double clicking selects a word, and triple-clicking selects the
| whole line. If I double- or triple-click-and-hold, I can drag the
| mouse to expand the selection word-wise or line-wise, not just
| character-wise. This works with the paragraphs of text in the
| body of this blog post, too._
|
| I had no idea that you could end with a drag to expand your
| selection by word or by line like that. That's really cool. (The
| author's using Linux, but it works on macOS too.)
| reportgunner wrote:
| Works on my Win10 machine too.
| godot wrote:
| This thread just makes me think of the thankless job of
| native frontend developers working on Linux/macOS/Windows
| OSes that made these nuances and behaviors work exactly to a
| specific standard. Ok, maybe not thankless in the case of Mac
| and Windows since they probably got paid. :) But yeah, I
| imagine all the edge cases aren't easy to handle.
| grishka wrote:
| Yes. Very much this.
|
| Another example: default macOS dropdowns allow you to click and
| drag while holding the button to select something in one single
| gesture. Default <select> implementation in Chrome/Vivaldi also
| supports it. None of the custom JS ones support it.
|
| The menu that opens from a <select> extends outside of the
| browser viewport which makes it easier to choose from long lists.
|
| Anything that opens a custom popup menu, including a dropdown,
| can only close it when you click within the browser viewport, for
| obvious reasons. System popup menus (NSMenu I think?) are kinda
| system-modal in that you can close them by clicking anywhere on
| screen, which is more convenient.
| frosted-flakes wrote:
| Your last point is not true. You can set custom dropdowns to
| close on loss of focus, which will happen when clicking outside
| of the browser window. It makes debugging with the browaer
| tools a right pain in the neck, but it's totally possible.
| grishka wrote:
| Yes but then that click would still go through to wherever
| you clicked and activate some other window. System menus
| consume that click.
| frosted-flakes wrote:
| Not on Windows, with the exception of the Ribbon control in
| the File Explorer and Microsoft Office.
| [deleted]
| blacklion wrote:
| It is why I hate Electron apps which disguise themselves as
| native ones.
| stereocodes wrote:
| As I type into a regular textarea on this site I'm wondering
| where these textarea replacements on websites are? I'd love for a
| few examples of this happening. "Many" JS programmers recreate
| the textarea? Show me.
| msoad wrote:
| It's such a blanket statement to say "you can't". Those controls
| themselves are coded up mostly using JavaScript so it is
| defiantly possible. It just requires a lot of work.
|
| The most accessible component library that I've seen is Adobe
| Spectrum React[1] which supports all of those nuances mentioned
| here for all of their controls and allow for styling and
| customization.
|
| [1] https://react-spectrum.adobe.com/react-spectrum/index.html
| lol768 wrote:
| > supports all of those nuances mentioned here for all of their
| controls and allow for styling and customization
|
| I don't believe it.
|
| Just tried the picker https://react-spectrum.adobe.com/react-
| spectrum/Picker.html and within 30 seconds you can find
| divergences from the browser's behaviour.
|
| The invisible input field behaviour Drew mentions in the
| article doesn't work. If I hit backspace, my browser doesn't
| know I'm in an input field and (correctly) navigates me to the
| previous page.
|
| In Firefox, if I use tab I can select my native <select> and it
| gets focus styling - not so with Adobe Spectrum React's
| equivalent control. Once I have focus, I can start typing to
| select items without opening the dropdown list. Typing whilst
| I've tabbed on to the React control does nothing. With the
| native control I can hit space to open up the menu and view the
| items once I have focus. With the React control, hitting space
| does nothing.
|
| I also looked at elements like the switch and checkboxes. With
| native components I can click in the empty space before a form
| control and be confident that the next <Tab> press I perform
| will focus the control for me. This behaviour doesn't work with
| Adobe Spectrum React's equivalent control's - I end up tabbing
| straight over the components altogether.
|
| > It's such a blanket statement to say "you can't".
|
| It's a blanket statement, sure, but in my experience it's
| absolutely true and I don't know why it's _always_ frontend JS
| developers who are arrogant enough to think they can reinvent
| decades of work on e.g. Gtk in their crappy UI controls library
| but it 's quite tiresome. Spoiler alert: you can't and won't,
| stop trying.
| phh wrote:
| > Just tried the picker https://react-
| spectrum.adobe.com/react-spectrum/Picker.html and within 30
| seconds you can find divergences from the browser's
| behaviour.
|
| Took me exactly three key presses. I navigate using vimium. I
| just don't know how to pick anything on vimium without my
| mouse on this, while standard select work just fine.
| mattwad wrote:
| Nor should we want to! I have spent a week trying just to
| make my forms screen-reader-friendly and it is very hard,
| especially if you're using a library already to build the
| components. But the reason I know it won't work is that all
| my changes look like weird hacks and are bound to be
| immediately broken by the next person to work on them that's
| not using a screenreader.
| nedt wrote:
| Also the picker is broken on iOS. If the bottom navigation
| bar is hidden the backdrop doesn't cover the whole page,
| which is ugly. More ugly then just a standard select element.
| Selecting by swiping over the elements doesn't work. And
| sometimes an accidental swipe and tap jumps to the top of the
| page. If Adobe can't support iPhone for everyone with less
| people power is better off using the existing form elements.
| jakelazaroff wrote:
| _> In Firefox, if I use tab I can select my native <select>
| and it gets focus styling - not so with Adobe Spectrum
| React's equivalent control. Once I have focus, I can start
| typing to select items without opening the dropdown list.
| Typing whilst I've tabbed on to the React control does
| nothing. With the native control I can hit space to open up
| the menu and view the items once I have focus. With the React
| control, hitting space does nothing._
|
| I just tried the link (in Firefox) and all of these work
| correctly.
|
| _> I also looked at elements like the switch and checkboxes.
| With native components I can click in the empty space before
| a form control and be confident that the next <Tab> press I
| perform will focus the control for me. This behaviour doesn't
| work with Adobe Spectrum React's equivalent control's - I end
| up tabbing straight over the components altogether._
|
| What do you mean, "click in the empty space before a form
| control"?
| stereocodes wrote:
| in both examples where you claim this doesn't work it worked
| for me. clicking on an empty space next to the form element
| and hitting tab focused correctly for me. Also tabbing then
| starting to type worked as well. I tested in FF and Chrome.
| Are you sure the options exist in the select box when you
| type? That would make it seem like type completion doesn't
| work. I Tried the checkbox and radio buttons example in FF
| and Chrome both auto select the field and using arrow keys to
| make options selected worked just like native. I think the
| error is somewhere between keyboard and chair.
| Vinnl wrote:
| This is such a fantastic library. Gave me a far better shot at
| making my work accessible than I'd otherwise have.
| lkxijlewlf wrote:
| > ... defiantly possible
|
| In a lot of cases, yes.
| badsectoracula wrote:
| I think the real issue here isn't if JS control can or cannot
| (they certainly can) but that even if they can, they still wont
| behave like the native controls because the native controls
| depend on the native platform.
|
| E.g. imagine if someone is using a modified Gtk library that
| uses vi-like shortcuts/modes for multiline text areas. This
| wont work on custom JS controls. Or something more likely,
| someone using macOS which, AFAIK, has text edit controls that
| understand some Emacs-like shortcuts. Even if you sniff their
| OS from the user-agent or whatever and use macOS-like keys, the
| user still wont get the text functionality exposes via, e.g.
| the Services menu.
|
| Of course at the end of the day you may not care about such
| details - or care but you consider other things more important
| or have other concerns/limitations for the entire underlying
| system.
| tuyiown wrote:
| The nuances should be exposed in a stylable, implementable and a
| documented API, with examples and guidelines.
|
| I don't understand why accessibility promoters endlessly bash
| developers, while the problem is that the edge between visual
| requirements and proper accessibility is extremely hard to dance,
| whereas it's mostly a non issue on proper platforms (eg.
| Cocoa/SwiftUI)
| robin_reala wrote:
| But... that's when as a developer you push back. Visual
| requirements don't take the place of accessible components in
| countries where there's a legal requirement for accessibility,
| which includes most of north america.
| lucasmullens wrote:
| > there's a legal requirement for accessibility
|
| In the US I'm fairly sure there's only a requirement for
| accessibility if you're building something for the
| government. I'm certainly allowed to build a website that
| isn't accessible and not have it taken down.
|
| Edit: Guess there's precedent to require some businesses to
| do it as well. Looks like I'm mostly wrong here.
| robin_reala wrote:
| You're required under the ADA to make "reasonable
| accommodations" for people with disabilities. This has been
| tested numerous times in court, most recently against
| Dominos:
| https://blog.ericgoldman.org/archives/2021/06/domino-
| pizzas-...
| gbear605 wrote:
| Judges have found that retail websites are subject to the
| ADA[1], and sites for things like utilities definitely are.
| Your personal website does not need to comply though, since
| it's not considered a public space.
|
| [1]: https://myblindspot.org/2017/09/retail-websites-are-
| public-a...
| kmeisthax wrote:
| In some cases the visual requirements are _also_
| accessibility-related.
|
| For example, <select> will give you a drop-down that lets you
| type to pick, but _only_ the first letter, and _only_ letters
| that directly correspond with a keycode. So you can 't type
| "Uni" to get "United States of America"; you can't type
| "toukiyou" plus enter to get "Dong Jing ", and so on. If you
| need to support IMEs or picking through large option sets,
| dropdowns are a bad option.
|
| Of course, native UI developers know that you can use a
| combobox instead of a dropdown picker; but there's no
| <combobox> tag. You have to implement your own by attaching a
| bunch of div/event soup to an <input type=text>[0]. In this
| particular case, doing so will actually make the input _more_
| accessible, because keyboard users can just type the answer
| instead of having to press the first letter and hit down 200
| times to get to the thing they want. It 's also more
| internationalized, because you can use your IME to compose
| the characters you need to search through the list with.
|
| [0] The select2 library will do this for you and it's my go-
| to if I need a combobox.
| robin_reala wrote:
| Oh, 100%, if your designer is extending components with a
| mind for greater usability and accessibility then that's
| perfect. There's a reason ARIA exists after all.
| montroser wrote:
| For text inputs and select dropdowns, yes, we take them for
| granted because the simple case is simple -- but there really is
| _so much_ complexity in keyboard navigation and interaction.
| Reaching parity in a JS implementation would be a serious
| undertaking and would usually not be the right thing to do.
|
| However, there are some controls, like date and color inputs,
| whose browser implementations are both inconsistent and severely
| UX-challenged such that no professional web site/app would really
| be able to use them in production. For these, in 2022, we still
| have no choice but to build custom implementations in order to
| meet usually expectations.
| Karellen wrote:
| A native date input might be inconsistent between different
| browsers, or different OSs, but it will be consistent with the
| native date input on _every single other website_ the user goes
| to. If they 're lucky, it will be consistent with the date
| input field on every other application on their OS.
|
| The only intuitive interface is the nipple. Everything else is
| learned. If the user has leaned how to use the native date
| picker on their browser, they know how to use the date picker
| on your website.
|
| If you make them learn how to use a new date picker for your
| website, it's very unlikely they'll thank you for being able to
| transfer this unique knowledge to that one website of yours on
| the very unlikely chance they choose to switch browsers. I
| mean, who does that regularly?
|
| And if the native date picker in their browser doesn't work for
| them - maybe because aesthetics, maybe because accessibility -
| they can either pick a different theme for their browser, or
| pick a different browser. (Or a different OS!) That has the
| advantage of fixing the native date picker on every single
| website they go to. Except for the annoying websites which
| implement their own, where if the custom date picker doesn't
| work for them, they're fucked.
|
| If someone's using a browser with an date picker you happen to
| dislike, that's their choice. Let them have it.
| 9dev wrote:
| This is a strange take: Native date pickers are broken in
| every mainstream browser, which is what the majority of our
| users use. People don't consciously "choose" browsers. They
| use whatever was preinstalled or someone recommended them ten
| years ago.
|
| Our customers don't care about other browsers, Open Source
| software, or the nuance of native input fields. "Look, on
| AirBnb I can enter dates in a humane way, why is it so hard
| on your website?" - I just don't get away with recommending
| them to switch browsers.
|
| Having accepted that premise, we can talk about the custom
| implementations: I would never recommend rolling your own,
| either. There are several widely used library for date
| pickers that users are accustomed to, are accessible, and
| miles ahead of the native controls. There is absolutely
| nothing wrong with sticking to those libraries until the
| vendors finally fix their mess.
| kmeisthax wrote:
| The funny thing is that, at least on Windows[0], there
| actually isn't a standard color picker. Or, well, there _is_
| , but it's one of those common-controls dialogs that hasn't
| gotten a UI refresh since Windows 3. People writing native
| apps that need to pick colors wind up writing their own color
| pickers[1]. Even Microsoft does this: Paint gives you the
| same obsolete system color picker I mentioned before, but
| Paint 3D ships with it's own[2].
|
| If you ask a browser on Windows for a color picker, you get
| the old-and-busted one. Given the odd bifurcation in Windows
| UI since 8, I suspect date pickers are the same way, and the
| one the browser gives you won't actually match what other
| native apps are doing. So what happens if you decide to do
| the "right thing", is that you get a demonstrably worse user
| experience for your forms for the vast majority of people who
| do not know how to retheme native UI and have zero
| familiarity with the old Windows controls that browsers
| continue to throw at people.
|
| [0] macOS has a native color picker that is apparently so
| good that someone reimplemented it for iPadOS.
|
| [1] Adobe isn't even consistent among their own suite. The
| Photoshop color picker is entirely different from the
| Premiere or Animate ones, for example.
|
| [2] I suspect the Paint 3D color picker _may_ be a XAML
| default, but up until very recently the prospects of actually
| using XAML in most apps was very dim. More specifically, XAML
| used to be either exclusive to .NET /C#, or exclusive to
| Microsoft Store apps, neither of which were conducive to
| native software that need to live outside of an app container
| sandbox and be distributed through Steam.
| dmitriid wrote:
| > And if the native date picker in their browser doesn't work
| for them - maybe because aesthetics, maybe because
| accessibility - they can either pick a different theme for
| their browser, or pick a different browser.
|
| Or, you know, if aesthetics or _accessibility_ doesn 't work
| with a native picker I might just use a third-party one
| instead of requiring my users to switch browsers and OSes.
|
| Native date input have horrendously/hillariously bad
| implementations in _all_ desktop browsers. I can 't even
| begin to imagine thinking about using them for anything.
| Karellen wrote:
| Someone with particular accessibility needs might not be
| using a popular desktop browser - they'll already be using
| a user-agent which is adapted to their own needs.
|
| If you use native input elements, then whatever
| accessibility needs a user might have can be accommodated
| by a user-agent which caters to those needs. And you get
| that to take advantage of that for free.
|
| If you roll your own, you can't cater to people with
| disabilities that you haven't considered.
| dmitriid wrote:
| > Someone with particular accessibility needs
|
| Accessibility is not black and white. I have good vision,
| and native date pickers as implemented in _all_ desktop
| browsers, are so tiny, I have to zoom the page every time
| I encounetr them.
|
| > If you roll your own, you can't cater to people with
| disabilities that you haven't considered.
|
| True, but you out of hand dismissed huge swaths of people
| who are not using "adapted user-aganets" but still suffer
| because browsers have a shitty native implementation.
| julianlam wrote:
| I don't understand this sentiment. Why would it matter whether
| the UX is different between browsers for a date or colour
| input?
|
| In the end, if it inserts a date, or a hex colour
| representation, then I am happy.
|
| Although now that I think about it, there's a chance a date
| input would return `mm-dd-yyyy` or `dd-mm-yyyy` depending on
| locale. To have it return a unix datetime would probably be
| easier for everybody.
| p49k wrote:
| > I don't understand this sentiment. Why would it matter
| whether the UX is different between browsers for a date or
| colour input?
|
| It's not just a question of consistency: some of HTML UI
| elements are still in pre-alpha stage in modern browsers,
| almost completely broken, despite being part of the standard
| for many years. It's a joke.
|
| For an example, check out the RANGE element; you will find no
| shortage of articles complaining about how ridiculously
| broken and unusable it is.
| 9dev wrote:
| Tangent: I wonder why, after having standards like ISO 8601
| for decades, stuff like this is something we even have to
| think about. On a technical level, there's a need for exactly
| two date time formats: Monotonically increasing integer
| timestamps, and ISO 8601 style date time with timezones.
| grenoire wrote:
| The browser date pickers will always return YYYY-MM-DD to
| your server when they send a request. What's exposed to the
| user is usually localised. This is the behaviour you want.
| obpe wrote:
| I have implemented many custom form controls. The reason is
| almost always because the design requires it. But other reasons
| can be to "improve" the control; for the select box to make the
| invisible edit buffer visible. I appreciate this is not the way
| but it is also pretty annoying how limited the styling, and
| customization, of form controls is.
|
| We use Angular so it's pretty easy to hide the custom control and
| have a plain control for accessibility. At least for checkbox and
| radio inputs, am I the only one that uses a hidden input to
| control the style of some div to make it look fancy like the
| design required?
| grishka wrote:
| If a designer wants me to do a custom control, I usually
| explain them why it's a bad idea and instead style the standard
| one.
| Klaster_1 wrote:
| The UI designers I had worked with do not have much experience
| working with the web platform as a user or developer, are not
| aware of capabilities default controls provide and almost never
| use the products they've designed. Additional exposure of UI
| compared to under-the-hood stuff begs for additional
| bikeshedding and micromanagement by people who understand this
| even less, like management. Maybe I never met good a designer
| or worked in a company with sane process.
| ryukoposting wrote:
| In my (very limited) experience, the "hidden input" approach
| seems to be a reasonable approach. All the w3schools guides
| I've followed seem to do it that way.
|
| disclaimer: 95% of my "modern" web frontend experience consists
| of non-professional goofing off in Svelte.
| enlyth wrote:
| Sadly this is the "right" way, and as many other commenters
| in this thread have pointed out, the sad state of default
| browser components is to blame.
| bradstewart wrote:
| By far the most annoying thing to me (as a user who does not rely
| on accessibility features) is how few JS-built forms support
| TABing through the fields, in the correct order. It's
| infuriating.
| asddubs wrote:
| I wish more development went into form widgets. A big thing is
| also that they're accessible and responsive by default.
|
| One that I would love would be some sort of drag and drop
| reorderable list, for example.
| rjknight wrote:
| This is true, but the set of custom controls is quite small.
| Controls that were built-in to, say, Visual Basic 4.0 in 1995 are
| not present in today's web browsers.
|
| Re-implementing built-in controls (the example of a <select> box
| is given in the OP) is obviously a very bad idea in almost all
| circumstances. Implementing a missing control is a much more
| difficult decision, and there are times when it can be a
| defensible choice to do so.
| specialist wrote:
| Emphatic agreement.
|
| Today, even apparently trivial widgets require ridiculous amounts
| of effort to attain a "natural" UX. To become so good you don't
| notice. That holy grail of being "invisible".
|
| --
|
| Epochs ago, I created custom controls for Win32. The one I was
| most proud of was a direct manipulation sundial picker for a
| raytracer. I obsessed over the details. Like being pixel perfect,
| both mouse and arrow keys (for fine grained increments), live
| updates between dial widget and text fields. Damn, I was proud of
| that control. I flushed and preened whenever a user complimented
| the effort.
|
| Ages ago, I started using bootstrap-select. It's a nifty dropdown
| w/ type ahead (search). Modest, no big deal, right? Nope! That
| project received so many PRs, tweaks, fit & finish, finesse, and
| all around TLC. I was transfixed, fascinated. I haven't done UI
| for years, but remained subscribed to their project
| announcements, mostly out of awe and respect.
|
| https://github.com/snapappointments/bootstrap-select
|
| Observing the bootstrap-select project over time humbled me. I
| used to think I had some UX juice. Now I know that I'm just
| banging the rocks together.
| timwis wrote:
| > The browser's built-in controls are quite sufficient.
|
| What do you recommend for a typeahead/autocomplete? In my case
| I'm using a third party API for results (geocoding), but even
| with a static list, the closest option is datalist, which is very
| limited
| aarondf wrote:
| A big part of the reason that JavaScript controls can't capture
| the nuance is because it takes _a lot of work_ to capture the
| nuance. So teams justifiably implement the 90% use case and move
| on.
|
| There are projects that dedicate an unreasonable amount of
| resources to making these controls in JavaScript and show just
| how far you can get in JS. For example, https://headlessui.dev.
|
| EDIT:
|
| To directly address the "invisible buffer" thing, look at this
| control from Headless UI: https://headlessui.dev/react/listbox.
|
| Open it, start typing, and notice the invisible buffer actually
| does work here.
| stuartloxton wrote:
| The "invisible buffer" doesn't match OS X functionality (with
| Firefox if it matters).
|
| In the state dropdown of the article I can type "New J" to
| highlight "New Jersey" and then press backspace + "Y" and it
| will highlight "New York". In the headless UI version if I try
| similar "To" to get "Tom..." but if I press backspace and "a" I
| don't get "Tanya..." I get "Arlene..."
| mrob wrote:
| On Firefox on Linux, I get a different incorrect behavior.
| "To" + backspace + "a" (fast enough that it doesn't trigger
| the timeout for starting a new search) remains on "Tom...".
| marcellus23 wrote:
| Also, it doesn't let you type-to-select when the box is
| focused but the dropdown is not expanded.
| hbn wrote:
| I just tried this with a native <select> in Safari, Chrome,
| and Firefox and they all worked like the Headless UI version,
| where a single backspace clears your entire buffer.
| Cthulhu_ wrote:
| But... why not style the built-in controls?
|
| I mean in addition to this keyboard UX, there's accessibility
| to consider; screen/braille readers, alternative input methods,
| etc.
| mhink wrote:
| Because in a lot of cases, browsers don't expose the
| necessary APIs to do so. That being said, most component
| libraries I've seen that implement custom controls (which
| _do_ expose APIs to allow styling) will make a point of
| adding all the necessary ARIA attributes to make controls
| properly accessible.
| simion314 wrote:
| >But... why not style the built-in controls?
|
| As devs we don't decide, we get soem designs, like make a
| numeric input that looks like in this picture, make a select
| that can show a different icon for each option()like a
| language select with flag icons)), or make a font select that
| each item has it;s own font family.
|
| Then you have stuff that are clasic things in normal GUI
| toolkits like accordions, tree views, very efficient
| grid/list views(I mean a widget where you can load 10K items
| and not have to implement your own smart loading or the lazy
| pagination way).
|
| I did not done too much mobile but I remember there are some
| "tabbed/stacked views" , you can put your components in this
| views and would be efficiently loaded and unloaded when you
| moved from one view to other making things start faster and
| use less memory.
|
| Not sure why the browser makers ignore this stuff, did they
| give up and we just have to use third party libraries for
| simple things like a good select and a working GridView?
| aarondf wrote:
| I mean... you have to know that styling the default controls
| usually falls _vastly_ short of what you 're trying to do.
| LinAGKar wrote:
| Same with links, for example when someone makes a JavaScript link
| and breaks the middle click to open in new tab
| nick238 wrote:
| It's suuuper annoying when the type-to-pick-dropdown doesn't
| work. Mildly annoying for US states, I live in Illinois, so when
| it flashes "Idaho", "Louisiana", oh boy. These are usually the
| forms that then have a 'fake' dropdown for credit card expiration
| dates, so I can't type-to-pick the month/year either.
| mmis1000 wrote:
| As a chinese user, I don't know this function until now.
|
| Character in chinese requires multi keystroke. And the IME
| won't be even triggered when you are not focusing a text field,
| render the whole function useless.
|
| So, a common pattern here is "use combobox instead". Because
| combobox has a working input field build-in, make it usable
| with chinese.
|
| But.... the HTML don't have combobox build-in, so you end up
| get one in literally any ui framework or a handwritten one if
| you really don't want to use framework.
| thfuran wrote:
| As long as it's not one of the sites that truncates passwords
| differently at signup and at login, I can probably manage.
| grishka wrote:
| Bonus points for when the month is the _name_ of the month.
| vsareto wrote:
| Numbers vs. names for months is a legit casus belli
| Aachen wrote:
| Spotify custom implemented this for their desktop client. You
| could right click on a song, open the submenu "add to
| playlist", and type a few characters. Idk why they bothered
| custom implementing that when a select list is a standard
| element no matter what framework they use, but I was happy.
| Then cometh the update and the feature be regressed. I now need
| to use the mouse for literally everything, including looking
| through this list with no discernable sorting (it's not
| alphabetical). Only spacebar for play/pause survived, all other
| keyboard controls seem gone or I can't guess them.
|
| Just use normal components. Save the effort, help the screen
| reader, please the power user. Please.
| marcellus23 wrote:
| Ugh, Slack too. For ages they didn't have right-click menus
| anywhere. Then a while ago, they added right-click menus to
| channels, but of course they couldn't just use the native
| menus that every OS already has, so it's some HTML
| abomination that had to rewrite the wheel for handling things
| like lenient mouse movement (e.g. https://css-
| tricks.com/dropdown-menus-with-more-forgiving-mo...). Still
| doesn't support type-to-select, or god knows how many other
| accessibility and power user niceties.
| easrng wrote:
| I don't know if Electron has an API for menus, but the HTML
| elements that let you add items to the native contextmenu
| were scrapped, and every browser I know of renders their
| own menus on Windows/Linux anyway. There is not a way to
| add a native contextmenu unless you do something cursed
| like positioning an invisible <select> where the mouse is
| and opening it on right click.
|
| Edit: Never mind, there is no way to open a <select> with
| JS.
| marcellus23 wrote:
| I know, but other Electron apps manage to do it (VS Code,
| Postman), so there must be a way.
|
| edit: some quick googling reveals there is an API for
| this
| https://www.electronjs.org/docs/latest/api/menu#class-
| menu
| stereocodes wrote:
| what does this have to do with form fields? edit: I see you
| think that context menus are form fields. Thats incorrect.
| marcellus23 wrote:
| It's not about form fields, it's about type-to-select. No
| one said anything about context menus being the same as
| form fields.
| Phelinofist wrote:
| You could organize your playlist in folders. Not a solution
| but that might make it bearable :P
| sandruso wrote:
| I just figured out one thing: when delay between keystrokes is
| < 100ms or less the search through options works and it will
| highlight Illinois. (Chrome)
| diegof79 wrote:
| I agree with the author that custom components don't capture all
| the interaction details. Many times they are not accessible or
| cannot implement cross-platform input well.
|
| However, I disagree with:
|
| > The browser's built-in controls are quite sufficient.
|
| The problem is that browser components are good for simple forms
| but insufficient for other types of interaction.
|
| A good example is select. Using the select tag is the best way to
| have a dropdown list that's accessible and supports mobile. But,
| select doesn't cover most of the cases that you need for a
| complex app.
|
| Many of the WAI ARIA authoring examples (including the combobox
| patterns) are not covered by built in components. Interaction
| patterns like pop ups, dialogs, or lookup lists are quite common
| for an app... but hard to do in an accessible/cross-platform way.
|
| Web browsers need to do something different to support
| accessible/usable apps. The idea of leaving all those things to
| WebComponents makes sense, but the result is reinventing the
| broken wheel on each app.
| nedt wrote:
| Oh the combobox element in the WAI ARIA is interesting. On
| mobile the dropdown can't be scrolled without scrolling the
| page (and the user losing where they were in the form). Also
| the tap targets are smaller.
|
| And there even is a combobox in HTML5. It's an input with a
| list attribute.
| extra88 wrote:
| Do you mean <datalist>? It doesn't meet all use cases
| (especially if what needs to be listed requires dynamic
| updating) but browser support slowly has gotten better.
|
| Unfortunately, I recently heard that all the major browsers
| fail to resize the datalist text on zoom (my guess is it's
| rendered outside the DOM, like the browser's UI).
|
| Bug report for Firefox:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
| mattlondon wrote:
| Yep I totally agree with this.
|
| There are however a bunch of ARIA tags & best practices etc
| (https://w3c.github.io/aria-practices/) that exist to make
| popups and dialogs (and other things e.g. tree views or "email-
| inbox-style" "treegrids" etc) accessible (if implemented
| correctly).
|
| I am conflicted about these - it is nice that there are ARIA
| tags for this, but it would also be nice if browsers
| "understood" aria tags and added some default behaviors (e.g.
| keyboard navigation). As it is, ARIA tags are essentially
| "pointless" to anyone who doesn't use an assistive technology,
| and so non-assitive-technology users nor developers benefit
| from using ARIA tags so they are often forgotten. If the
| browsers saw that there was an A11y-tree that matched a
| treeview or a treegrid, it would be really really nice if they
| applied some default common keyboard navigation implementation,
| rather than do nothing and leave it up to the developer to
| decide what keys do what on each and every site. .... Or on the
| other hand, is that too prescriptive and should we give
| developers and UX designers more leeway to design something
| better, rather than rely on browser-enforced defaults? I guess
| we are happy with browser defaults for basic inputs, but would
| we be for a treegrid?
| extra88 wrote:
| The WAI-ARIA Authoring Practices are not _best_ practices,
| they are not carefully researched to ensure they can be
| successfully used in a variety of browsers or with a variety
| of assistive technologies. They include examples that don 't
| work properly with common browser/screen reader combinations
| (like Safari + VoiceOver). They'll use ARIA approaches even
| when they're not the only or best way to achieve a goal.
| They're best thought of as patterns designed to "exercise" a
| browser's support for ARIA attributes, browser developers can
| use them to test whether their implementation of ARIA support
| matches expectations.
|
| Nevertheless, some of them _are_ perfectly good solutions as-
| is and can serve as a good starting point.
|
| I would also like browsers to have more capabilities "baked
| in;" browsers should offer keyboard navigation of ARIA
| landmarks (both implicit ones created by <header>, <main>,
| <footer>, etc. and explicit `role` attributes). I don't like
| the idea of browsers automatically creating interactive
| controls based on the presence of ARIA attributes, I'd rather
| there be new HTML elements, ones that document stylability
| much better than old ones did.
|
| I'm interested in Open UI's [0] work, attempting to develop
| common web components, ones that can be useful in the short
| term and may serve as the basis for new HTML elements in the
| future. They're sort of documenting cow paths that HTML in
| the future can pave, similar to HTML5 elements being named
| based on common class names or useful additions to JavaScript
| having been based on features in libraries like jQuery
| (obviously without adopting jQuery's syntax).
|
| [0] https://open-ui.org/
| dmitriid wrote:
| Lots of people have been saying this for years, and accessibility
| voices are now being heard as well. It's extremely difficult to
| create a proper form control and remember all the usage patterns
| and all the edge cases.
|
| However, people want more than just the 6 or so controls defined
| in the 1990s. Even w3c in their design system relies on a third-
| party autocomplete: https://design-system.w3.org/third-party-
| plugins/
|
| The reason? Browser implementors rarely solve actual issues that
| are truly desired by most people. Because browser implementors
| are low-level C/C++ developers who rarely touch actual web
| development. So we get 41 distance units, and horrendously bad
| APIs like Service Workers and Custom Elements, and piles of
| things like Ambient light sensors [1]. But for all the hype and
| advertisement around web _applications_ we don 't really get
| things that actually make it easy to, you know, develop these
| applications. Google Docs is transitioning to canvas and Figma
| reimplemented half of the browser in WebGL not because web
| platform is so great.
|
| There's now the https://open-ui.org project that collects common
| UI patterns that have been endlessly re-implemented across
| countless frameworks and libs. It will be another 40 years before
| any of them become a reality.
|
| [1] Yes, it's a thing:
| https://chromestatus.com/feature/5298357018820608
| codeptualize wrote:
| This is not helpful imo. Although it correctly identifies a
| problem of badly implemented controls. The explanation and
| solution show a lack of knowledge and understanding about the
| topic and current situation.
|
| It's easy to say "use just the browser provided controls" until
| you actually have to build something that people need to use.
| What is expected today from even a simple form involves a lot of
| custom behavior that browsers do not provide, at what point is it
| "custom"? Advising against that will not help things become more
| usable nor accessible.
|
| Instead of "just don't do it", I suggest to promote caring about
| usability and accessibility, and make people realize it should be
| evaluated for each individual situation and give practical
| information on how to do that.
|
| Very basic practical advice; Use native elements where possible,
| if you run into their limitations preferably use an existing well
| build and maintained alternative that does implement all of the
| intricate details. Building something completely custom should be
| a last resort, if you do end up in that situation it's often
| beneficial to build it on top of something else.
| shadowgovt wrote:
| Agreed. I think about custom controls like I think about
| cryptography libraries: _most hackers_ aren 't specialized
| enough to have thought through all the corner cases and unless
| you want that to be your specialty, you're taking on a lot of
| risk of blowing your own leg off (metaphorically speaking)
| trying to hack out a solution instead of using something
| (ideally) well-maintained and with some history behind it.
|
| (Having had some experience working on custom controls in a
| browser: it's the kind of project that will occupy a three-
| person team at a Fortune-500 full-time over multiple quarters
| to get right. Set your expectations accordingly.)
| withinboredom wrote:
| I've used browser controls for the last 20 years on any form
| I've ever implemented. These days you get validation errors,
| accessibility, and so much more for free -- even if JavaScript
| is turned off. I can't think of a reason you'd ever want to use
| a custom control on a form.
| codeptualize wrote:
| How about a date range, search fields with dynamic
| autocomplete, rich content dropdown selects, combined multi
| selects, etc etc?
|
| As I said in my original comment; I agree that where possible
| normal input elements are preferred, but they do not cover
| all cases. I guess it depends on what you consider custom,
| most of those use html form elements underneath, but they
| definitely require implementing the intricate details as
| described in the article.
|
| I also don't think it's correct to say accessibility and
| usability come for free as long as you use plain html
| elements. You can build really horrible unusable forms with
| plain html elements, I've seen plenty (and I've probably
| build a few myself in the past haha).
|
| My point is; "don't use X" and "don't do Y" posts are not
| helpful as they do not convey the point that both usability
| and accessibility require effort and consideration, and give
| a false sense of "if you don't do this all will be great"
| which is not the case.
| woudsma wrote:
| > The browser's built-in controls are quite sufficient.
|
| Until you work on global webshop forms, where business/management
| wants hundreds of exceptions to the rules. Few examples: form
| input pre-fills, custom validation, auto-complete fields, fancy
| dropdowns, email/postcode checks that need to happen while
| filling in the form. I could go on. And it all should be
| manageable from some ancient CMS, of course.
| karaterobot wrote:
| > Making a custom form control with JavaScript is going to make
| life worse for a lot of people. Just don't do it. The browser's
| built-in controls are quite sufficient.
|
| An extremely common use case at the last two companies I've
| worked at is a multi-select dropdown with autosuggest.
| Optionally, new items can be added to the list. Sometimes we
| needed to use ajax to populate the list, because you were
| searching 25,000+ items. We used this control in 10-15 different
| places, usually inside a spreadsheet cell. Which built-in
| controls should I use for this? I agree with the author that it
| is difficult to implement.
| [deleted]
| Cthulhu_ wrote:
| I prefer to use built-in controls as much as possible, but they
| have their flaws and missing features. One of my pet peeves /
| gripes is the half or broken implementation of new HTML5 input
| fields, like number or calendar inputs. I haven't found working
| them at all delightful.
| svkurowski wrote:
| I was wondering about this, too.
|
| > Making a custom form control with JavaScript is going to make
| life worse for a lot of people. Just don't do it. The browser's
| built-in controls are quite sufficient.
|
| For my self-hosted minimal CRM (not really ready for anybody
| except me yet)
| [Aktenkoffer](https://github.com/svkurowski/aktenkoffer), I
| created a custom select that allows for filtering/searching of
| contacts when choosing sender/recipient for a given document. I
| don't use browser's select because:
|
| 1. There's a lot of contacts one has, and the list will become
| very long, a usecase for which select seems not to be the best
| fit, i.e. I don't want to load all the options always. 2. I
| cannot always remember how I formatted a contact name - e.g did I
| include the "Dr." at the beginning or not. Select quick-selection
| only works when I know exactly the sequence of characters I'm
| looking for (like the US state selection the author mentioned).
|
| Obviously it has tons of feature gaps, I.e. pressing Esc does not
| close it (yet), up-and-down arrows don't work (yet), one cannot
| just type to go to one option.
|
| Any suggestions, what to do in such a case? And how I can learn
| more about such approaches?
|
| I love sourcehut, and its design and I would like to follow a
| closer to the browser, minimal UI but in practice it seems quite
| hard for me - harder than getting a custom select "half-right".
| wffurr wrote:
| There's not a great built-in combobox control, which is a
| shame. An input type=list element with a datalist comes close:
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
| saint-loup wrote:
| Recent discovery: there's a native <datalist> element, well
| supported except for Firefox@Android. It's a combo of <select>
| and filtering (a combo box, to use the Windows parlance).
|
| https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...
| theandrewbailey wrote:
| The big downside is that datalist will only show exact
| matches of what you've put in. If you're doing a fuzzy search
| somewhere (or the user has a typo) and want to offer search
| suggestions, a native datalist doesn't work. I wish there was
| an attribute that forced all options to appear when filtering
| happens elsewhere and options are dynamic.
| eximius wrote:
| Can't or don't?
|
| Besides, I usually build controls out of input primitives, not
| pure JS.
| romaniv wrote:
| The best unit of isolation for web functionality is behaviors,
| not controls. Think of them as traits enabled and configured via
| attributes. I've used such things on many different projects with
| very good results. The main advantage is that if you design them
| properly it is trivial to extend built-in functionality without
| reinventing the flat tire.
| bavell wrote:
| Interesting, care to expand on behaviors vs controls?
| khepin wrote:
| Worst of those I encounter regularly is US sites trying to
| constrain your input to numbers only on certain fields. Not
| "letting you input anything and marking it invalid if you put
| something other than a number", but listening to which key is
| pressed to allow the typing or not. On French keyboards, typing a
| number requires the use of the SHIFT key. So I regularly need to
| change my keyboard layout just to type a couple numbers in a form
| field because someone thought they'd be smart...
| fuzzy2 wrote:
| Oh yeah I had that recently in a project (IE support required,
| so no type=number). When you try this, you will eventually find
| that you use so many keys during normal operation that a
| whitelist just isn't feasible. Left, right, tab, Home, End,
| Ctrl+C/V, Shift+Ins, ...
| padseeker wrote:
| This is an interesting comment but also an edge case. I build
| custom components all the time, such as a combo box that allows a
| user to select a list of options but also allows the user to type
| in a fragment and the options will be displayed filtered based on
| the text fragment typed. I would imagine your use case is a
| nightmare, but the average dev team and product manager is
| probably myopic and anglo-centric so they are more worried about
| the average latin language based user as opposed to your use
| case.
|
| I'm glad you are sharing this, its good to be aware of and I
| might share this with my own product team in the future.
| jaywalk wrote:
| Selects are the absolute worst when it comes to customization. I
| totally understand it from a design perspective, but I will
| always push back on it aside from customizing the box itself. The
| actual dropdown options? Sorry, they're going to look how they
| look.
| vsareto wrote:
| Me wishing every UI/UX person understood this.
|
| In fact, the more bells and whistles I find on the requirements
| for individual form inputs, the more annoying it is the work
| on.
|
| Simplicity is god for most of front-end.
| mihaic wrote:
| I'd actually put the blame here on browsers, and how limited the
| default inputs are.
|
| There are too many needlessly reimplemented components, but
| anyone that has ever needed to style a <select> to make it look
| in line with any modern design quickly reached desperation.
|
| I'd love to be able to use standard components everywhere, but
| most of my users care if my website looks like it's from 2004.
| K0nserv wrote:
| You don't have to style the select. If you are being forced to,
| your designers are either incompetent or ignorant. Aesthetics
| shouldn't trump usability
| aaronbasssett wrote:
| That's an unpleasant thing to say about the people running
| Hacker News.
|
| Take a look at the search page.
| K0nserv wrote:
| I think my statement is truthful, albeit harsh.
|
| I don't believe there are many designers who are interested
| in creating experiences with poor usability, thus my point
| about ignorance and not understanding the tradeoff they are
| making. On "incompetence", if a designer understands fully
| that they are creating something that will be less useable
| and accessible for the sake of aesthetics they have earned
| the label. To take the HN search page as an example, the
| filters can't be interacted with via keybord or screen
| reader. When it's your job to help users solve problems and
| you have made it knowingly harder to do that, I don't see
| how that's competent.
|
| Luckily, it has been my experience that in most
| cases(including my own) the former, rather than the latter,
| is at play.
| Uehreka wrote:
| By this logic, almost every designer is incompetent or
| ignorant. Styling form elements is not an extreme position,
| even if you might want it to be.
| scelerat wrote:
| Many designers I have worked with got into UI design from a
| graphic design/art/print background[1]. Many I have worked
| with had never read so much as a word from any OS
| platform's human interface guidelines and were, indeed,
| ignorant of HCI fundamentals.
|
| [1] graphic design is a completely legitimate field and a
| good way to get into UI design, but if that's all you've
| got, you still have quite a way to go
| K0nserv wrote:
| It's not that it isn't an extreme position, but I think you
| are right that many(most?) designers don't appreciate the
| usability tradeoffs they are requesting in doing so. Most
| designer I've had this discussion with have come around to
| not doing styling like this after having the tradeoffs
| explained to them.
| brimble wrote:
| Speaking of design trade-offs, I've found it's really
| hard to get stakeholders to appreciate the cost of
| implementing designs. Design cost _should_ be part of the
| trade-off give-and-take of figuring out what can fit in a
| release or sprint or whatever, but often all those
| decisions happen too early in the process to do that. It
| 's easy for one design decision to affect several
| "stories" and add tens of "points" (in typical agile
| terminology) to a project, and entirely possible that the
| stakeholders would rather have five more features than
| have that widget look and behave _just_ so. Most
| designers don 't seem to consider this much.
| nedt wrote:
| Have you ever seen a designer define all the different
| states with all the different input methods for a select
| element?
| closetohome wrote:
| > Aesthetics shouldn't trump usability
|
| It's true, and it really shouldn't be as controversial an
| opinion as it apparently is.
| cabalamat wrote:
| > but anyone that has ever needed to style a <select> to make
| it look in line with any modern design
|
| Then don't make it look "in line with any modern design". Make
| it look like an HTML select tag, because that's what it is.
|
| Functionality should (nearly always) trump prettification.
| (Especially when the results are pretty anyway).
| ajkjk wrote:
| I feel like it's important to establish that "controls should
| look like the browser intended and not be customizable" is an
| ideological stance, not an obvious and self-evident truth.
| And it's one that I strongly disagree with, because it's
| needlessly controlling: why shouldn't developers me able to
| make something look however they want? The web is a platform
| for _all kinds of creations_, not just "website that look and
| feel like websites", and people should have the freedom to do
| whatever they want and not be constrained by arbitrary
| limitations of bad APIs.
| SPBS wrote:
| What kind of CSS do you need to add to <select>? Do you have an
| example of this modern design?
| rhdunn wrote:
| The dropdown listbox, optgroup labels, and options should all
| be part of the CSS box model and have all the styling options
| available. That would allow full styling (including border,
| margin, padding, text and background colour) and make the
| listbox match the other element styling.
|
| That would go a long way, but doesn't support more complex UI
| like checkboxes in the dropdown (for a compact multiselect
| component), a treeview instead of a listbox (including
| checkbox support), and highlighting parts of option text for
| things like autocomplete (with the ability to filter based on
| what's being typed).
|
| It would also be useful to know if the listbox is being
| displayed above or below the select, so with a rounded
| border, you can style both the select input and listbox to
| have a flat edge on the top or bottom accordingly.
|
| For checkboxes, it should be possible to theme them more
| easily, including: 1. border width, colour, and radius for
| the box; 2. a graphic or unicode character for the checked
| and mixed states; 3. optionally an image for the entire
| checkbox.
| egeozcan wrote:
| 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.
| marcosdumay wrote:
| 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.
| galaxyLogic wrote:
| 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
| nine_k wrote:
| 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.
| crooked-v wrote:
| Now make that a set of 200 checkboxes and see how
| practical it is compared to one combobox-style multi-
| select input.
| pc86 wrote:
| 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.
| blacklion wrote:
| 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.
| nine_k wrote:
| 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.
| egeozcan wrote:
| > 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.
| nine_k wrote:
| > 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.
| earthboundkid wrote:
| You just need a fuzzy text filter at the top to hide the
| checkboxes you don't care about.
| egeozcan wrote:
| I think this thread just about proved how insufficient
| the available controls are.
| cabalamat wrote:
| I would probably use a series of checkboxes for the same
| effect.
| egeozcan wrote:
| 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.
| com2kid wrote:
| 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.
| Shared404 wrote:
| 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.
| kreetx wrote:
| 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.
| worldsayshi wrote:
| >I can't select multiple non-consecutive items by using just
| my mouse
|
| Well you can with ctrl-click. A well hidden feature though.
| egeozcan wrote:
| > using just my mouse
| ironmagma wrote:
| Say what you will about ActiveX, but it allowed a much more
| native feel for web pages.
| jraph wrote:
| 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
| MaxBarraclough wrote:
| > 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.
| ironmagma wrote:
| 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.
| cycomanic wrote:
| What is the problem exactly seems to work fine on Firefox
| mobile
| cookiengineer wrote:
| How about some checkboxes and labels with the for attribute
| then?
| iamben wrote:
| 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!
| egeozcan wrote:
| 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.
| lhorie wrote:
| 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
| egeozcan wrote:
| 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.
| lhorie wrote:
| > 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 :)
| egeozcan wrote:
| I'm arguing that you DO need custom controls. Did you
| read the thread?
| lhorie wrote:
| 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.
| egeozcan wrote:
| 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).
| lhorie wrote:
| 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...
| runarberg wrote:
| 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.
| tomger wrote:
| The js fiddle example works great on iOS. I didn't realize
| mobile safari supported a multi-select sheet!
| nedt wrote:
| 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.
| cosmotic wrote:
| Most websites that use custom components look and feel broken,
| no matter what the year.
| mdoms wrote:
| > anyone that has ever needed to style a <select>
|
| No one has ever, in the history of software, NEEDED to style a
| <select>. You want to style a select. Your users don't give a
| toss.
| yoz-y wrote:
| That's untrue. As long as the UI works, people will prefer a
| nicely looking one.
| mdoms wrote:
| > As long as the UI works,
| Aeolun wrote:
| I mean, we don't _need_ custom browser components. We need
| certain functionalities that just cannot be given by default
| components without a ton of ugly hacks.
| throw_m239339 wrote:
| I agree 100%. and the fact that there are still only a handful
| of form controls is just jarring. The people who champion using
| JS frameworks to make up for the lack of form elements are
| contributing to the problem, especially on mobile. No library,
| not even well tested JS ones can make up for the native
| controls. This is why users do prefer mobile native apps.
| mmis1000 wrote:
| Imagine a custom implemented drop down that just goes out of
| the screen and make you unselectable. Let alone the item
| height are just narrow that make you accidentally click
| something next to it. And yea, that happens all the time.
|
| And as a developer I often need to argue with the designer
| that please just don't use dropdown on mobile ui when there
| are many items. That is just a torture for a phone user.
|
| And sometimes I even need to add hidden area to the ui.
| Because the controls are way too tiny to click.
|
| Usability are not really in their mind., Or probably it is
| just a bad designer.
| mouzogu wrote:
| the web is really a horrible platform to build any kind of high
| fidelity app. you can say it works despite of itself.
|
| and this is by design, web as a platform is pretty much owned
| by tech giants like google and apple who have a financial
| interest in keeping the web from becoming a rich platform which
| would cut into their app store hegemony.
|
| ironic when you consider iphone and the html 5 back story. in
| some respects microsoft with IE back in the days was more
| interested in developing the web as a platform but also saw the
| web as something they could monopolise whereas now apple takes
| a more nuanced but just as much devious approach.
| danielvaughn wrote:
| What I think the web really needs is headless behavior via
| attributes.
| easrng wrote:
| Like onclick, onsubmit, etc? We already have those.
| dfabulich wrote:
| I have good news for you! https://open-ui.org/
|
| > _The purpose of Open UI to the web platform is to allow web
| developers to style and extend built-in web UI controls, such
| as <select> dropdowns, checkboxes, radio buttons, and
| date/color pickers._
|
| Their current thinking is to cook a new element, <selectmenu>.
| Here's a demo of styling it in an experimental version of
| Chrome. https://www.youtube.com/watch?v=IjHnmaquifM
|
| (They went with a new element <selectmenu> instead of <select
| styleable=true>, but there's still an ongoing debate about
| that, and/or how to polyfill it.)
| scelerat wrote:
| "no, but we want our customers to have an immersive brand
| experience"
|
| - egos
___________________________________________________________________
(page generated 2022-02-24 23:00 UTC)