The Wayback Machine - https://web.archive.org/web/20201027094629/https://blog.chromium.org/2016/08/

From Chrome Apps to the Web

Friday, August 19, 2016

We have always believed in making the open, interoperable web as strong as possible. For a while there were certain experiences the web couldn’t provide, such as working offline, sending notifications, and connecting to hardware. We launched Chrome apps three years ago to bridge this gap.

Since then, we’ve worked with the web standards community to enable an increasing number of these use cases on the web. Developers can use powerful new APIs such as service worker and web push to build robust Progressive Web Apps that work across multiple browsers. More capabilities will continue to become available on the web.

As we continue our efforts to simplify Chrome, we believe it’s time to begin the evolution away from the Chrome apps platform. There are two types of Chrome apps: packaged apps and hosted apps. Today, approximately 1% of users on Windows, Mac and Linux actively use Chrome packaged apps, and most hosted apps are already implemented as regular web apps. We will be removing support for packaged and hosted apps from Chrome on Windows, Mac, and Linux over the next two years.

All types of Chrome apps will remain supported and maintained on Chrome OS for the foreseeable future. Additional enhancements to the Chrome apps platform will apply only to Chrome OS devices, including kiosks. Developers can continue to build Chrome apps (or Android apps) for Chrome OS.

Starting in late 2016, newly-published Chrome apps will only be available to users on Chrome OS. Existing Chrome apps will remain accessible on all platforms, and developers can continue to update them.

In the second half of 2017, the Chrome Web Store will no longer show Chrome apps on Windows, Mac, and Linux, but will continue to surface extensions and themes. In early 2018, users on these platforms will no longer be able to load Chrome apps.

On Windows, Mac, and Linux, we encourage developers to migrate their Chrome apps to the web. Developers who can’t fully move their apps to the web can help us prioritize new APIs to fill the gaps left by Chrome apps. In the short term, they can also consider using a Chrome extension or platforms such as Electron or NW.js.

As the capabilities of the web continue to grow, we're excited to see what developers build next. Alongside other browser vendors, we remain committed to investment in the web and enabling users and developers to benefit from its openness and reach.

Update on December 5, 2017:

Chrome Apps will be removed from Chrome Web Store search & browse functions in mid-December 2017. Existing apps will continue to work and receive updates.

The Chrome browser will continue to load packaged and hosted apps on Windows, Mac, and Linux beyond the previously announced deprecation timeline. Another update will be posted here when a new date for the Chrome Apps EOL on Windows, Mac, and Linux has been finalized.

Posted by Rahul Roy-Chowdhury, VP Product Management

Chrome 53 Beta: Shadow DOM, PaymentRequest, and Android autoplay

Monday, August 8, 2016

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Shadow DOM V1

HTML, CSS, and JavaScript are powerful development languages, but they can be difficult to maintain in large code bases. Sites that embed third-party content also need to ensure that included styles do not affect other parts of their app. Chrome 53 supports Shadow DOM V1, which allows an element to encapsulate its style and child DOM away from the main document. This improves the maintainability of large or composed sites. Shadow DOM V1 has some significant changes from the V0 version, and is broadly agreed-upon by major browser vendors. Chrome will support both versions of the API until enough developers have moved to V1. The behavior of a shadow root is determined by which API call it was created with.

PaymentRequest API

Completing payments on the web can be a cumbersome process for users, leading to lower conversions on sites. While autofill has made it easier to enter information, efficient data entry on mobile is still a challenge. PaymentRequest allows for fast, seamless, and secure payments on the web using a credit card or Android Pay. It also lets users provide a billing address, shipping details, and payer information without typing. PaymentRequest is available on Chrome for Android, with support for more platforms coming soon.

Chrome for Android autoplays muted video

Video is a great way for sites to reach their users, but it can be jarring when it plays unexpectedly. This is especially true on mobile, where the user may be in an environment where audio is unwanted. Chrome on Android now allows muted videos to begin playing without user interaction. If the video was marked as muted and has the autoplay attribute, Chrome will start playing the video when it becomes visible to the user. Developers can also use script to play muted videos without user interaction. Muted videos that begin playing sound before a user action will automatically be paused.

Other features in this release

Sites that send notifications to Android devices running Android 6.0 (Marshmallow) or later may now provide a badge to show in the status bar in place of the Chrome logo.
Notification objects now provide getters for reading the notification action buttons and vibration pattern.
Cross-origin plugin content smaller than 5x5 pixels no longer loads for users that have set "Detect and run important plugin content."
The allow-presentation sandbox flag allows sites to control whether an iframe can present to external devices.
pattern attribute values on input elements now use the unicode flag, improving syntax checking and other regular expression ergonomics.
3D-positioned elements will be flattened if an ancestor has opacity less than 1.
To prevent visual artifacts, all content will be re-rastered when its transform scale changes unless it has the will-change: transform CSS property.
Low-pass and high-pass biquad filters now support more filter characteristics.
--webkit-filter is now an alias for the unprefixed filter property and will behave identically instead of having separate behaviors.
--webkit-user-select now supports an all property which forces a selection to contain an entire element and all its descendants.
The Web Bluetooth API is available experimentally on some platforms as an origin trial, allowing sites to communicate with nearby devices using the Bluetooth Generic Attribute Profile (GATT).

Deprecations and interoperability improvements

Events generated by script will no longer trigger default actions, improving spec compliance and browser interop.
HTTP/0.9 has been deprecated in favor of HTTP/1.0, which adds response header support.
TLS Diffie-Hellman ciphers have been removed, following their deprecation in M51 due to security concerns.
The TextEncoder API no longer accepts arguments and will instead always encode using utf-8.
Due to recent security issues, new certificates issued by Symantec Corporation or by CAs that chain to Symantec Corporation will no longer be trusted in Chrome unless accompanied with Certificate Transparency information.

Posted by Hayato Ito, Shadow DOM Chaffeur