Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Custom JavaScript controls can't capture the nuance of form fields (2021)

drewdevault.com

Post reply on HN
Print view View original

221–227 of 227 posts

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#221

Post by kevincox »

awinter-py wrote: post #167

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 i…

To be fair Google Docs is a bit different here. To a large extent their goal is to display what is going to be printed (this is changing a bit with the new pageless mode and things like checkboxes but still is the core). So doing all of the rendering themselves actually makes sense.

That being said I would love to see a rich-text input with some default controls available.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#222

Post by kevincox »

bandie91 wrote: post #216
LinAGKar wrote: post #86

Same with links, for example when someone makes a JavaScript link and breaks the middle click to open in new tab

many +1 and add target=_blank to the list.

In Firefox there is an option to override this in about:config so that all links open in the same tab.

However the downsides including breaking some OAuth authentication flows and sometimes you can't open fake links in new tabs when you want to.

However for me the consistency is still worth the minor breakagaes.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#223

Post by bmn__ »

ajkjk wrote: post #214
bmn__ wrote: post #193

Earlier quoted context omitted.

I feel like it's important to establish that "controls should look like the Web designer intended and 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 should Web designers be able to make something look however they want? The web is a platform for _all kinds of users_, not just "websites that look and…

That's just petty, and not effective at making whatever point you're making anyway (which, well, I'm not sure what it is).

You know what's petty? Not being able to come to terms with criticism, and then pretending to not understand it.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#224

Post by rhdunn »

extra88 wrote: post #211
rhdunn wrote: post #204

Earlier quoted context omitted.

The open-ui is only potentially good when you need something that resembles the standard controls and interactions. At the moment it only has a few controls specified and if you need anything not covered by those you are going to end up creating your own UI -- e.g. using a treeview dropdown instead of a listbox, or if you have a form with multiple checkboxes and need that group of checkboxes to be a role=select from…

>a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user. ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, , and error messages…

> ARIA 'select' is an abstract role, it's not meant to be used in code [0]. Form inputs should be grouped by HTML, , and error messages should go where they make sense; the fieldset's is the name of the group but since it is repeated like a description after the name of each child input, it could be useful to add an error message to it.

Thanks for the fieldset tip.

> > If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns

> I am saying that, the Authoring Practices examples aren't battle-tested, that's not what they're for.

Oh right. That makes sense. I use those as a reference point, not as something to use as-is. I mainly refer to the keyboard, role, and attribute specification in the main document, as they are clearly specified.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#225

Post by martindale »

mihaic wrote: post #7

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 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.

Agree completely. I'm practically one new-tab-opened-without-me-asking away from forking a browser just to remove this behavior.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#226

Post by spiralx »

kreetx wrote: post #160
Shared404 wrote: post #154

Earlier quoted context omitted.

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.

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.

Re: Custom JavaScript controls can't capture the nuance of form fields (2021)

#227

Post by stereocodes »

marcellus23 wrote: post #140
stereocodes wrote: post #117

Earlier quoted context omitted.

what does this have to do with form fields? edit: I see you think that context menus are form fields. Thats incorrect.

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.

did you read the article? the context of this entire thread is about form fields.
Post reply on HN