[go: up one dir, main page]

HTML form controls provide the backbone for much of the web's interactivity. They're easy for developers to use, have built-in accessibility, and are familiar to our users. One issue with native form controls, however, is the inconsistency in their styling. Older controls, such as <button> and <select> were styled to match the user's operating system. Form controls that were added to the platform more recently were designed to match whatever style was popular at the time. For Chromium based browsers, this has led to controls that look mismatched and sometimes outdated, which causes developers to spend extra time (and ship extra code) styling around the controls' default appearance.



a meter, progress, and input type range element stacked vertically. Their visual styles are very different.
<meter>, <progress>, and <input type="range"> look like they come from different worlds in Chrome 80 on Windows.



To help fix this problem, the teams at Microsoft Edge and Google Chrome spent the last year collaborating to retheme and improve the functionality of the built-in form controls on Chromium browsers. The two teams also worked to make the focused states of form controls and other interactive elements like links easier to perceive. These changes are available today in Edge on Windows, and may be seen in Chrome 81 as part of experiments. The chrome://flags/#form-controls-refresh enables the changes in Chrome 81 as well. The changes will roll out in Chrome 83 on Windows, macOS, ChromeOS, and Linux. See the updated release schedule for Chrome 81 and 83. Updates for Chrome on Android should roll out later this year. If you want to hear more about what's coming to form controls, take a look at Nicole Sullivan and Greg Whitworth's talk from CDS 2019.
A Fresh Coat of Paint
The two teams wanted to make the controls feel like they were part of a matched set. This meant doing away with gradients and using more of a flat design inspired by current design systems.
As Nicole Sullivan, a member of the Chrome team, describes it:
We were going for beautiful, webby, and neutral. We hope that every design system would see a bit of themselves in the new designs and easily imagine how they might be adapted for their own branding.
Below is a comparison of the form controls as they previously appeared in Chromium and as they appear after the redesign:
Form controls as they appear in Chrome 80Form controls as they appear after the redesign. The styles are much more consistent.
Left: Prior styling of form controls in Chrome 80.
Right: Controls as they appear after the redesign.
Improved Accessibility and Touch Support
In addition to improving the default styling, the two teams also tuned up form controls' accessibility and enhanced touch support. 


These changes are most notable in a few key areas:
A More Visible Focus Ring
The focus indicator—sometimes referred to as the "focus ring"—is an important accessibility feature that helps people using a keyboard or switch device to identify which element they're interacting with.


Previously, Chromium used a light single color outline to indicate the focused element. However, if the focused element happened to be on a similarly colored background, the ring would be difficult to perceive:


A button on a blue background. The focus indictor on the button is not discernible.
The previous focus ring on a similarly colored background.



The new focus indicator uses a thick dark ring with a thin white outline, which should improve visibility on both light and dark backgrounds. This is an easy accessibility win that automatically improves the keyboarding experience on a number of sites without developers needing to write any new code.


Black and white double-strokes make the focus ring visible on both light background and dark background
The new two-line design for the focus indicator ensures that it's visible on both black and white backgrounds.



Note that there are still some scenarios where the focus ring may be hard to perceive—for example, if a black button is on a white background, or if the focus ring is clipped by elements that are positioned closely together.


If you run into a scenario where the focus ring is hard to perceive, or if the new focus indicator does not match the design of your site, there are ways to style focus including the new :focus-visible pseudo-class, which provides fine-grained control over when the focus indicator is displayed.
Increased Tap Target Sizes for Multi-input Displays
Over the past few years we've seen an increase in multi-input devices like 2-in-1 devices, tablets, and touch-enabled laptops. This means that touch becomes an important consideration for desktop. However, many of the existing form controls were not designed with multi-input surfaces in mind. For example, <input type="date"> works great on mobile, but the tap targets are much too small to be usable on a touch-screen laptop.


The input type date  element as it appears in Chrome 80. The element has very small buttons for incrementing and decrementing the date.
The previous design for <input type="date"> with small tap targets.



To improve functionality on touch screens, the updated controls will now have better flyouts, larger tap targets, and support for swiping and inertia when scrolling:


The redesigned input type date element. It has large buttons and easy to click dates.
The new design for <input type="date"> with much more accessible tap targets

Improved Color Picker
Previously the <input type="color"> element was not fully keyboard accessible, meaning users relying on a keyboard or switch device couldn't use it. Along with a new appearance, the control is also now fully keyboard accessible and includes additional modifier keys (Control, or Command on Mac). These improvements let users jump by ten color values at a time.


An animation of the redesigned color picker, showing improved keyboard navigation
The new <input type="color"> with improved keyboard accessibility. 



More Consistent Keyboard Access
Finally, the teams updated the ARIA role mapping of all the controls to match the recommendations in the HTML Accessibility API Mappings specification. This should provide a more consistent experience for anyone relying on a keyboard or assistive technology, like a screen reader, to access the page.
How You Can Get Involved
While the design refresh is a much needed change, the two teams have also heard from developers that it should be easier to style the built-in form controls and plan to tackle that work next. If you're excited by the idea of improved styling, functionality, and possibly even new high-level components, the folks at Edge and Chrome need your help!
Test Your Sites
Try out the new form controls and focus indicator in Edge and Chrome Beta. If the design changes have negatively affected your existing sites or apps, let us know using this bug template. Or, if you find a related bug, give it a star! ⭐️ Starring is extremely valuable because it helps platform teams triage and decide what to work on next.
Tell us What You Want to See
Much of the work on the new form controls was enabled through surveying developers, and interviewing design system and UI framework authors.

In an effort to help centralize this feedback and include as many developers as possible in the standards process, the team at Edge have created open-ui.org. If you work on a design system, or a UI component set, consider sharing your knowledge on Open UI to help classify and identify gaps in the existing form controls.

Posted by Rob Dodson, Developer Advocate

Cross-posted from the Chrome Releases Blog

We previously paused upcoming releases for Chrome and Chrome OS. Today we’re sharing an update as we’re now resuming releases with an adjusted schedule:

  • M83 will be released three weeks earlier than previously planned and will include all M82 work as we cancelled the M82 release (all channels).
  • Our Canary, Dev and Beta channels have or will resume this week, with M83 moving to Dev, and M81 continuing in Beta.
  • Our Stable channel will resume release next week with security and critical fixes in M80, followed by the release of M81 the week of April 7, and M83 ~mid-May.
  • We will share a future update on the timing of the M84 branch and releases.

We continue to closely monitor that Chrome and Chrome OS are stable, secure, and work reliably. We’ll keep everyone informed of any changes on our schedule on our release blog and will share additional details on the schedule in the Chromium Developers group, as needed. You can also check our schedule page for specific dates for each milestone at any time.

Thanks everyone for the help and patience during this time.

Posted by the Chrome Release Team

Cross-posted from the Chrome Releases Blog

Due to adjusted work schedules at this time, we are pausing upcoming Chrome and Chrome OS releases. Our primary objectives are to ensure Chrome continues to be stable, secure, and work reliably for anyone who depends on them. We’ll continue to prioritize any updates related to security, which will be included in Chrome 80.


Please follow the Chrome Releases blog for updates.

Posted by the Chrome Release Team

Today we’re announcing two significant changes that affect the developer experience when publishing on the Chrome Web Store. The new developer dashboard is now the default experience, and the developer registration flow has changed.

New dashboard is now the default

We recently launched a new developer dashboard for Chrome Web Store developers to try out. Following a period of feedback and improvement, we’re announcing that this new dashboard is now the preferred dashboard. This dashboard appears by default on the following events:
  • When you click Settings > Developer Dashboard on the Chrome Web Store home page.
  • When you follow existing bookmarks or links to the developer dashboard.
  • When you navigate explicitly to chrome.google.com/webstore/developer/dashboard.
You can opt out of the default behavior by clicking Show more… in the small dialog at the bottom left-hand corner of the new dashboard, then clicking opt out:



Opting out means that you’ll see the old dashboard in each of the cases listed above. You can always opt in again by clicking the link in the old dashboard’s banner:


Opting out is useful for specific use cases that affect a small number of developers. The new dashboard does not yet support the following tasks:
  • Transfer items
  • Edit or publish a paid item, or add in-app purchases, using Chrome Web Store Payments
  • View an item’s public key
  • Re-order screenshots
  • Preview a new version of your item or promotional tiles
  • View revenue stats
For more details and status on these features see the known issues document.

Developer registration fee now required earlier

The Chrome Web Store charges a $5.00 fee to register as a Chrome Web Store developer. This fee was previously required only before publishing an item to the public, but is now required for all Chrome Web Store developers.

Who does this affect?

  • Developers who previously published items to the public were required to pay the registration fee at that time. These developers do not need to pay the fee again: no action is required.
  • New developers must register and pay this fee before they can use the Chrome Web Store developer dashboard.
  • Previously registered developers who have never published an item to the public must now pay this fee before they can use the CWS developer dashboard. If you have published to private domain or to trusted testers, but not to the public, you will now need to pay the registration fee. Note: This will look like a new developer registration flow, but all that’s required is to pay the fee and complete the flow.

Posted by Shumeng Gu, Chrome Web Store Engineer