Chromium Blog: February 2016

Transitioning from SPDY to HTTP/2

Thursday, February 11, 2016

serversHTTP/2 RFCupgrading their SSL libraryUpdate: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.

Posted by Bence Béky, Network Protocol Engineer and HTTP/2 Enthusiast

The Physical Web expands to Chrome for Android

Wednesday, February 10, 2016

The Physical Web helps users discover URLs relevant to their surroundings via initial step in supporting the Physical Web, and the community has already begun exploring promising applications. Starting in version 49, Chrome for Android will also surface Physical Web content, making these experiences available to an even larger audience.
As deployed 1,500 beacons to help attendees of CES® (Consumer Electronics Show) navigate showrooms. The Golden State Warriors utilize the Physical Web with the help of Signal360 to provide fans with highlight videos and welcome content at Oracle Arena.

Physical Web bluetooth beacons enabled a scavenger hunt at CES® 2016.
Now, Physical Web developers can reach Chrome for Android users as well, starting with the Beta channel and rolling out more widely soon. When these users walk by a beacon for the first time, they’ll receive a notification allowing them to enable the Physical Web. On future encounters with beacons, users can quickly see a list of nearby URLs by tapping on a non-vibrating notification waiting for them.

Physical Web experience on Chrome for Android
Developers can make their web content discoverable on the Physical Web by configuring an Eddystone-URL frame type. Now that the Physical Web is tightly integrated into Chrome for Android, a single deployment can deliver contextual information to Chrome users across multiple mobile platforms.
As we continue to improve the Physical Web experience, we’re excited to see what types of contextual experiences developers build. We encourage anyone to join the conversation on our Physical Web cookbook to learn more about what’s possible. Posted by Ani Mohan, Physical Web Voyager

Chrome 49 Beta: CSS custom properties, background sync with service workers, and new ES2015 features

Tuesday, February 2, 2016

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.
CSS custom properties Modern websites often have CSS files with repeated values, such as a few colors reused throughout the page in a color scheme. Altering this data can be tedious and error-prone, since it’s scattered throughout one or more CSS files. To improve this, Chrome now supports reference these custom properties anywhere in the document.
Changing a custom property can update multiple components in a website
CSS custom properties also inherit across simplify customizing components.
Background sync with service workers Previously, sites could lose local changes or become out of sync if a user didn’t stay on the site until updates could be sent over the network. For example, an email client might lose a pending message if the user hit "send" and quickly navigated away. The new a one-off sync of a user’s local changes when the device next connects to the network, even if the site isn’t open.
Improved ECMAScript 2015 support The destructuring and Proxy objects and the Reflect API can customize previously hidden object behavior such as property lookup and assignment. The latest version of Chrome also makes block-level constructs such as strict mode.
Keygen and application/x-x509-user-cert The <keygen> element is used to generate a key-pair as part of an HTML form. While this can be used to enhance user security, <keygen> and user certificates sent with the MIME type of application/x-x509-user-cert can be exploited to disrupt a user’s secure communication, interfere with the functioning of their devices, or track the user without consent. Going forward, <keygen> will return an empty string by default and user certificates sent with the MIME type of application/x-x509-user-cert will no longer be automatically downloaded and installed.
Other features in this release

With user consent, sites can MediaRecorder API.

Developers can now CSS font-display, improving page load speed.

Sites can now detect which service worker client initiated a fetch request and return a specialized response using the FetchEvent.clientID attribute.

Chrome now smoother user experience.

Chrome now more strictly cookie prefixes.

Sites can now prevent media from playing remotely Remote Playback API.

Event.timeStamp is now a pointer velocity measurements.

Promise rejection handling can now be tracked using the UnhandledRejection and RejectionHandled events.

Developers can now URLSearchParams.

The DecodeAudioData.

service workers to navigate controlled windows to a new URL.

Sites can detect if a user has requested reduced data usage and respond with a lighter experience by checking the Save-Data header field.

Minor changes

Chrome’s content security policy now matches ‘script-src http:’ to both HTTP and HTTPS, preventing developers from accidentally rejecting secure resources.

The supports a navigate mode, improving spec compliance.

Developers now have the option to ignore case when matching attribute selectors.

Developers can now create pop-ups that don’t expose which page opened them using 'rel=noopener'.

addEventListener() and removeEventListener() now require their first two arguments and can have the "capture" option specified using dictionary syntax, improving spec compliance and flexibility.

Chromium now supports the standardized version of ChaCha-Poly1305 cipher suites in TLS.

Navigator.getStorageUpdates() has been removed as it is no longer in the Navigator spec.

MouseEvent.webkitMovementX/Y has been removed in favor of the unprefixed version.

TouchEvent constructor to improve spec compliance and will be removed altogether in Chrome 53.

Object.observe() has been deprecated as it is no longer on the standardization track and will be removed in a future release.

The spec.

Some non-standard uses of RTCPeerConnection legacy methods have been deprecated to enable promise-based implementation of the WebRTC spec.

Document.defaultCharset has been deprecated to improve spec compliance.

Posted by Josh Karlin, Syncing Samurai

Chromium Blog

Transitioning from SPDY to HTTP/2

The Physical Web expands to Chrome for Android

Chrome 49 Beta: CSS custom properties, background sync with service workers, and new ES2015 features

Labels

Archive

Feed