<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:
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:
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.
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 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 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.
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 createdopen-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.
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
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 developerswho 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.
Chrome 81 adds two new immersive features to the web, both designed to support augmented reality. The WebXR Device API, first enabled in Chrome 79, now supports augmented reality. We've also added support for the WebXR Hit Test API, an API for placing objects in a real-world view.
If you've already used the new API to create virtual reality, you'll be happy to know there's very little new to learn to use AR. This is because the spec was designed with the spectrum of immersive experiences in mind. Regardless of the degree of augmentation or virtualization, the application flow is the same. The differences are merely a matter of setting and requesting different properties during object creation.
The WebXR Hit Test API provides a means for an immersive experience to interact with the real world. Specifically, it enables you to place virtual objects on real-world points in a camera view. The image below from one of the Immersive Web Working Group's sample apps illustrates this. The broken blue circle indicates a point returned from the hit test API. If I tap the screen a sunflower will be placed there. The new API captures both the location of a hit test and the orientation of the point that was detected. You'll notice in the image a sunflower has been placed on both the floor and the wall.
If you're completely new to the WebXR Device API, check out our earlier articles, Virtual reality comes to the web and Virtual reality comes to the web, part II. If you're already familiar with entering a WebXR session and constructing a frame loop, then check out our new article on Web AR. Also check out our article on the WebXR Hit Test API.
Origin Trials
This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.
PointerLock unadjustedMovement
Scripts now have the ability to request unadjusted and unaccelerated mouse movement data when in PointerLock. If unadjustedMovement is set to true, then pointer movements will not be affected by the underlying platform modifications such as mouse acceleration.
Other features in this release
Buffered Flag for Long Tasks
Chrome 81 updates the buffered flag of PerformanceObserver to support long tasks. In particular, this feature provides a way to gain insight into early long tasks for apps or pages that register a PerformanceObserver early.
CSS image-orientation property
Chrome will by default respect EXIF metadata within images indicating desired orientation. The accompanying image-orientation property allows developers to override this behavior.
CSS Color Adjust: color-scheme
A new meta tag and CSS property lets sites opt-in to following the preferred color scheme when rendering UI elements such as default colors of form controls and scrollbars as well as the used values of the CSS system colors. For Chrome 81 only initial color and background are affected.
Exclude Implicit Tracks from grid-template-rows and grid-template-columns Resolved Values
Note: This was mistakenly included though it did not actually ship.
hrefTranslate attribute on HTMLAnchorElement
The HTMLAnchorElementnow has an hrefTranslate attribute, providing the ability for a page to hint to a user agent's translation engine that the destination site of an href should be translated if followed.
IntersectionObserver Document Root
The IntersectionObserver() constructor now takes a Document as the 'root' argument, causing intersections to be calculated against the scrolling viewport of the document. This is primarily targeted towards observers running in an iframe. Previously, there was no way to measure intersection with the scrolling viewport of the iframe's document.
Modernized Form Controls
In version 81, Chrome modernizes the appearance of form controls on Windows, ChromeOS, and Linux while improving their accessibility and touch support. (Mac and Android support are coming soon.) It's hoped that this will reduce the need to build custom form controls. This change is the result of collaboration between Microsoft and Google. For more information, see the recent talk at CDS or the MS blog post. For a closer look at the controls, this page gives an example of all of the elements that changed.
Move onwebkit{animation,transition}XX handlers to GlobalEventHandlers
Until now, the prefixed onwebkit{animation,transition}XX handlers were only available on the Window object in Chrome. They are now on HTMLElement and Document as required by the spec. This fix brings Chrome in line with Gecko and Webkit.
Note: This change is intended to improve interoperability on existing web pages. These handlers are still obsolete so web developers should use the non-refixed versions on new pages.
Position State for Media Session
Adds support for tracking position state in a media session. The position state is a combination of the playback rate, duration, and current playback time. This can then be used by browsers to display position in the UI and with the addition of seeking can support seeking/scrubbing too. For a code sample and demonstration, see our sample.
SubmitEvent
Chrome now supports a SubmitEvent type, an Event subtype which is dispatched on form submission. The SubmitEvent has a submitter property that refers to attributes of the submitter button including the entry data, the formaction attribute, the formenctype attribute, the formmethod attribute, and the formtarget attribute.
Currently, applications are doing their own form submission by calling preventDefault() during onsubmit. This approach has the limitation that the received event does not include the button that triggered the submission.
WebAudio: ConvolverNode.channelCount and channelCountMode
For a ConvolverNode, the channelCount can now be set to 1 or 2. The channelCountMode can be "explicit" or "clamped-max". Previously, a channelCount of 1 was not allowed and neither was a mode of "explicit".
This release also extends ConvolverNode capabilities slightly to allow developers to choose the desired behavior without having to add a GainNode to do the desired mixing.
Adds the onclosing event to the RTCDataChannel object, which signals to the user of a data channel that the other side has started closing the channel. The user agent will continue reading from the queue (if it contains anything) until the queue is empty, but no more data can be sent.
WorkerOptions for shared workers constructor
Adds the WorkerOptions object as the second argument for a shared worker constructor. The previous second argument, a string containing the worker's name is still supported.
WritableStream.close()
WritableStream objects now have a close() method that closes a stream if it is unlocked. This is directly equivalent to getting a writer, using the writer to close the stream, and then unlocking it again.
JavaScript
This version of Chrome incorporates version 8.1 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent changes in the V8 release notes.
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
Deprecation and Remove "basic-card" support Payment Handler
This version of Chrome removes the basic-card polyfill for Payment Request API in iOS Chrome. As a result, the Payment Request API is temporarily disabled in iOS Chrome. For full details, see Rethinking Payment Request for iOS.
Remove supportedType field from BasicCardRequest
Specifying "supportedTypes":[type] parameter for "basic-card" payment method shows cards of only the requested type, which is one of "credit", "debit", or "prepaid".
The card type parameter has been removed from the spec and is now removed from Chrome, because of the difficulty of accurate card type determination. Merchants today must check card type with their PSP, because they cannot trust the card type filter in the browser:
Only issuing banks know the card type with certainty and downloadable card type databases have low accuracy, so it's impossible to know accurately the type of the cards stored locally in the browser.
The "basic-card" payment method in Chrome no longer shows cards from Google Pay, which may have connections with issuing banks.
Firefox removed "supportedTypes" in version 65.
Remove the <discard> element
Chrome 81 removes the <discard> element. It is only implemented in Chromium, and is thus not possible to use interoperably. For most use cases it can be replaced with a combination of animation of the 'display' property and a removal (JavaScript) callback/event handler.
Remove TLS 1.0 and TLS 1.1
Note: Removal of TLS 1.0 and TLS 1.1 has been delayed to Chrome 83, which is expected to ship in late May 2020.
This version of Chrome removes TLS 1.0 and TLS 1.1. TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.
TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and was vulnerable to attacks.
TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
TLS 1.0 is no longer PCI-DSS compliant.
Supporting TLS 1.2 is a prerequisite to avoiding the above problems. The TLS working group has deprecated TLS 1.0 and 1.1. Chrome deprecated these features in version 72 in early 2019.
TLS 1.3 downgrade hardening bypass
TLS 1.3 includes a backwards-compatible hardening measure to strengthen downgrade protections. However, when we shipped TLS 1.3 last year, we had to partially disable this measure due to incompatibilities with some non-compliant TLS-terminating proxies. Chrome currently implements the hardening measure for certificates which chain up to known roots, but allows a bypass for certificates chaining up to unknown roots. We intend to enable it for all connections.
Downgrade protection mitigates the security impact of the various legacy options we retain for compatibility. This means user's connections are more secure and, when security vulnerabilities are discovered, it is less of a scramble to respond to them. (That, in turn, means fewer broken sites for users down the road.) This also aligns with RFC 8446.
We plan to roll out restrictions on mixed content downloads on desktop platforms (Windows, macOS, Chrome OS and Linux) first. Our plan for desktop platforms is as follows:
In Chrome 81 (released March 2020) and later:
Chrome will print a console message warning about all mixed content downloads.
In Chrome 84 (released July 2020):
Chrome will warn on mixed content downloads of executables (e.g. .exe).
In Chrome 85 (released August 2020):
Chrome will block mixed content executables.
Chrome will warn on mixed content archives (.zip) and disk images (.iso).
In Chrome 86 (released October 2020):
Chrome will block mixed content executables, archives and disk images.
Chrome will warn on all other mixed content downloads except image, audio, video and text formats.
In Chrome 87 (released November 2020):
Chrome will warn on mixed content downloads of images, audio, video, and text.
Chrome will block all other mixed content downloads.
In Chrome 88 (released January 2021) and beyond, Chrome will block all mixed content downloads.
Example of a potential warning
Chrome will delay the rollout for Android and iOS users by one release, starting warnings in Chrome 85. Mobile platforms have better native protection against malicious files, and this delay will give developers a head-start towards updating their sites before impacting mobile users.
Developers can prevent users from ever seeing a download warning by ensuring that downloads only use HTTPS. In the current version of Chrome Canary, or in Chrome 81 once released, developers can activate a warning on all mixed content downloads for testing by enabling the "Treat risky downloads over insecure connections as active mixed content" flag at chrome://flags/#treat-unsafe-downloads-as-active-content.
Enterprise and education customers can disable blocking on a per-site basis via the existing InsecureContentAllowedForUrls policy by adding a pattern matching the page requesting the download.
In the future, we expect to further restrict insecure downloads in Chrome. We encourage developers to fully migrate to HTTPS to avoid future restrictions and fully protect their users. Developers with questions are welcome to email us at security-dev@chromium.org.
In order to determine which ads are the most intrusive to web experience, we rely on the Better Ads Standards which give companies like Google guidance based on feedback from people around the world.
Today, the group responsible for developing the Better Ads Standards, the Coalition for Better Ads, announced a new set of standards for ads that show during video content, based on research from 45,000 consumers worldwide.
There are many different types of ads that can run before, during, or after a video but according to the Coalition’s research, there are three ad experiences that people find to be particularly disruptive on video content that is less than 8 minutes long:
Long, non-skippable pre-roll ads or groups of ads longer than 31 seconds that appear before a video and that cannot be skipped within the first 5 seconds.
Image or text ads that appear on top of a playing video and are in the middle 1/3 of the video player window or cover more than 20 percent of the video content.
Does this affect my video content?
The Coalition has announced that website owners should stop showing these ads to their site visitors in the next four months. Following the Coalition’s lead, beginning August 5, 2020, Chrome will expand its user protections and stop showing all ads on sites in any country that repeatedly show these disruptive ads. It’s important to note that YouTube.com, like other websites with video content, will be reviewed for compliance with the Standards. Similar to the previous Better Ads Standards, we’ll update our product plans across our ad platforms, including YouTube, as a result of this standard, and leverage the research as a tool to help guide product development in the future.
If you operate a website that shows ads, you should consider reviewing your site status in the Ad Experience Report, a tool that helps publishers to understand if Chrome has identified any violating ad experiences on your site. Starting this week, we’ll update the Ad Experience Report with information to help publishers resolve any issues with these new video standards currently on their site. For more information about this process, you can reference the Help Center and Community Forum.
