 The Chrome web browser uses the Blink rendering engine to transform code and resources into a web page that you can view and interact with. And when engineers want to make a change to Blink, they post on the Blink Dev mailing list to get approval to proceed. And these posts are called Blink Intents. I'm Sam Dutton, and in this video, you'll find out how Blink Intents work, why they're important, and how new features make their way into Blink. Now, you may have heard of Chromium. This is the open source browser project on which Chrome and some other browsers and frameworks are built. And Blink, like I say, is the rendering engine used by Chromium. And for a new feature to land in Blink, it needs to go through the Chromium project's open development process. And by new feature, well, you know, I mean any change or addition to browser code or architecture. And that could be a new JavaScript API, a significant performance enhancement in Blink code, or some other change to the way the browser looks or functions. Chromium, you can imagine, is a big project with thousands of contributors. And when there are changes to Chromium, each milestone must be a place to invite the wider web ecosystem to comment on design and implementation. With the goal of ensuring that features are compatible across different web browsers. Wherever possible, new features must be interoperable across the web platform, and not solely implemented on one browser. Web developers do not want surprises. You know, when browsers don't work the way you expect or where you wind up having to write different code for different browsers and platforms. As you'll see, Blink intents help structure and regulate the process of change. And that in turn helps make changes more predictable and less of a surprise, which is good for web developers. For users, we need to be careful that browser changes don't cause websites to stop working, and it's worked to the remembering, actually, that sometimes developers stop maintaining websites. Some sites haven't been updated in decades. Proposals for changes and updates to the web platform come out of research. Consulting with users, businesses, browser engineers, web developers and other stakeholders. And this research allows us to work out what's missing from the platform or what needs to change. Now, initially, a proposal for a change or a new feature on the web platform is just words on a page. Engineers share documents for feedback and discussion from their colleagues. So let's take a look at an example. FedCM, Federated Credential Management. This is a proposal to provide new and better mechanisms for platforms that manage user sign up at login, known as federated identity. For example, I don't know when you select login with Google or login with GitHub. Now, once a proposal like FedCM is ready for public discussion, it gets published to GitHub as what's called an explainer. Now at this point, anyone can ask a question or comment on the design of a feature by creating an issue on the explainer repo on GitHub. In your feedback, you might describe additional use cases or constraints, provide ideas for improvements, or just show support. Once a proposal gets adopted by a standardization body, such as the W3C, you can also join discussions and watch presentations in web standards groups, such as the W3C working groups. Developing web standards is a crucial part of the process here. And you can find out more about that from our forthcoming video, What Are Web Standards? Anyway, now, it's important to mention that at any stage, a feature may not continue in the development process. Some features never get beyond the initial draft proposal stage. And sometimes, a feature makes it to the experimental phase, where developers get to try it out in the wild, but then the feature gets completely reworked because the experiment helped surface unexpected issues. And that's a good thing. A feature must be shown to meet the needs of developers and other stakeholders and make the web better for end users. Before the feature goes through the development process to become part of the web platform and be implemented in browsers. So for each milestone, when engineers are working on a new feature or a change to the Blink rendering engine, they publish a post on the Blink Dev Discussion Group, explaining that they intend to move to the next phase towards implementation of a feature. And these posts are called intents. Anyone, including you, can subscribe to the Blink Dev Group to get notified when there's progress with the new feature in Blink. You can also subscribe to an individual feature to get updates. The first checkpoint is the intent to prototype. At this point, Chromium engineers can begin to implement a feature. And this means that prototype functionality for the feature may be made available for developer testing behind a feature flag, initially in Chrome Canary and then in other release channels. Any user can set a flag from the Chrome Flags page to activate and test a feature on a single browser. However, not all flags can be set from the Chrome Flags page. For more fine grained control, you can run Chrome from a terminal using command line switches. Now, bear in mind that some new features are not available until the feature ships for testing in Chrome Canary, although this is quite rare. Some features don't have their own flag, but they're made available if the experimental web platform features flag is enabled. And this is generally the case for what you might call smaller features that take no more than, say, three to six months to implement, at the most. Anyway, enough about flags. So once prototyping of a new feature has begun, Chromium engineers invite discussion and early experimentation. And feedback at this point is critical for validating and iterating on proposals. Chromium bugs is the place to comment on the implementation in Chrome. An intent to experiment is an optional next step. If Chrome engineers would like to request an origin trial, origin trials are a way to test a new or experimental web platform feature. You register for the origin trial of a feature as a web developer, get a token for the trial, and the feature will be activated on any page that provides the token. You can find out more from our origin trial page, and there's a video about that there as well. For progress towards implementation of a feature to proceed, the Blink API owners must give their approval by replying to an intent with a looks good to me post known as an LGTM. The API owners are a group of Blink contributors, highly experienced with the web platform and its APIs, and agreed by the Blink community to be in good standing with a commitment to Blink's mission and values. As well as giving approval or not for features to proceed towards implementation, the API owners oversee the Blink intent process itself, and you can find out much more about that from the Chromium website. An intent to experiment must get at least one LGTM from API owners. Developers can then sign up for the origin trial of that feature and then test it in production. Like I said, an experimental feature can be activated on any page that provides a valid trial token, and that makes it possible to test a feature in real world environments with real users without them needing to do anything special for the feature to be activated. Developers can then share results of their tests and that provides a valuable insight and data to help iterate and evolve the feature. This is the whole point of an intent to experiment. Developers can try out features with real users and then give us feedback so we can improve the feature. An intent to ship is the final milestone. This signals that a feature is now complete and ready to be implemented for general availability for all users in Chrome Stable without needing a flag or a trial token. An intent to ship must get three LGTMs from API owners before implementation can proceed. Once approved, a feature is merged into an upcoming release and then progresses through the Canary Dev, Beta and Stable channels. Testing and implementation of some features needs to be handled with special care, so some features are rolled out gradually to an increasing proportion of users. Features can also be rolled back and reworked if there are unexpected side effects. As a developer or a site owner, it's critical to ensure you test your sites with the Canary and Beta versions of Chrome to catch and report any bugs before a feature reaches Stable. And you can find out more about that from our video, What Are Chrome Release Channels? There are just two other types of blink intent and these might sound a little sad, but they're actually a good thing. First up, intent to deprecate and next, intent to remove. An intent to deprecate is posted by engineers when they want to start warning developers that a feature is scheduled to be deprecated. For example, by providing support and information about the deprecation in the Chrome DevTools console. An intent to remove is posted by engineers when they need code to be deactivated by default, and that's their intention. Deprecation and removal are both critical to the health of the web platform. They make sure we can remove features that don't work well for end users or web developers and they help reduce the complexity of the code base. For example, problems with the design of AppCache were discovered once it was used on production sites in stable browsers and the API was eventually removed. Deprecations and removals also help to keep Chrome safe and secure by reducing potential attack vectors. Like with all blink intents, we do our best to approach decisions with care. We review feature usage rates and other data before proceeding. The bar for removing features is actually incredibly high and a feature will only be removed if it's used by a very, very small proportion of users and if better alternatives are available. So you can track progress of features on Chrome status where you can also subscribe to updates, file bugs and find other resources. To track new features, you can also follow along with the Chromium blog and you can keep up with all blink intents by joining the BlinkDev discussion group. Now just be aware that that can result in a lot of emails. Alternatively, you might prefer to subscribe to a single intent. You can actually view a spreadsheet of blink intents at bit.ly slash blink intents and if you really, really like blink intents, you can even build on the automated blink intent tracker services. So that's how blink intents work. To find out more, take a look at our article and thanks for watching. Be sure to check out the other videos in the Chrome Concepts series.