Opera Core Concerns

Official blog for Core developers at Opera

Subscribe to RSS feed

Posts tagged with "W3C"

CORS goes mainline

, , , ...

About 6 years ago Opera's Anne van Kesteren started working on a spec called "Access Control", which had been used in VoiceXML to allow limited cross-site access for cases where that didn't pose a security problem. After many years of working on the spec, in Opera, and with other browser developers, it is something the Web is starting to adopt - a real standard, now called CORS. Although it is still formally a working draft, it has been stabilising and getting deployed in test applications so we don't expect it to change a lot now.

This week, Opera integrated support for it into the core mainline, meaning it can start to be adopted in product builds - so look for it soon in a snapshot near you.

Read more...

Native webcam support and orientation events - technology preview

, , , ...

UPDATE: We have released newer experimental builds with webcam support for both Opera Desktop on Mac/Linux/Windows and Opera Mobile on Android. You can get more information and download these builds here.

---

Last week we wrote a blog post discussing our internal prototyping of web camera streaming in the browser. On the very same day, the proposed standard interface on which that was built changed considerably.

This week we are pleased to announce the release an updated preview build of Opera Mobile for Android enabling web developers to access and interact natively with a device's webcam via JavaScript. This build has been entirely re-based on the new standards proposal introduced last week so it's goodbye to the <device> element and a big warm hello to the getUserMedia JavaScript API.

Read more...

Web, meet the <device> element (and orientation events)

, , , ...

Recently we've been prototyping on Opera Mobile for Android to add support for both the HTML <device> element and the W3C's proposed orientation events specification.

In our first internal build, web developers are able to access, display and interact in real-time with a user's web camera using native HTML features.

Read more...

Everything you need to know about HTML5 video and audio

, , , ...

Hi, I'm Simon Pieters, and I'm working with Quality Assurance for HTML5 video and audio at Opera.

Opera 10.50 has now been released on Windows, and it supports the HTML5 video and audio elements. But how do you use them? Introduction to HTML5 video covers a general introduction but doesn't go into the details; Accessible HTML5 Video with JavaScripted captions shows how captions can be implemented until the spec gains proper support for captions; and (re-)Introducing <video> has some information on Opera's implementation. I recommend reading all three!

This article aims to provide all the nitty-gritty details of HTML5 media, the DOM API, events, and so forth, so you can implement your own HTML5 player with fallback to old browsers.

Read more...

Geolocation-enabled build

, ,

We are delighted to release the first build of Opera with geolocation support. The geolocation Working Group of the W3C has recently relased the first Working Draft of the geolocation API specification, and we are now releasing the first Labs build with support for the API.

The API is used in a web page's Javascript code to retrieve the current latitude and longitude of the browser. The following snippet shows how a web page would request the browser's location:

// One-shot position request:
navigator.geolocation.getCurrentPosition(showMapCallback);

function showMapCallback(position) {
  // Show a map centered at (position.coords.latitude, position.coords.longitude).
}

As you can see, the API is very simple, and doesn't get much more complicated with more advanced functionalities (see more examples from the specification)

Geolocation on the web is not new. Many sites already use the IP address of the browser to serve targetted content, mostly ads (you will have seen the 'Find a Friend in [your city]' banners). However, that method is notoriously inaccurate and cannot be reliably used for more advanced geolocation services. On the other hand, the device which the browser is running on is more likely to have an accurate idea of its location if it has a GPS unit or can triangulate the wireless access points or cell towers, or look up its IP address. Even if the device doesn't have the right hardware, a location provider web service can be used. This build uses the Skyhook service, and therefore you will need to register your site on loki.com in order for your geo-enabled web application to be allowed to request the locations of users. Additionally, if you're running Windows XP you will also need to run svcsetup.exe, which ensures that wifi scanning will not be affected by various "wifi managers" that are shipped with many laptops. All this won't be necessary in future releases, but for now if you experience crashes, it is likely because you need to run svcsetup.exe first.

More importantly, leaving it to the browser to transmit its location means that the user can remain in control of their privacy. This build will prompt the user if they agree to send their location, every time a site requests it. While the UI in this build is experimental, it provides one possible way of protecting the user's privacy.

The W3C Geolocation API is likely to become a widely adopted standard, and Opera is providing this early implementation of the API to let developers and users start experimenting with it. We would be very grateful for feedback from both developers and users, on the API itself and on what functionality and level of privacy control you would like to see exposed in the user interface.

Once you have installed this build, you can go and test it out on our geolocation demo page, which will show were you are on a map, and will display scheduled near you.

Selectors API

, ,

The Selectors API specification, currently being worked on within the WebAPI working group at the W3C, defines DOM APIs designed to make it possible to select elements within the document using Selectors. This simple, yet powerful API has the potential to make working with the DOM faster and easier. If you’re familiar with CSS, you will be familiar with Selectors and these APIs should be easy to learn.

For example, to select all the em and strong elements within the document, you can use this.

document.querySelectorAll("em, strong");

To see how much easier this is compared with traditional APIs, consider this example HTML fragment:

<ul id="fruits">
  <li><input type="checkbox" name="fruit" value="apples"> Apples</li>
  <li><input type="checkbox" name="fruit" value="oranges"> Oranges</li>
  <li><input type="checkbox" name="fruit" value="bananas"> Bananas</li>
  <li><input type="checkbox" name="fruit" value="grapes"> Grapes</li>
</ul>

After the user has filled out the form containing those check boxes, suppose you want to get the list of all the checked items. Using traditional APIs, this would require obtaining a list of all the input elements and iteratively checking which ones were checked.

var fruits = document.getElementById("fruits");
var checkboxes = fruits.getElementsByTagName("input");
var list = [];
for (var i = 0; i < checkboxes.length; i++) {
  if (checkboxes[i].checked) {
    list.push(checkboxes[i]);
  }
}

Using these new APIs, the operation can be reduced to a single line of code!

var list = document.querySelectorAll("#fruits input:checked");

This returns a node list containing all the input elements that were checked by the user. Your script can then perform any operation you like with them.

We have been working on an implementation of these APIs recently and support has been included within the recently released Acid 3 build.

There are two new methods introduced: querySelector() and querySelectorAll(). The former returns the first matching element within the tree, and the latter returns a collection of all matching elements as a NodeList. The current editor’s draft specification defines that the methods are available on the Document, Element and DocumentFragment nodes. However, our implementation currently only supports it on the Document and Elements nodes.

The querySelector() method is useful for situations where only the first matching element is needed, and is designed to be more efficient than the alternative querySelectorAll() method in such cases.

For example, the following form control and javascript function could be used to validate an email address. For simplicity, this uses the validity APIs from Web Forms 2.0. If support for legacy user agents is required, a more appropriate validity check could be written. The querySelector() method is used to obtain the correct element for outputting the appropriate error message, or clearing it when it is valid.

The JavaScript:

function validateEmail(evt) {
  var ctrl = event.target;
  var parent = ctrl.parentNode;
  var errMsg = parent.querySelector(".error");

  // Validate form control value
  if (!ctrl.validity.valid) {
    errMsg.innerHTML = "Invalid email address."
  } else {
    errMsg.innerHTML = "";
  }
}

The HTML fragment:

<p><input type="email" name="email" onchange="validateEmail();">
   <strong class="error"></strong></p>

Our implementation also partially supports the namespace resolver features, allowing you to work with mixed namespace documents and select elements based on their namespace. Consult the specification for more information on the NSResolver object.

You can try out these examples for yourself in the recently released Acid 3 Gogi Build which is available for Windows and Linux.