Chromium Blog: chromium

Updates to Form Controls and Focus

Monday, March 30, 2020

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 80

Form controls as they appear in Chrome 80

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

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

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

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

Intent to Explain: Demystifying the Blink Shipping Process

Tuesday, November 12, 2019

If you’re a standards-curious web developer, you may have wondered how features get added to browsers, or even how the Chrome team decides what they will work on. You probably also have, at least at some point, thought to yourself “I have this urgent problem but I’ll have to work around it for the foreseeable future, because browsers are just too slow to bring in changes”. You may have even added some expletives when no one was around.
If that description sounds accurate, this is the post for you! This post will describe the Blink process, how browser engineers (both inside and outside of Google) use it in order to ship features in Chromium, what considerations are taken when deciding to ship a new feature, as well as some considerations that impact what features get worked on, and how you can play a role in all of this! Project goals The Chromium project is the open source project on which Chrome is built, and on which other browsers are also based: Samsung Internet, Opera, Brave, Vivaldi, and last (to join the project) but not least, Microsoft Edge. The project enables all those different browsers to share a single implementation of the web platform, and at the same time, keep their unique characteristics and focus.
Blink is the rendering engine used by Chromium. It is the part of the project that descends from WebKit (the rendering engine Safari uses), and which is mostly (but not exclusively) responsible for the Chromium’s Web Platform implementation. The goal of Chromium and Blink inside it is to continuously improve the web platform as a whole.
How does Blink improve the web platform?

By improving its predictability through testing and infrastructure, making sure developers have to spend less of their time tackling browser-specific issues and more of their time… well, developing.

By removing user hostile features, features that increase the platform’s complexity or make its implementations less secure.

By adding platform capabilities that enable web developers to innovate and create web experiences that meet and exceed their users’ expectations and needs.

If we want the web to thrive in the long term, we need to make sure that our users consider it safe and pleasant to use, and that it supports all the capabilities developers need in order to easily make their users (and businesses) are happy.
Any improvement to the platform needs to take backwards compatibility and cross-browser interoperability into account. There’s a lot of web content out there that will never change. The risk of breaking some of it needs to be weighed against the user benefits of shipping that new feature or removing that risky old one. Similarly, in cases where Blink is the first engine to ship a feature or to remove it, we should make sure other browser vendors can follow. We do that by ensuring shipped features designs are widely reviewed, and have specifications and tests to guide future implementers.
The Chromium project is rather large, and is being worked on by many different entities. Therefore it needs to control which features get shipped, while being even-handed in that decision process. We achieve that through a simple process that guides contributors as they evolve the platform to ensure maximum long-term compatibility and interoperability. What features get worked on? Chromium is an open source project that’s being worked on by over 2000 engineers from ~55 different organizations. Of course, Google is responsible for the bulk of Chromium - 92% of commits to the project (data) come from Google, although about 20% of contributors are not Google-affiliated.

With a project of this magnitude, each of the involved companies and contributors are naturally pushing their own slightly different agenda and priorities. Even within Google’s Chrome team there are multiple ways to prioritize which problems are most urgent to tackle and solve. One area that is consistent, is that we work with the ecosystem and developer partners to understand and address their needs. We do that by creating compatibility dashboards, collaborating with frameworks, and observing development patterns in the wild.
The MDN survey is a great example of how the ecosystem can help shape the priorities that a browser vendor has. We’re still in the process of analyzing the results, but it was clear that compatibility is a top priority for developers and we will commit to keep improving on it. We also plan to create more ways to gather structured data on developer needs and hardships.
As you can imagine, with all these priorities from different contributors, it's important for us to be clear about how a feature goes from inception to shipping.

So, what are the typical phases of creating a new web platform feature and shipping it in Chromium?
The very first step before getting started would be to figure out what we need to be working on and which user or developer problems are the most burning ones. That is typically done by talking to partners, looking at current development patterns and consulting with web developers and framework authors to get a better understanding of what the platform can do better to address their and their users’ needs. Once we know which problem we want to tackle, we can start incubating it! What does “incubating” mean?
Over the years, we found that the best way to design and prototype a new platform feature is through incubation - getting a strong grasp of the use cases a feature is trying to solve as a first step, and then rapidly iterating over the design in a public forum that includes browser engineers and domain experts. Only once we are certain that a feature solves important use-cases and have high confidence that it solves it the right way, we bring that feature to an official track at a Standard Development Organization, such as a W3C Working Group, the WHATWG, or TC39.
Not all incubations turn up to be standards though. Some incubations fail and some prototypes never make it out to the hands of users. That is perfectly fine and by design. The web platform cannot afford features that don’t solve real user or developer problems to creep in, and we want to make sure those features never make it to be a permanent part of the platform. Step 1 - Initial research At this phase, we establish a better understanding of the problem space, by gathering up the specific use-cases we want our future solution to tackle and the constraints under which the solution must operate.
At the end of that phase, engineers are expected to publish an explainer that outlines the above, and maybe have a very rough sketch of what a solution may look like. The explainer is published in a relevant public forum (e.g. the WICG discourse) in order to solicit feedback from the web community at large. Such feedback can include missed-out use-cases, further constraints that can impact the design, or simply statements of support for solving the problem.
It’s important at this stage to focus on the problem, and not over-index on any one possible solution - and this is one of the places we haven’t always been perfect. Step 2 - Design & Prototype Now that we have better grip of the problems we’re trying to solve and the constraints in which we operate, we can start designing the feature and what it may look like. Ideally, the design team would include browser engineers from interested vendors as well as problem space experts from the web developer or framework developer community.
Once we have an initial rough design, it might be a good idea to start building and committing code (behind a flag and turned off by default) in order to better understand the solution’s feasibility and complexity.
That’s when engineers should send out an “Intent to Prototype” email to blink-dev (previously, “Intent to Implement”), in order to notify the relevant code owners that work is underway in that area. Note that such an intent doesn’t mean that the feature is shipping soon, or that it will ship at all for that matter. It just means that this is a problem space that’s being explored, and code is landing to that end.
That’s also a good point in time to make sure the feature will get a wider review, by filing for a TAG review. Step 3 - Experiment & iterate Once code starts to land behind a flag, it’s a good time for interested web developers to start playing around with the solution by turning on the feature flag and testing it out. Feedback on the initial implementation is critical in order to make sure the eventual design would work well for developers and users alike. For some features, such experimentation is enough for developers to get a good handle on what’s the solution looks like, and how well it addresses the problem.
In other cases, it’s critical to gather data from the field regarding the solution, to see how well it works in broader deployment to fulfill user’s needs, or get a better understanding of its performance characteristics at scale. Step 3.5 - Origin Trial In those cases, a browser engineer can request an Origin Trial (by sending out an Intent to Experiment email), which enables interested developers to test the feature out in broader deployment to users who have not turned on the feature flag. Once an Origin Trial is in place, developers can register for the trial, and enable the feature (in production) for their domains. That enables them to gather data on the user impact of the feature, and report it back to the design team, confirming or refuting their assumptions regarding the solution’s viability.
Note that an Origin Trial is a temporary experiment, and there’s a good chance that the feature will significantly change before it will be enabled by default, or even that the effort will be dropped altogether. Developers interested in participating should take that into account, and not rely on the feature being available to their users beyond the scope of the trial. Step 4 - ship it! Once the previous steps were completed with success and the team believes the feature is ready to be turned on by default, that’s when they can submit an Intent to Ship.
That’s a part of the process that’s a bit more strict.
In order to ship a feature by default, engineers need approval for the feature to ship from 3 API owners.
What’s an “API owner”? API owners are a set of trusted Chromium engineers, who are responsible for enforcing the Blink process guiding principles. Each feature we’re trying to ship has some user and developer benefits, otherwise we probably wouldn’t be working on it. Shipping new features can introduce interoperability risks, if other browsers don’t follow us. The API owners are tasked with applying our compatibility and interoperability principles and help evaluate each shipping feature with regards to its risk/benefit tradeoff. They then provide their approval on “Intent to Ship” threads for new shipping features, if they think the benefits outweigh the risks. Those approvals are provided in the form of “LGTM” (“Looks Good To Me”) replies on intent threads.
Note that LGTMs are not required for Intent to Prototype. For an Intent to Experiment, approval from a single API owner is sufficient, as the risk they pose is fairly contained.
As part of the “Intent to Ship” request, chromium engineers need to provide clear signals regarding the risk and benefit tradeoff of the feature.

The feature needs to have a solid specification and a comprehensive cross-browser test suite in order to minimize interoperability risk.

Signals from other browser vendors as well as from wide review forums (such as the TAG) are taken into account, alongside signals from the web developer community and partners who are planning to use the feature.

If the feature went through an Origin Trial, a report outlining the results is also important to better understand the benefits.

Note that the fact that an “intent to ship” is sent indicates the team’s estimate of the feature being ready to ship, but it does not necessarily mean that the feature will ship shortly, or at all.
Some features take a long time to go through the intent process, in order to prove that the risk they pose is low enough to justify shipping. Others get held up addressing feedback from other vendors or from wide-review forums.
In other (rare) cases, features can be rejected by the API owners, and their proponents then need to look for alternative ways to resolve the problem, which won’t hit the same concerns that got their initial intent rejected. Removing features Finally, while adding new feature certainly grabs most people’s attention, an equally important part of the intent process is to deprecate and remove legacy web platform features. In those cases, the main risk is breaking existing content, and the benefits are typically around improving user’s security, privacy and performance. The project’s willingness to take some compatibility risk and remove features is critical to our risk/benefit calculus also when launching features first - if we got it wrong and late feedback causes us to change course, we typically can figure out a path to deprecate those features to get us back on track to interoperability. Summary The Chromium’s project goal is to make sure the web platform remains a healthy and successful platform. For that, we believe the platform needs to make significant progress in the face of shifting developer and user expectations, as well as adapt to the changing market forces and constraints. At the same time, we need that progress to be done in a responsible manner both inside the Chromium project and when it comes to our collaboration with the wider ecosystem.
The Blink process’ role is to keep the balance between those different requirements, and to help ensure the web is a thriving platform for generations to come.

Posted by Yoav Weiss, Wrangler of processes and Advocate of developers.

Changes to the Field Trials infrastructure

Friday, May 25, 2012

In theory there’s no difference between theory and practice. In practice, there isnew ideas out in the real worldcontributing to ChromeField TrialsPosted by Tyler Odean, Product Manager

SSL FalseStart Performance Results

Wednesday, May 18, 2011

Last year, Google’s Adam Langley, Nagendra Modadugu, and Bodo Moeller proposed SSL False Start, a client-side only change to reduce one round-trip from the SSL handshake.
We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%¹. That is a big number. And reducing the cost of a SSL handshake is critical as more and more content providers move to SSL.

Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.
To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.
To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.
All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.¹Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.
Posted by Mike Belshe, Software Engineer

New Flock Browser Based On Chromium

Tuesday, August 24, 2010

Foreword: When we released Google Chrome almost two years ago, we also released the source code under an open-source license. Just as Firefox, WebKit, and other open source projects helped to drive the web forward, we wanted to follow suit and ensure that others could use the code we developed to make their products better. The Chromium codebase provides a complete browser to build on, so that if you want to focus on one particular piece, such as drastically changing the user interface, you can do that without having to worry about how to get amazing performance in the rest of the browser.Recently, Flock released a new beta version of their browser built on top of the Chromium codebase. For those of us in the Chromium project, this is extremely exciting and encouraging. We believe that users having a choice between multiple browsers is a great thing, as it spurs innovation and competition, and lets users choose a browser that provides the best experience for them. Flock brings an innovative approach to their "social web browser," and we are glad to welcome them into the Chromium community. As part of that, we wanted to offer the team behind Flock an opportunity to talk about the ideas behind Flock, how Chromium helped them in achieving their goals, and their vision for the future. What follows is a perspective from Clayton Stark, VP Engineering at Flock.
When Flock began developing its first web browser five years ago, "the social web" was a small, niche market. Today social is the mainstream web, and this evolution in the market drove our development roadmap. With the new Flock browser, our engineering team focused on designing a straightforward and integrated social dashboard that delivers an experience simple enough for a mass audience. This is where the technology behind Chromium came into the picture for Flock. As Chromium emerged, we saw that not only was there significant improvements to performance, but also apparent was a simple and elegant user interface and architecture across all the various systems.
A core goal of new Flock is to keep our users in touch with all of their friends and feeds with a minimum of configuration, and at the same time, make it fun and simple. With all of the users’ feeds and social activity streams flowing into the scrolling sidebar, we knew the performance had to be first-rate, and that techniques we used for earlier versions of Flock were unlikely to perform at scale. With Chromium under the hood, we were able to leverage web workers, and that, combined with the raw horsepower of V8, allowed us to scale the use of the sidebar to manage very large data sets (in the first few weeks after the beta launched we saw a few hundred million activities flowing into Flock’s sidebar). Most importantly, benchmark testing shows us that New Flock with Chromium performs in the top-tier of all browsers available in the market.
Clearly the web is evolving very quickly, and we are seeing more and more people discovering content through their friends. The Flock team is energized by the big developments coming fast in this emerging, interest-graph-enabled web, and we have a roadmap in front of us that we are really excited about. The browsing platform needs to continue to mature at a rapid pace to support the dramatic changes in online user behavior. And, as it does, we already see the performance and power in Chromium that we need to allow us to focus on the innovations we want to bring forward, on top of the platform.
So, I’d like to send out a huge thanks on behalf of the Flock team to all those who have contributed to the Chromium project. Your work has made our project possible, and made new Flock our best release ever.
Clayton Stark, VP EngineeringFlock, Inc.
Posted by Ian Fette, Product Manager

Sep	OCT	Nov
	15
2019	2020	2021

Chromium Blog

Updates to Form Controls and Focus

Intent to Explain: Demystifying the Blink Shipping Process

Changes to the Field Trials infrastructure

SSL FalseStart Performance Results

New Flock Browser Based On Chromium

Labels

Archive

Feed