[go: up one dir, main page]

Virtual Reality (VR) is rapidly growing in popularity, and now it's coming to the web. The power of the web is that it can allow VR to work across browsers and hardware, accessible via a single click. This enables VR developers to broadly reach users across multiple types of headsets with a single web app. Here’s how to get started.
Chrome 56 for Android is now available in beta, and web developers can sign up for an Origin Trial which enables the WebVR API and GamePad API extensions. The WebVR API provides access to the input and output capabilities of virtual reality devices such as Daydream View. It also provides access to the user’s position and orientation, so that web apps can render a stereoscopic 3D scene to the headset's display. The Gamepad API extensions provide access to input from motion controllers, such as the Daydream controller, and enables natural interactions in VR.
Origin Trials allow a developer to temporarily enable the feature for all Chrome users visiting their website. The WebVR API is still evolving and will undergo further changes based on developer feedback before being enabled by default for all pages. WebVR will be extended to desktop platforms and Google Cardboard in a future Chrome release, and several performance improvements are coming in Chrome 57.
To learn how to get started and build your first WebVR web app, visit the WebVR developer site for tutorials and samples. Join the conversation by giving feedback on the API or the Chrome implementation and joining the WebVR Slack channel.
Posted by Brandon Jones, Virtual Reality Plumber

Four months ago we announced that we’d be moving to HTML5 By Default to offer a safer, more power-efficient experience. As a reminder, this change disables Adobe Flash Player unless there’s a user indication that they want Flash content on specific sites, and eventually all websites will require the user’s permission to run Flash. To ensure a smooth transition, not all users and sites will be affected immediately. HTML5 by Default and the associated user prompts will be introduced gradually as follows.
The feature will be rolled out to users over a few months. HTML5 By Default will be enabled for 1% of users of Chrome 55 Stable in the next few days. The feature is also enabled for 50% of Chrome 56 beta users. With Chrome 56 stable in February, we plan to enable it for all users.
Starting in January users will be prompted to run Flash on a site-by-site basis for sites that they have never visited before. We want to avoid over-prompting users, so over time we’ll tighten this restriction using Site Engagement Index, a heuristic for how much a user interacts with a site based on their browsing activity. In October all sites will require user permission to run Flash.
More details, including specific Site Engagement Index thresholds, are available on the Flash Roadmap Page. Developers can find recommendations on how to test their Flash sites there as well. As sites transition from Flash to HTML5, this change will no longer affect them and the entire web will become faster, more secure and power-efficient.
Posted by Eric Deily, wrangler of the Default

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


“Not Secure” warning for HTTP password and credit card pages


To help users browse safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Starting in version 56, Chrome will 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. The feature will roll out gradually over the next few weeks.

To avoid being labeled insecure, sites should secure their traffic with HTTPS and follow general security guidelines.

Chrome ‘Not Secure’ warning appearing in the URL bar for a site with an HTTP connection  

Web Bluetooth

Sites can now interact with Bluetooth Low Energy (BLE) devices using the Web Bluetooth API on Android, Chrome OS, and Mac. The Web Bluetooth API uses the GATT protocol, which enables web developers to connect to bluetooth devices such as printers and LED displays with just a few lines of JavaScript. Web Bluetooth can also be combined with Physical Web beacons to discover and control nearby devices. To get started, check out these samples and demos on GitHub.  

heart.gif
An Android device connecting to a BLE-enabled heart rate monitor via the web (source)

CSS position: sticky

Chrome now supports CSS position: sticky, a new way to position elements. A position: sticky element is relatively-positioned, but becomes position: fixed after the user reaches a certain scroll position.

Previously, building content headers that scrolled normally until sticking to the top of the viewport required listening to scroll events and switching an element’s position from relative to fixed at a specified threshold. This solution was difficult to synchronize, resulting in small visual jumps. Now, users can achieve the desired effect by simply positioning their elements as sticky.


Other features in this release
  • Showing and hiding the URL bar on mobile no longer resizes the initial containing block or elements sized with viewport units such as vh.
  • Text input elements such as <input type="text"> now have spell-checking enabled by default on Android devices with at least 512 MB of memory and a system dictionary.
  • The generic font family used to fit content within the UI has been standardized and renamed as system-ui on all platforms.
  • The new Referrer-Policy HTTP header allows sites to forward site traffic by URL without leaking the user’s session identifier or other private information.
  • KeyboardEvent.isComposing() allows sites to determine if the user is typing based on recent KeyboardEvents, without monitoring keyboard events directly.
  • Chrome for Android now sets the default preload attribute for videos to metadata on cellular connections, showing a preview image and time information to match other mobile browsers.
  • Chrome now supports TLS 1.3 and includes 1-RTT based on draft-18.
  • Sites can use ImageBitmapRenderingContext to reduce memory consumption and compositing overhead by rendering pixel data in the form of an ImageBitmap.
  • Sites can respond to pinch gestures using the pinch-zoom CSS touch-action property.
  • ConstantSourceNode is a new audio source node that produces a constant output mixed with an AudioParam.
  • Two Web Audio ChannelSplitterNode Interface attributes are now read-only: channelCount, which is defined by numberOfOutputs in createChannelSplitter(), and channelCountMode, which is set to explicit.
  • PannerNode.rolloffFactor now clamps to the nominal range of a PannerNode’s distance model to describe the volume reduction rate as the source moves away from the listener.
  • window.prompt() will no longer focus its parent tab if the page is not currently in the foreground, and the dialog will be automatically dismissed.
  • To match behavior on Windows, Chrome Extensions can now override default search, startup, and homepage settings on Mac with the Chrome Settings Overrides API.
  • Support for FLAC is enabled within the FLAC and Ogg containers for the <audio> tag and decodeAudioData().
  • OPUS can now be used with decodeAudioData(), expanding the variety of audio codecs supported by the WebAudio API.

Deprecations and interoperability improvements
  • The WebAudio API no longer includes the deprecated Doppler API, including speedOfSound, dopplerFactor, and setVelocity.
  • To improve standards conformance, RTCPeerConnection now accepts iceTransportPolicy as an RTCConfiguration parameter as well as iceTransports.
  • RTCPeerConnection is now available without a webkit prefix, though webkitRTCPeerConnection still remains.
  • Non-whitespace unicode control characters will now be rendered according to the specification, rather than being ignored.
  • The reflected-xss directive has been removed from Content Security Policy 2 since it was solely a wrapper for the X-XSS-Protection header and provided no additional functionality.
  • Support for the MediaStreamTrack.getSources() method has been removed in favor of MediaDevices.enumerateDevices().
  • The CSP referrer directive is no longer supported in favor of the new Referrer-Policy header.
  • ShadowDOM’s slotchange events bubble, but no longer re-fires, at a slot's assignedSlot.  
  • Legacy CBC-mode ECDSA cipher suites ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_256_CBC_SHA have been removed in favor of modern ciphers such as ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
  • ECDSA with both SHA-1 and SHA-512 have been removed to reduce dependencies on SHA-1 and align with TLS 1.3's new ECDSA handling.
  • Chrome no longer allows opening of pop-ups during inputs which represent a touch scroll, such as touchstart and touchmove.
  • Sites will no longer initiate fetches for scripts with invalid type or language attributes, such as type="python", unless triggered by declarative fetches using link preload.
  • MIDIMessageEvent.receivedTime has been deprecated in favor of Event.timeStamp, since Event.timeStamp now supports high-resolution monotonic time instead of epoch time.

Posted by Vincent Scheib, Web Bluetooth Orthodontist
Labels: