Standardize form controls & components

This work will span WHATWG, Web Components, CSSWG and who knows what else. At any rate I’d like to propose a central repo for linking to standardization and improved standardization of form controls & components. This repo, currently here will allow us to have cross control issues and routing them accordingly while providing a central location to the other WICG based repo/discussions occurring for others. I’d like to transfer this to the WICG repo.

To ensure I’m complying with the WICG reqs for transferring a repo, here is a section taken from a blog post I’ll be putting up soon which covers only one aspect of the problem that web developers and ultimately end users face by us not dealing with this issue.

A good example of how this can be so problematic is , here is what it currently looks like in Edge, Firefox, Chrome and Safari:

Chrome:

Edge:

Firefox:

Safari (MacOS):

These types of browser inconsistencies wouldn’t be such a huge deal if the form parts were agreed upon and reachable by web developers. Unfortunately, the majority of form controls and components aren’t which leaves web developers to go to great lengths to work around this; here’s simply one example blog post detailing ways to work around the form control. This hack can be seen on many major sites such as Facebook and Twitter.

This is great! As a frontend developer, I would love to see this work happen. Customising form controls is something I encounter in most if not all projects, and lack of a native way to do it is a real issue.

I fully support this effort and think it’s a great idea. Right now, form controls are inconsistent between browsers, and even between OS platforms on the same browser, don’t look great by default, are not easily style-able in many cases, and are not very extensible. As a result, many sites roll their own controls in order to meet the look-and-feel + functionality requirements of the page, and don’t use the built-in ones at all.

This situation is bad because it (a) is a tax on each site that they need to build such controls, (b) is a tax on users because the site’s javascript is larger, and © often results in form controls which behave worse in terms of accessibility, responsive design, touch input, localization, and other features that can be provided by the user agent instead.

Instead, we should have form controls that easily admit styling to adjust to the brand/color scheme of a site and are extensible when needed, but that always have good accessibility, etc responsiveness, etc., and look great & consistent by default.

This would be very useful for things where the common existing workaround is to use an <input type="..." hidden> and reimplement it entirely, something that’s easy to screw up and leave with related problems and something that results in a lot of otherwise unnecessary network and page load overhead just in the amount of code it takes to do correctly.

Is there a broader effort including other host-specific things that aren’t currently portably styleable like scroll bars* and anonymous text fragments? Styling scrollbars is obvious, and it’s been implemented for years in WebKit and Blink both via ::-webkit-scrollbar, but sStyling plain text would sometimes be useful when you’re doing display: flex and other similar stuff, having ::before and ::after on them would be nice, and it’d be nice to save an otherwise unnecessary <div> or (more often) <span>. There’s also some relatively obscure cases where it avoids certain issues and plays nicer with things.

Edit: Scroll bars are apparently a work in progress. I also struck some redundant text.

FYI: https://www.w3.org/TR/css-scrollbars/

Thanks! Was not aware of that. Are you aware of anything about styling raw text outside of elements?

@isiahmeadows I’m not sure how that is related to this topic, but probably this: https://github.com/w3c/csswg-drafts/issues/2208

I support this work, and I think having a repo for cross-cutting issues with form controls (or “widgets”) sounds good.

I’m looking forward the progress on this! Not only the style but also the interaction of form controls varies in different browser. Form controls and components work with the directional input, but the behavior caused by the input is different.

For example, the input element which type is ‘date’, there are differences as below: ( I couldn’t check this in MacOS)

• How to open the calendar widget
  • Chrome: Click the drop-down UI
  • Firefox, Edge: Click any field among year, month and date
• The initial number set by the directional input
• Appearance

  • Chrome:

    

  • Edge:

    

  • Firefox:

    

@jihyerish Thanks for the response, and yes - that is the intent. We have purposefully not scoped this to style because as we did our customer interviews and surveys we found that styling was only a part of the problem. So simply adding a bunch more psuedo elements won’t solve the entire problem. At any rate, it’s a large problem and why we plan to peel the onion control by control. We’ll see how this goes, I know this is not the first time this has been tried but I think it may be time again and if the webdev community rallies alongside UAs/Standards participants that are on board with this we may be able to make progress.

Requested feedback from Mozilla https://github.com/mozilla/standards-positions/issues/177