Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

Thursday, September 15, 2016

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

Custom Elements V1 Complex user interfaces often require a large amount of HTML. Most languages allow developers to create their own components built on top of language primitives to mitigate this kind of verbosity. Custom elements allow developers to create their own custom HTML tags, and define the new element’s API and behavior in JavaScript. This enables a browser-native way to build reusable, interoperable components.
Chrome 54 provides support for the latest custom elements V1 spec, which is broadly agreed-upon by major browser vendors. Chrome will also continue to support the V0 API until enough developers have moved to V1.

BroadcastChannel It is not uncommon for desktop users to have multiple windows or tabs open simultaneously. Some sites utilize this behavior, such as web editors that open documents in their own tabs. Historically, communicating between those tabs has been difficult. BroadcastChannel is a new one-to-many messaging API between windows, tabs, iframes, web workers, and service workers. It allows scripts to establish named channels to send messages between browsing contexts of the same origin.

Media platform improvements on Chrome for Android Media is an increasingly large and important part of the browsing experience on mobile devices that requires fluidly utilizing the entire screen. Developers can now use Element.requestFullScreen() to trigger full screen mode after a screen orientation change in addition to after a user gesture. This allows experiences like rotate-to-fullscreen for media players.
In addition to fullscreen improvements, Chrome on Android now persists the media notification of a backgrounded HTMLVideoElement, allowing a user to continue playing videos while they aren’t visible. Developers can detect background video playback by using the Page Visibility API.
Playing background videos in Chrome 54.

Other features in this release

Navigations initiated in an unload handler will be blocked and any prior navigation will continue.

The imageSmoothingQuality attribute for CanvasRenderingContext2D allows developers to balance performance and image quality by adjusting resolution when scaling.

Sites can use Node.getRootNode(options) to obtain the root for a given node.

Using PushSubscription.options, sites can track applicationServerKeys without having to store them offline.

The Resource Timing API now supports transfer, encoded, and decoded size attributes, allowing developers to measure cache hit rates and byte usage.

The user-select property enables developers to specify which elements can be selected by the user and how.

Foreign Fetch and WebUSB are available for experimentation as origin trials.

The text-size-adjust property allows sites to control whether font size automatically scales on mobile devices.

Deprecations and interoperability improvements

To match behavior in other browsers, embedded YouTube Flash players will be rewritten by Chrome to use the HTML5 embed style, improving performance and security on Chrome Desktop.
CacheQueryOptions now conforms to spec across all CacheStorage methods.
initTouchEvent has been removed in favor of the new TouchEvent() constructor.
SVGZoomEvent has been removed as it is no longer part of the SVG 2.0 spec.
SVGSVGElement.currentView, SVGSVGElement.useCurrentView, SVGViewSpec interface, and SVGSVGElement.viewport have been removed as they are no longer part of the SVG 2.0 spec.
SVGTests.requiredFeatures attribute has been deprecated since it no longer provides useful functionality in the SVG 2.0 spec.
SVGElement now supports the dataset property.
The KeyEvent.keyIdentifier field has been removed in favor of the KeyboardEvent.key field.
window.external.IsSearchProviderInstalled() and AddSearchProvider() are now no-ops, since they are unsupported in most other browsers.

Posted by Marijn Kruisselbrink, Broadcast Buccaneer

Moving Towards a More Secure Web

Thursday, September 8, 2016

To help users browse the web safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure.

Chrome currently indicates HTTP connections with a neutral indicator. This doesn’t reflect the true lack of security for HTTP connections. When you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you. released our HTTPS reportdo not perceiveOur plan

easier and cheaper than ever beforebestperformancepowerfulnewfeaturesset-up guidesPosted by Emily Schechter, Chrome Security Team

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.

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

Universal rendering with SwiftShader, now open source

Wednesday, June 29, 2016

SwiftShader is a software library for high-performance graphics rendering on the CPU. Google already uses this library in multiple products, including Chrome, Android development tools, and cloud services. Starting today, SwiftShader is fully open source, expanding its pool of potential applications.

Since 2009, Chrome has used SwiftShader to enable 3D rendering on systems that can’t fully support hardware-accelerated rendering. While 3D content like WebGL is written for a GPU, some users’ devices don’t have graphics hardware capable of executing this content. Others may have drivers with serious bugs which can make 3D rendering unreliable, or even impossible. Chrome uses SwiftShader on these systems in order to ensure 3D web content is available to all users.

Chrome running without SwiftShader on a machine with an inadequate GPU (left) cannot run the WebGL Globe experiment. The same machine with SwiftShader enabled (right) is able to fully render the content.

SwiftShader implements the same OpenGL ES graphics API used by Chrome and Android. Making SwiftShader open source will enable other browser vendors to support 3D content universally and move the web platform forward as a whole. In particular, unconditional WebGL support allows web developers to create more engaging content, such as casual games, educational apps, collaborative content creation software, product showcases, virtual tours, and more. SwiftShader also has applications in the cloud, enabling rendering on GPU-less systems.

To provide users with the best performance, SwiftShader uses several techniques to efficiently perform graphics calculations on the CPU. Dynamic code generation enables tailoring the code towards the tasks at hand at run-time, as opposed to the more common compile-time optimization. This complex approach is simplified through the use of Reactor, a custom C++ embedded language with an intuitive imperative syntax. SwiftShader also uses vector operations in SIMT fashion, together with multi-threading technology, to increase parallelism across the CPU’s available cores and vector units. This enables real-time rendering for uses such as app streaming on Android.

Developers can access the SwiftShader source code from its git repository. Sign up for the mailing list to stay up to date on the latest developments and collaborate with other SwiftShader developers from the open-source community.
Posted by Nicolas Capens, Software Engineer and Pixel Pirate

Chromium Blog

Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

Moving Towards a More Secure Web

From Chrome Apps to the Web

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

Universal rendering with SwiftShader, now open source

Labels

Archive

Feed

Company-wide

Products

Developers