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

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

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. 

A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing. We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS. In addition, since the time we released our HTTPS report in February, 12 more of the top 100 websites have changed their serving default from HTTP to HTTPS.

Studies show that users do not perceive the lack of a “secure” icon as a warning, but also that users become blind to warnings that occur too frequently. Our plan to label HTTP sites more clearly and accurately as non-secure will take place in gradual steps, based on increasingly stringent criteria. Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.

In following releases, we will continue to extend HTTP warnings, for example, by labelling HTTP pages as “not secure” in Incognito mode, where users may have higher expectations of privacy. Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.
   
We will publish updates to this plan as we approach future releases, but don’t wait to get started moving to HTTPS. HTTPS is easier and cheaper than ever before, and enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our set-up guides to get started.

Posted by Emily Schechter, Chrome Security Team