Chromium Blog: 2019

Chrome 80, Content Indexing, ES Modules and More

Thursday, December 19, 2019

ChromeStatus.com Content Indexing

IndexedDBExperimenting with the Content Indexing API ECMAScript Modules in Web Workers importScripts()type"module"<script type="module">const worker = new Worker('worker.js', { type: 'module' });ES Modules in Web Workers Origin TrialsOrigin Trials Guide for Web Developers New Properties for the Contact PickerContact Picker API'address''icon' Other features in this release Autoupgrade Mixed Contentauto-upgrading HTTP content in HTTPS sites Compression Streamsperform gzip and deflate compressionCompressionStreamDecompressionStream Contact Picker APIOrigin Trials Cookie updatesSameSite cookies explained Disallow defaulting of SameSite attribute to 'None' Value 'None' no longer allowed on insecure contexts CSS Improvements line-break: anywhereUAX 14) or mandated by the word-break property.

overflow-wrap: anywhere

The overflow-wrap: anywhere declaration allows an otherwise unbreakable sequence of characters to be broken at an arbitrary point if there are no otherwise-acceptable break points in a line. Additionally, soft wrap opportunities introduced by anywhere are considered when calculating min-content intrinsic sizes.

Decoding Encrypted Media

The capabilities of

multiple browsers) allows websites to get more information about the decoding abilities of the client. This enables more informed selection of media streams for the user, enabling scenarios such as smoothly and power-efficiently decoding a video for the available bandwidth and screen size.


Delegating Shipping Address and Contact Information in Web Payments
The Payment Handler API now subscribe to paymentrequest@chromium.org.


Fetch Metadata Destination header
Chrome now supports the a list of its possible values.


HTMLVideoElement.getVideoPlaybackQuality()
This method retrieves information about video playback performance. Such information may be used to alter bitrate, framerate, or resolution, either upward or downward, to provide a better user experience.


JavaScript optional chaining
Provides safe access to descendent object members with parents that may or may not be null. This applies to objects as well as functions. For example, consider an object reference with three levels such as a.b.c. Testing for the existence of c would previously require nesting said test inside a test for b. This change allows you to test for c directly without an error being thrown when b is null.


Nullish coalescing
Adds support for the 'nullish' operator to JS.


Offscreen Canvases Now Support getTransform()
The OffscreenCanvasRenderingContext2D CanvasRenderingContext2D counterpart, this method lets you retrieve the transformation matrix that is currently applied to the context.


Support for SVG in favicons
Chrome now supports using SVG images as favicons. Scalable formats for favicons reduce the resources for a website or app. For example, a website could have one (or more) hand-tuned icons for small sizes and use a scalable icon as a catch-all.


Text URL Fragments
Users or authors can now link to a specific portion of a page using a text fragment provided in a URL. When the page is loaded, the browser highlights the text and scrolls the fragment into view. For example, the URL below loads a wiki page for 'Cat' and scrolls to the content listed in the text parameter.



https://en.example.org/wiki/Cat#:~:text=On islands, birds can contribute as much as 60% of a cat's diet




Deprecations, and Removals
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of previous removals. The descriptions here are just a summary of what's being deprecated and removed. You can find longer descriptions of all these items and replacements and remediations in Deprecations and removals in Chrome 80.


Disallow Popups During Page Unload
Pages may no longer use the window.open() method to open a new page during unload. The popup blocker already prohibits this, but now it is prohibited whether or not the popup blocker is enabled. For now, enterprises can use the AllowPopupsDuringPageUnload policy flag to allow popups during unload. Chrome expects to remove this flag in version 82.


Disallow Synchronous XMLHttpRequest() in Page Dismissal
Chrome now disallows synchronous calls to XMLHttpRequest() during page dismissal when the page is being navigated away from or is closed by the user. This applies to beforeunload, unload, pagehide, and visibilitychange.



To ensure that data is sent to the server when a page unloads, Chrome recommends sendBeacon() or Fetch keep-alive. For now, enterprise users can use the AllowSyncXHRInPageDismissal policy flag and developers can use the origin trial flag allow-sync-xhr-in-page-dismissal to allow synchronous XMLHttpRequest() requests during page unload. This is a temporary opt-out measure. Chrome expects to remove this flag in version 82. 



For details about this and the alternatives, see Improving page dismissal in synchronous XMLHttpRequest().


FTP Support Deprecated
Chrome has been removing capabilities from its FTP support since version 72. The reason for this is that usage of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client. In addition, more capable FTP clients are available on all affected platforms. In Chrome 80, the client's capabilities are restricted to either displaying a directory listing or downloading a resource over unencrypted connections. For more information, see Deprecations and removals in Chrome 80.


Non-origin-clean ImageBitmap serialization and transferring removed
Starting in Chrome 80, errors are raised when a script tries to serialize or transfer a non-origin-clean ImageBitmap object. A non-origin-clean ImageBitmap is one that contains data from cross-origin images that are not verified by CORS logic.


Protocol handling now requires a secure context
The methods registerProtocolHandler() and unregisterProtocolHandler() now require a secure context. These methods are capable of reconfiguring client states such that they would allow transmission of potentially sensitive data over a network. 


Remove -webkit-appearance:button for arbitrary elements
Changes -webkit-appearance:button to work only with <button> and <input> buttons. If button is specified for an unsupported element, the element has the default appearance. All other -webkit-appearance keywords already have this restriction. 


Web Components v0 removed
Web Components v0 are now removed from Chrome. The Web Components v1 APIs are a web platform standard that has shipped in Chrome, Safari, Firefox, and (soon) Edge. For guidance on upgrading, read Web Components update: more time to upgrade to v1 APIs. This deprecation covers the items listed below. 


Custom Elements v0
HTML Imports v0
Shadow DOM v0

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 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”? 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.

Chrome Dev Summit 2019: Elevating the Web Together

Monday, November 11, 2019

As the largest open ecosystem in history, the Web is a tremendous utility, with more than 1.5B active websites on the Internet today, serving nearly 4.5B web users across the world. This kind of diversity (geography, device, content, and more) can only be facilitated by the open web platform.
Users uniquely experience the Web as one as they navigate from site to site, and thus the responsibility is with all of us to work on delivering quality experiences that reach all.
At this year’s Chrome Developer Summit (CDS), we are focusing on giving developers the capabilities to reach the bar that our users demand. To help further foster the diversity and capability for web developers, we’ve been working closely with the ecosystem to make enhancements to the web platform, improve developer experience, and make meaningful updates to the browser itself.

Enhancing the versatility of the Web
Our vision is to make loading disappear for all our users. At I/O this year, we previewed Portals, which allows developers to create seamless experiences by pre-rendering content and optionally embedding it in the page to change the way users navigate across the web. We’re pleased to see the new style navigation from early partners like Fandango have been testing on their site already. Portals is available behind the chrome://flags/#enable-portals flag for developers to experiment with.
At CDS this year, we’re previewing Background Periodic Sync and Content Indexing will allow developers to proactively cache and surface relevant web content for people even if they’re not on an active internet connection. Web Bundles is now available behind the experimental flag, and the other two are now available as origin trials.
Consumption of web content has never been more diverse; while the rise of mobile-first in developing markets has been well documented, we’re now seeing an increase in cross-device computing with the youth across the globe. We’re committed to making the platform powerful enough for developers to create amazing modern experiences that users expect while taking advantage of the frictionless of the web. By focusing our efforts on enabling fully capable web applications, we’ve been working to bring many primitives to the platform, including:

SMS Receiver, allowing web apps to retrieve two-factor SMS messages.

Contact Picker, which will allow people to share web content to their contact lists, bringing social media and communication capabilities to web apps.

Native File System API, enables web apps to read or save changes directly to files and folders on the user's device. This allows developers to build powerful web apps that interact with files on the user's local device, like IDEs, photo and video editors, text editors, and more.

There’s a lot more that we’re working on in this space and we can’t wait to see what you build with these capabilities. You can read all about our latest work in our blog on supporting new web experiences.

Enabling developer success no matter the framework or CMS
As web developers, we’re on a collective journey providing people their best, unique web experience. This collective responsibility makes accurate, actionable data on the health of the web increasingly important.
CDS gives us a checkpoint to see how we are doing and have a discussion on where we go next. We use the HTTP Archive to see how the web is built and the First Input Delay, our core metrics for loading and interactivity.
Measuring user experience quality is multi-faceted, today we introduced two new metrics to give developers a holistic view of how their sites are performing. Cumulative Layout Shift (how stable a page feels).
Now, data is great, but insights that lead to fixes and improvements are better. We often get asked “What do I do with this information?” We’ve collaborated with many experts from the community on The Web Almanac, to give developers a holistic view of the health of the web. We launched over 17 chapters today and we’re excited to continue to identify and share more such insights.

Developers work incredibly hard to move their performance metrics in the right direction, so we are looking at ways to reward developers for going the extra mile. Today we are sharing some early explorations which surface speed signals in Chrome’s UI.

Frameworks, libraries and CMS’es form a critical part of the developer ecosystem and we’re keen to support them on their journey of creating instant and seamless for their users. Earlier this year we created Lighthouse Stack Packs for WordPress and React to support their developer ecosystems in build fast and reliable sites, and today we’ve increased the coverage include Angular, AMP as well as the ecommerce CMS, Magento, bring more actionable insights to developers irrespective of the tools developers use.
We’ve been excited to see that the Framework Fund has supported a number of meaningful projects that make it easier to hit the performance bars by default, and we’re looking forward to seeing more projects being funded this year.
Finally, we have launched Lighthouse CI to make sure that developers are given insights for each pull request. Developers can quickly hook up Lighthouse CI to their build pipeline to get a rich diff of the changes that they made and the impact it had on the quality of their site.

Making the browser work for you
We believe the web is for everyone, no matter their device type, internet speed or purchasing power. To help ensure the platform remains accessible to all, we’re investing in performance and memory improvements to the browser, including bringing new features like Image Lazy Loading that is now going to be available to Paint Holding, shipping soon in Chrome.
The web needs to be a safe and trustworthy place for everyone. Furthering our initiatives around HTTPS encryption, we began working with the community to start DNS over HTTPS, which offers better security and privacy by encrypting the traffic between the browser and DNS provider
We are also following up on our I/O promise to make our existing third-party cookie controls more visible. Starting with the Chrome M79 Beta, we’re experimenting with a toggle for controlling third-party cookies on the Incognito New Tab Page. We are also working on redesigning our settings pages to make access to this control easier in regular mode. And finally, apart from continuing to make progress to improve the existing cookies infrastructure, we’re also continuing to develop our Privacy Sandbox, a secure environment for content that also protects user privacy.
We want to thank the entire web community for their continued investment in a platform that is so impactful to so many people around the world. We believe it is our collective responsibility to elevate the web experience for every user and in that spirit, let's celebrate the 'We' in Web.
Posted by Dion Almaer, Web Developer Ecosystem

Chromium Blog

Chrome 80, Content Indexing, ES Modules and More

Intent to Explain: Demystifying the Blink Shipping Process

Chrome Dev Summit 2019: Elevating the Web Together

Labels

Archive

Feed