Initial thoughts on standardizing form controls
While the move to Chromium is bitter sweet for me, one of the things that has me excited is being able to take some of the time that the team has spent devoting to compat and investing it in trying to address the many pain points that we’ve heard through the years.
One area that we’re beginning to investigate is the problem of form controls and components built into the browser. Initially, we started at a very high level by doing an opportunity analysis of the various buckets of work we could consider addressing in this space; all with varying levels of necessary investment. Ultimately, they all came back with an indicator that there was substantial opportunity for web developers, designers and end users if the problem is solved correctly. In addition, it revealed a few core pillars that I feel must exist for the work done in this space to solve the pain points web developers and designers currently face when working with the built in form controls.
- Web developers need complete control over the appearance
- Extensibility needs to be possible
- State management across component(s), including composite components
- Expectation from developers is that the controls "just work"
- Accessibility, performance, focus and other foundational items work as expected
Ok, so now that we have a quick overview of the expected key pillars, let’s dig into a few of them in a little bit more detail with some of the data that lead us to making these key pillars.
Complete control over the appearance
In many of the currently shipping controls and components there are a set
of CSS properties that developers can apply to aspects of control. This is one of the
major pain points presented, some of the top offenders being <select>, <input type="file"><input type="date"/><video> element where the developer either gets all of the controls or none of them by
adding or removing the controls attribute. Because of this, many developers are left recreating all of the functionality already provided even though
they may have only desired to make a small content adjustment, like adding an additional button next
to the play/pause button.
While there is a desire for more native controls in the browser (more on this later), adding them does no good if the web developers and designers can’t adjust them to meet the needs of their site's design or user experience.
I sent out a survey on twitter to understand this problem space a bit more. With close to 1,400 unique respondants it helped reveal why this area is such a pain point for web developers & designers.
Let's take a quick look at some of the results (view the full results here).
Within the survey we asked if they have ever used a library or created their own version of controls, and if they did which controls did they create? Here are the top 10:
This list isn’t surprising if you’ve been in the web development community for a while. But simply requesting which ones were created doesn’t necessarily inform us why they reached for a library or created their own, so we then asked, “What were the top two reasons that you needed to create or use a custom control?”
In addition to Microsoft, Bocoup and Google have been actively investigating this space so when Simon Pieters of Bocoup reached out, having seen my survey, we decided to collaborate on a survey that was presented to attendees of JS/CSS Conf EU. It had the same questions overall but it included two new questions. “Which form control gives you the most frustration”:
And while this is only a slight pivot to what could be inferred from the earlier question it shines a strong light on the most problematic controls.
In addition to this, we asked "Why does that form control give you the most frustration?" (bolded quotes were more commonly stated by respondants but phrased differently):
- “Requires hacky tricks”
- “Can’t style
<option>elements at all to the extent we need to” - “Too little control over styling across popular browsers”
- "I’m generally ok with default rendering of form components and the amount that web fonts, etc can be used. But select menus are a major outlier and just sort of stink”
- “Label “select a file” and file name are hard to customise.”
- “Styling implementation for Select is inconsistent between browsers. Not all styling properties apply to the control.”
- “…but the amount of work it takes to implement an accessible alternative with complete feature parity is massive”
Browser consistency
In order to achieve the capability of control over the appearance; we also need
to ensure that browser vendors align as much as possible on the sub-parts available to web
developers. A good example of how this can be problematic is <input type="file"/>
Chrome:
Edge (EdgeHTML):
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 aren’t standardized, which requires web developers to go to great lengths to work around these shortcomings. Here is one example blog post detailing ways to work around the file form control. Similiar "hacks" can be seen on many major sites such as Facebook and Twitter.
Why is this a necessary pillar?
Browser inconsistencies can lead to negative end user experiences and browser engineers often have an unrealistic expectation of web developers to open every browser and test it thoroughly. This has long been known to be a large request, especially for smaller shops. In order to try to put a quantitative number to qualitative assessment we asked, “Which browsers do you actively test during the development phase?”
This is not necessarily surprising to me given my history on the Microsoft Edge team, but it was kind of surprising how few Safari testers there were. I can only speculate at this point, but I think this has to do with the thought that Chrome is derived from Webkit, as is Safari and thus interoperability is not an issue. Where as Microsoft’s browsers have an infamous reputation of causing web developer pain through interop issues even if Microsoft Edge made huge strides in this regard.
An additional point to Safari’s lower testing can be due to developer access to testing Safari since it’s only available on Mac. We asked, “Which operating system do you primarily develop on?”
This can have a negative impact on our shared users
As we’ve seen in the results above, web developers have an ever-increasing testing matrix of operating systems and browsers. This can result in a negative impact on the end user which is bad for browser vendors, web developers and the companies that employ them to build their site.
To this end, I was curious about a key aspect of the end user experience, accessibility. Since the accessibilty team has spent so much time over the past few years improving accessibility in Microsoft Edge and now in Chromium, how many web developers take advantage of this investment and great work?
To understand this, we asked, “Do you do accessibility testing?”
Then, of the respondants that selected they do accessibility testing, we asked what type of accessibility testing they do:
Then, if they are doing assistive technology (AT) testing we asked which ATs they test with:
So we only have ~40% of web developers (that were willing to answer) doing any type of accessibility testing, and of those users only 27% doing any type of AT testing. This undoubtedly leads to broken user experiences and we have only begun to scratch the surface in this regard.
Standardize in-page controls
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
Reduce throw away work while increasing usability
As seen above, very few web developers have the time to put in the effort to do complete performance, accessibility and compat testing. Whereas the browser vendors, in many cases, are spending their time doing this work. This is something I'm acutely aware of since that’s what we’re actively doing within the Chromium codebase to match our Fluent Design System for the new Microsoft Edge built on top of Chromium.
As such, we want our users to have this experience while enabling web developers to benefit from this time spent by allow them to extend and style these controls; not throw them away to produce their own. Although I realize, give the current state of form controls, web developers are often stuck between a rock and hard place. This will not only improve the end user experience but also improve the developer experience and expense cost for the web development firms. In order to try and solve this problem, we should...
Introduce new form controls and components
Since we are aware of web developers needing to create their own controls, we figured we’d take this time to ask which form controls or enhancements they’d like added to the platform. We didn’t provide an exhaustive list but put in some of the top requests we’ve heard over the years, each respondent could select their top 3:
Top requests under "Other" were:
- Tooltips
- Context menu
- A fully functional dialog
Introduce new APIs to avoid hacky work arounds
As we’ve been looking into this, and as I’ve tried to show above, there will be scenarios in which the web platform is simply missing solutions or APIs necessary to unlock the creativity that web developers and designers hope to accomplish with their controls. Also, as we saw above and during the opportunity analysis, the web community wants to simplify the effort necessary to build the controls they need.
Take the <select> control as one example, without digging too deeply into
it yet - we currently don't have:
- a way in which to have a popup that we can ensure to be on top of all
content and break out of
overflow: hidden - have the popup open in the direction that has more space within the viewport
The Google Chrome team has been actively looking into this space as well, by utilizing built in modules, and they have introduced a proposal for a toggle/switch (WICG Thread) and have begun work on a virtual scroller component as well. In addition, they have an issue open for researching the "top layer" issue noted above open.
First steps regarding this work
More research into select & file
My initial thinking on this, and steps we’ll hopefully be taking soon for this
is to take the <select><input type="file">
Component libraries
We've also begun talking with many of the component libraries and frameworks, spefically about this work to understand what they would like to see from this and to learn from them due to their vast experience in this space. Some of the ones we've begun speaking with are:
- Fast DNA
- Fabric
- Polymer
- Ionic
- Ember
If you work on a component library or framework and are interested in talking, contact me on twitter (my DMs are open).
Stay tuned & get involved
Hopefully this is clear based on the data and the resulting post, that I want to ensure that what is built enables developers and designers to create enriching experiences without having to re-create the wheel. I'm very eager to hear from you and I know many from other browser vendors and members in the standards community are too.
If you're interested in getting involved and keeping up with the progress, follow me on twitter (I commonly send out surveys and short info there), star the Standardized Controls & Components Repo, and provide feedback to Google on their toggle/switch proposal.
That's all for now - thanks for reading and I look forward to a day where we can fully style
a <select> control (can you imagine?!)!
Click here to view the full survey results