Though people speak of the ‘metaverse’—a vast network of interconnected virtual worlds—as a far flung future concept, in reality we already have the underlying structure built and functioning on a massive scale; it’s called the internet and it connects billions of us together. The only thing holding the internet back from becoming the metaverse is a way to step inside of it. Mozilla, it turns out, is working on the solution.


This guest article comes to us from two members of Mozilla’s MozVR research team:

Vlad-Vukicevic-mozvr-mozilla-virtual-realityVlad Vukicevic – Engineering Director | Mozilla Toronto | @vvuk

Vlad works on graphics and media components of the Web platform, including VR and WebGL. He’s also heavily involved in Mozilla’s Games efforts, and has helped bring high quality gaming to the Web.

joshua-carpenter-mozillaJosh Carpenter – UX Lead, MozVR | Mozilla San Francisco | @joshcarpenter

Josh works full time on the UX of web VR. His background is in motion graphics, visual design and architectural visualization, and he was previously UX Lead of Firefox OS.


What Needs to Happen to Make VR Native on the Web

The biggest things that we need are support for building native-feeling immersive VR sites, users who have access to the necessary hardware to experience VR, and finally a compelling reason for developers to create or adapt existing sites. These are all tied together, and we’re trying to make sure that we can make small steps along all of these fronts without blocking on any one of them. Ultimately, we want users to have a seamless, friction-free experience on the Web, whether browsing existing Web content or new VR content. We also want developers to have a clear path to creating new fully-immersive VR web sites as well as adding VR elements to their current sites. Finally, we want all of this to work on the widest possible range of hardware, as one of the strengths of the Web is its ability to scale from the lowest end mobile phones to the highest end desktops.

In more depth, there are several key areas that need to be addressed on the Web platform and browser side:

Support for Building and Viewing VR-optimized Websites in HTML and CSS

Our initial work with Web VR has focused on creating content using WebGL, which is a full 3D graphics API. WebGL is an incredibly powerful API, but it’s an API borrowed from the 3D world purely to enable high performance 3D graphics on the Web. While WebGL is a good place to get started with VR experiments on the Web, the lingua franca of the Web remains HTML+CSS: the languages we use to structure and lay out websites from Wikipedia to Reddit to Mozilla.org. They are ubiquitous, relatively easy to use, standardized, backwards compatible, etc. In order for the VR Web to take off, we need to enable Web developers to create VR experiences using these languages they already know.

See Also: Case Study – ‘Inspirit’ Creator Breaks Down Responsive WebVR Design

mozilla-firefox-virtual-reality-mozvr
Mozilla’s Josh Carpenter works on ‘Sechelt‘, a WebVR demo inspired by the work of Canadian painter Roy Henry Vickers

We also need to view and interact with HTML and CSS websites in virtual reality. For this, we will need to implement VR equivalents of scrolling, clicking links, zooming in, etc. And we will need to determine how to display desktop and mobile sites that were never designed for virtual reality. A historical analogue is Apple’s Mobile Safari browser, which successfully defined a system for displaying and interacting with classic desktop websites on 3.5-inch iPhone touch screens. It will be interesting to see what becomes the ‘pinch to zoom of VR’!

Improved User Experience for Web VR in Current Desktop and Mobile Browsers

In order for Web VR to be a functional part of the modern Web, desktop and mobile browsers will need to integrate a baseline of user interface support, in some cases updating long-standing security and interface conventions. In the case of Firefox Desktop, for example, fullscreen permission prompts appear when the user enters VR mode, because it is currently tied to the existing concept of fullscreen mode on the Web. These prompts need to be presented in a different way, if at all, when VR is concerned because the content will not be viewed on a normal display.

Widespread Adoption of WebVR APIs in Major Browsers

A key strength of the Web is its universality. Developers can—for the most part—create a single experience and rest assured that it will run on all modern browsers. For Web VR to achieve its full potential and be an enticing option for VR developers, as many browsers as possible will need to implement support for the new WebVR API (as well as implement the basic platform, performance and UX improvements outlined here). Currently the WebVR API is supported in Firefox Nightly and experimental builds of Chrome, and the first draft of the WebVR specification has been published by developers on both teams.

We view these improvements as baseline features required for VR to be a native mode of the modern Web. However, additional features and optimizations will be needed in order for the VR Web to flourish. We envision the following:

“VR Native” User Experience

WebVR is currently best supported on desktop browsers like Firefox Nightly, where it is experienced as a temporary mode within a traditional 2D browsing user interface. These interfaces were not designed with virtual reality in mind, and as a consequence we cannot “browse” inside VR.

We do not believe Web VR will take off until we can truly surf the Web from inside virtual reality, with the functionality we expect from modern browsers. We have begun this work with our early ‘Hiro’ prototypes, and we have many more ideas!

New VR-centric File Types, Elements and Attributes

The consumption of video is one of the most common use cases of the modern Web. HTML5 gives us the <video> and <audio> elements, which make it easy for Web developers to add media to their websites. For example, in order for VR video to take off on the Web, we may need to extend the <video> element to support the most common VR-video formats (e.g. mono, over-under, side-by-side), and design new VR versions of the standard video playback controls.

Native-like Performance

For VR to truly be a first class citizen on the Web, browsers need to be able to deliver VR content with performance that matches that of native applications. Refresh rates of 75Hz, 90Hz, and beyond will be common, and the need for efficient paths to communicate the most accurate sensor data will mean that browsers will need to improve in all of these areas. Work that Mozilla has been doing to bring high performance gaming to the Web via asm.js and other technologies shows that this is possible, and is essential to making the Web viable for VR content.

Expanded Device Support

As stated earlier, a key strength of the Web is its universality. Websites built in HTML and CSS run everywhere, browsers provide excellent backwards compatibility, and browsers abstract away hardware and OS complexity. Developers know their content will run everywhere, and generally either do not need to worry about optimizing for one operating system or another (e.g. Mac vs Windows), or when they do, have standardized mechanisms for doing so (e.g. CSS media queries enabling responsive design for various screen sizes). We want to ensure this is true in VR as well by growing WebVR support to as many platforms and VR devices as possible.

Continue to Page 2 “How We’re Making it Happen”

  • AJ@VRSFX

    A compelling reason to create or adapt existing sites… ha!

    Your website can be rendered in 3D. Need we say more? Mayamoto didn’t have a compelling reason to render Mario in 3D, except… 3D!

    The video game industry went 3D over night because… 3D!!!

    They made the leap as soon as they could figure out how. Rendering the digital world in 3D is just plain better as long as performance can handle it. Moore’s Law blessed the game industry with that leap 20 years ago. Our buddy Moore is about to do the same for the interwebs.

    I know, I know. The pragmatists need a compelling reason. We can’t all be freaky early adopters, but how about this? When our 3D websites are drawing more of the cool kid traffic than their 2D websites, how long will they hold out before giving in and making their website “responsive” to VR devices? I’ve seen this scenario somewhere before.

  • Don Gateley

    They have resources for this but my FF browser still crashes once a day on average. I think they need to get their priorities straight. I stay with FF only because of the Session Manager extension which doesn’t have anything close to a peer on any other browser.

    • AJ@VRSFX

      Axing R&D to hire more debuggers is like taking the cash you were saving for a shiny new Tesla Model III and spending it on a soup-to-nuts overhaul for your rusted old 1995 Ford Escort. Sure, the Escort looks like crap and it doesn’t run great, but soon you’ll be powered by sunshine and rainbows.