Dev.Opera2017-02-07T17:38:22+00:00https://dev.opera.com/Dev.Opera editorshttps://dev.opera.com/articles/pwa-resources/Progressive Web Apps: The definitive collection of resources2016-11-11T00:00:00+00:002016-11-11T00:00:00+00:00Bruce Lawson, Shwetank DixitIntroduction
Want to get started with progressive web apps, but not sure where to start? This page will list the best resources we know of to help you understand Progressive Web Apps (PWAs), get started and learn things in depth.
Make sure to bookmark this page, as this is a living document that we’ll be adding to from time to time.
Progressive Web Apps: The what, how and why
These articles introduce the concept of Progressive Web apps and serve as a jumping point to learn more about them.
One of the best things about PWAs are that they can be added to the home screen of your Android device, just like native apps can. This section contains relevant articles covering the ‘Add to Home Screen’ capability, as well as a few articles on how to make your web app UI running smoothly.
Progressive Web Apps are capable of running offline just like native apps. This is primarily through a feature called ‘Service Worker’. Service Workers are great, and besides being used to make web apps run offline, are also required for other functionality like Push Notifications and Background Sync.
Service Workers: An Introduction: A great intro by the Google Team on what you need to know to get started with Service Workers.
The Offline Cookbook: Jake Archibald covers a variety of use cases for offline functionality along with helpful illustrations and code examples for the service wokers code. Very well worth a look!
Service Worker: Santa’s Little Performance Helper: Phil Nash covers Service Worker through a practical example. Its also contains a great example of caching web fonts for offline use using Service Workers.
Using Service Workers: The Mozilla team’s introduction to Service Workers on MDN. It contains some useful infographics on various parts of the Service Worker lifecycle, and more.
Making a Service Worker: A fantastic article by Lyza Danger Gardner going in-depth with Service Workers.
serviceworke.rs: Mozilla’s site detailing various caching strategies and use cases along with code examples.
Designing Offline-first Web Apps: Besides giving helpful tips on good offline experiences, this article helps you think differently about offline as a user state in the first place.
Push notifications are helpful in notifying the user of important, relevant or timely events, even if your site isn’t open in the browser, or even when the browser is closed. With the Push API spec and Service Workers, you can finally implement this in your progressive web app too. Be careful not to spam your users!
Web Starter Kit: A boilerplate for web development including sw-toolbox and sw-precache libraries.
Fetch-sync: Fetch Sync allows you to proxy fetch requests through the Background Sync API so that they are honoured if made when the UA is offline.
Msgr: Nifty service worker/client message utility.
Showcases, case studies and more
Take a look at what others are doing with Progressive Web Apps. Get inspiration and see how it has benefitted others in key business metrics.
PWA.Rocks: The showcase for the best Progressive Web Apps in the world. It’s maintained by the Opera Developer Relations team, and we accept Pull Requests if you have a great-looking responsive PWA. Remember, sites aren’t “mobile-only” so the best PWAs look great on desktop and devices.
Google PWA Showcase: Google’s showcase of companies which have befitted from PWAs.
PWAs: An African Perspective: We interview two great developers from Nigeria and Kenya about PWAs. Read their thoughts on how PWAs can help solve problems in that region.
]]>https://dev.opera.com/articles/pwa-desktop/Progressive web apps running as native OS X apps2016-07-26T00:00:00+00:002016-07-26T00:00:00+00:00Vlad FilippovProgressive Web Apps are getting ready for desktop
If you follow the Progressive Web App scene you’ve probably already seen multiple examples of the Air Horner app in mobile browsers such as Opera Mobile and Chrome for Android. However it is not easy to get your favorite PWA (such as Air Horner) to be a primary citizen on your favorite desktop operating system.
Browser makers are working on getting better support for PWAs in desktop, but it’s not quite ready yet. This is why I started the PWAify project. This project is powered by Node.js and Electron, which already have a huge community and provide ease of use for new and experienced developers. The PWAify project is still in the early experimental stages — use it at your own risk.
The goal of the PWAify project is to provide a solution for PWAs on desktop while we wait for browsers to develop support. In addition this project allows developers to experiment, give better feedback to browser makers, and improve the Web App Manifest specification.
What the installed Air Horner app looks like on Android and OS X
Currently the simplest use case is to just provide an HTTPS URL to the remote app. For example:
pwaify https://voice-memos.appspot.com/
There are some advanced options for the tool as well. You can specify the platform of your choice and an icon file once you are ready to distribute your app:
When you run the pwaify command it fetches and processes the manifest.json for the given PWA. Some early work is in place to simplify the process of generating desktop icons by looking at icons provided in the manifest. The current downside of the pwaify approach is the size of the executable for each application, but there is already huge list of Electron apps out there that require the download. In my mind I try not to worry about the download size. Instead I try to focus on the future of progressive apps instead.
Voice Memos PWA running on Windows, Linux, and OS X
For the purposes of the screenshot I rebuilt the Voice Memos app on all platforms. It is also possible to setup a build server for your application once you want to add multi-platform support. You can use the PWAify tool today by pointing it at your own app or one of the apps in the pwa.rocks list.
Besides the Voice Memos application, my second favorite example is the 2048 tile game, by using PWAify with 2048-opera-pwa.surge.sh I can easily jump back to the saved game state after I restart the application.
The PWAify project is open source, so you can fork it and extend functionality. For example you can add auto-update and custom UI for your application. In the spirit of keeping as much as possible of the application on the web I suggest only introducing minimal changes to the application wrapper. Treat the PWAify’d version of the app just like any other desktop browser would treat it.
The Future
Recently Microsoft announced that the Windows Store will start supporting the W3C Web App Manifest. This will help you distribute the applications for Windows Store users, but you don’t have wait for Microsoft. There is nothing stopping you today to build one version of your web application and get it in the hands of your users on desktop. You can even go beyond Windows users and distribute on other operating systems.
Some future ideas for the PWAify project itself include:
implementing more of the Web App Manifest spec.
reloading manifest.json from the server, which would allow dynamically changing certain properties of the application by updating the manifest.json remotely.
experimenting with new manifest features, such as window size and minimal UI.
working with the Electron app community to make it easier to generate application icons for cross-platform use.
Tools like Electron and PWAify put yourself in control of application distribution while allowing you to use the latest web technologies. Write one awesome progressive web application for multiple distribution targets!
]]>https://dev.opera.com/articles/pwa-nigeria-kenya-interview/Progressive Web Apps in Nigeria and Kenya: a Double Interview2016-06-16T00:00:00+00:002016-06-16T00:00:00+00:00Andreas Bovens, Bruce LawsonWhile keeping an eye on Twitter mentions of progressive web apps, I came across a number of conversations between web developers in Nigeria and Kenya. Intrigued, I got in touch with them to hear their thoughts on progressive web apps, resulting in this double interview.
Hi! Please tell us a little about yourselves.
Constance Okoghenun, @okoghenun: I’m from Lagos, Nigeria. I work as a UI Specialist for Konga, Nigeria’s largest online marketplace helping tens of thousands of merchants selling over 200,000 products on our platform. At Konga I help to build products that provide great shopping experiences for our customers. I also help organise and speak from time to time at Usable (formerly UXLagos), where designers, developers and enthusiasts here in Lagos and, recently, Abuja Nigeria, have monthly conversations about how to improve the experiences we deliver to our customers.
I love the web and have been working on the web for about 5 years now. It has been a delight to see it mature and become better as a platform, enabling me and other developers and designers to offer increasingly better experiences to our users.
Eugene Mutai, @kn9ts: I’m from Nairobi, Kenya. I’m currently working for/with Andela. Andela is new startup, with a revolutionary model founded on the principle that brilliance is evenly distributed around the world, but opportunity is not. Andela is transforming the brightest minds in Africa into world-class developers, who then are fused into startups or Fortune 500 companies all over the world. I am currently working as a full-time full-stack developer for RBI, a Canadian multinational company (and one of the largest fast food brands in the world) whose brands include Burger King and Tim Hortons.
I have been a web enthusiast and developer for at least four years now. I am also a Google Developer Expert on Web Technologies, attributed by one of my community contributions such as being the lead manager of the Nairobi JavaScript Community growing it to over 450 members, and I regularly speak at a variety of programming and tech meetups.
We met online because you were talking about Progressive Web Apps (PWAs) on Twitter. What is it about them that excites you?
Eugene: I haven’t talked about progressive web apps on Twitter only; I have evangelized about them wherever I got the chance to. My last talk on progressive web apps was at Nairobi Tech Week, the largest tech event in Sub-Saharan Africa this year. I’ve also written a blog post about it — Progressive Webs Apps: Africa may be the biggest gainer — which is a robust answer to the above question.
In summary, I am excited that finally web technology is earning its place on mobile. PWAs are changing the way web apps have been viewed: a secondary, less-intuitive and less-performant alternative to using a mobile app’s service. While settling in on mobile, leveraging its greatest advantage over native mobile apps — very low friction in usage — it may solve problems that make the daily usage of native mobile applications in Africa a challenge, e.g. the size of apps and requirement of new downloads every time they are updated, among many others.
On a side note, as a passionate web developer, it’s been tons of losing development battles with Android developers, and I’m finally unquantifiably happy we are becoming a force to be reckoned with.
Constance: There are lots of exciting things about progressive web apps and the new range of possibilities they bring to the web. If I were to pick just one feature of progressive web apps that I’m super-excited about, it’s the ability to detect and handle offline / unreliable network conditions with service workers.
This is vitally important, as web apps finally now have a space on user home screens — so being slow to load or breaking because of network unreliability is not acceptable. And, in my part of the world, where getting good connectivity speeds on mobile is pretty difficult, service workers present an opportunity for developers to build apps that aren’t just fast, but which are also resilient.
An example of this is Konga’s PWA: when we detect that the user is offline and has items in their shopping cart, we provide them the option of going through an offline checkout experience, thereby preventing internet connectivity from becoming a bottleneck when they shop with us.
Constance, what are the characteristics of the Nigerian market that make PWAs an appealing development route?
Constance: Data is pretty expensive in Nigeria. Over the last 12 months, data prices have become lower, but not low enough to make the majority of the Nigerian internet market data insensitive. On average, it costs about NGN 1000 (about $5) to get 1GB of data. In a country where minimum wage is about NGN 18,000 (about $90) that is already 5.6% of the monthly salaries. So, as you can imagine, Nigerians are extremely data sensitive.
A huge number of smartphone users do not download their apps and never update their apps. Instead, people side-load apps and other content from third parties who have these apps downloaded to a PC and for a small fee will install apps from their computers to users’ phones. Among younger, more tech-savvy Nigerians, the app Xender is really popular as it allows them skip app downloads and just send it from one device to another.
As you can imagine, these workarounds for downloading apps from the app store create all sorts of problems for developers — from app distribution, to getting the most recent, bug-free versions of apps in the hands of users.
With PWAs giving web apps a place in the user’s home screen, without the download overhead of native apps, this becomes more exciting; developers in Nigeria can now always give a great and up-to-date experience to their users. Also, they have the ability to re-engage with their users via push notifications, and improve conversions.
Eugene, is it similar in Kenya?
Eugene: The average pay is Kenya is approximately $300-400 a month. On a good month, with tough choices made in budgeting, one gets to barely spare $30 after covering monthly expenses. It costs $1 for 135MB of data and $5 for 1GB of data. On average a user has 15+ apps installed (extrapolated from global mobile app install stats). At least half of these apps demand to be updated after a day or two (best case scenario is weekly).
If each app is on average 15MB, this means 150MB of data used up on downloads from re-installations without considering each user’s unique personal data usage. If at least $5 of data is being used for updates only, I’d say this is very challenging to a user if they are is to keep up with these updates. Some updates also are just bug fixes — I kid you not, no one would update the app for that (including me) unless the bug is not negligible.
Constance, what were the challenges of making the Konga PWA?
Constance: The biggest for us at Konga was time: we had only about six weeks to build a stable version of our app and we did it in time. Thinking offline-first was something we had to get used to doing. Apart from those, building our PWA wasn’t very difficult.
And how was user feedback for your PWA, Constance?
Constance: Though we haven’t officially launched the app yet, feedback has been overwhelmingly positive. It requires 84% less data to complete the first transaction vs the previous mobile web experience, and 63% less data for initial load, and we are not even done building and optimizing the app. It certainly will be a delight for our users when it gets into their hands.
To quote our CEO Shola Adekoya:
We estimate that with our new light, super-fast, UX-rich browsing capability, customers’ data consumption will fall dramatically.
Back to Eugene now. How was user feedback to your evangelism, Eugene?
Eugene: I’m been satisfactorily happy with the feedback I have got from my blog post and all my talks on PWAs. In the last talk I gave, at one point a member of the audience who was an Android developer (among many others in the room) who became anxious and disturbed that PWAs would render native Android developers jobless. The best answer I could give was we’re only moving in the mobile department since we’re now in a sharing economy, and not kicking them out, and the hype was to only create awareness to all web tech developers and not to cause panic among Android developers.
Do you think those Android developers’ concerns are justified? Do you see PWAs becoming dominant in the kind of markets that you work in?
Eugene: No, I don’t think they’re justified. First of all, awareness about PWAs is something that needs to be urgently addressed. Every time I give a talk on PWAs the facial response of the audience is like “Why didn’t I know about this? This is revolutionary!” and the question that always follows is “Where can I find more information and learn about PWAs?”
Furthermore, I don’t envision PWAs being dominant in the mobile apps space, but I see their presence vastly increasing once knowledge about them is in the hands of every web developer. PWAs solve a number of challenges for entrepreneurs: it’s a cross-platform solution, there’s very low friction compared to native apps, there’s no APK size limitation, and so on.
Constance: I also don’t think that fear of PWAs is justified. I think both PWAs and native SDKs are just tools in a good developer’s tool box. There are use cases where a PWA would be perfect, and there are others for which a native app is best. Each developer just needs to evaluate when to use what. Moreover, there is nothing stopping native mobile developers from working on the web; Konga’s PWA was built by both our current mobile team (Android and iOS developers) and our front-end team.
What else would you like to see browsers do to make PWAs more widely available and accepted?
Constance: Lots of developers use frameworks; it would be great to see vendors reach out to the maintainers of those frameworks and work with them improving their tooling and processes, so that it’s super easy to build PWAs with their frameworks and tools. More importantly, I’d like to see a more consistent implementation of the web specs that PWAs are based on.
Eugene: Opera and Google Chrome have done a wonderful job so far. When talking about PWAs being installable, the “Add to home screen” option isn’t that convincing. I’d like to see something like “Install Web App” or “Add to Your Apps”.
Browsers should offer APIs so that PWAs can compete on an equal footing as native mobile apps. I am aware these missing APIs such as Bluetooth, NFC, USB access and so forth are currently being worked on. So this is just a matter of time.
Thank you both!
]]>https://dev.opera.com/articles/web-bluetooth-intro/An introduction to the Web Bluetooth API2016-03-02T00:00:00+00:002016-03-02T00:00:00+00:00Shwetank DixitIntroduction
There is an explosion of electronic devices nowadays, and with many of them, it’s possible to interact with them via Bluetooth Low Energy, or BLE. However, installing a separate app for interacting with every single bluetooth gadget is impractical. What if we could communicate with them through a web browser? The Web Bluetooth API aims to do exactly that with a promise-based API, which allows you to interact with many BLE enabled devices. This is also great for companies intending to launch new gadgets, as instead of spending time and money on developing a separate app for multiple platforms, they can offer interaction with their gadget in a cross-platform manner, as it could be controlled directly from a web page.
The Web Bluetooth API
So far, the ability to communicate with BLE devices has been possible only for native apps. The Web Bluetooth API aims to change that and brings this to web browsers as well. The specification for the Web Bluetooth API is not final yet, and you’re free to share your feedback on what you would want in it as well.
Right now, the Web Bluetooth API is in Opera for Android beta. You can activate it by going to opera://flags and enabling Web Bluetooth in the options provided on that page.
Some prerequisites
HTTPS only: The API only works on pages served over HTTPS. Most privacy-sensitive web APIs are now switching over to the HTTPS-only model, and this one is no exception.
Requires user action: We want to make sure that the API doesn’t work in the background without the user knowing about it, which is why there is a prompt shown to user to choose which device to pair with. Additionally, we also don’t want sites to show up this prompt straightaway without any user interaction. That is why methods in this API only work when called in response to a user action (like responding to a click event).
Getting Basic Device Information
Let’s take a look at some code to figure out how to use this API to get some basic information regarding a BLE device.
As mentioned earlier, the method navigator.bluetooth.requestDevice() can only be called in response to a user action like a button click. This method calls up a dialog box showing the list of available BLE devices matching the query filter. In our case, the filter we have set pertains to BLE devices which expose a so-called “GATT service” called battery_service. We’ll find out more about GATT services in the next section.
Keep in mind that it is necessary to include at least one filter when requesting device access using the Web Bluetooth API.
Once the user selects the device and connects to it, it can then print out the device name and its ID.
What are GATT services?
GATT stands for Generic Attribute Profile and provides a standard way for Bluetooth devices to advertise their services to the outside world. Your cell phone might provide a GATT service to show the current battery level. Your fitness band might provide a service that too, along with another one showing the current heart rate count. There are a number of services which are exposed through GATT, and we can listen to those services depending on which of those services are exposed by the device.
Some devices may not list their services in the standardized list of GATT services, in which case you could use their full Bluetooth UUID or a short 16- or 32-bit ID instead. Of course, this depends on whether the device has any documentation mentioning these UUIDs and what they are for.
Once we have connected to a device, the next step is of course, to read some useful data from it. To do that, we need to connect to the device’s GATT server by using the method gatt.connect(). Let’s take our previous code sample and extend it. This is based on the Battery Level Sample Code demo, which you can also check out (Note however that it uses the connectGATT() method which is deprecated from Chromium 50 onwards).
navigator.bluetooth.requestDevice({
filters: [{
services: ['battery_service']
}]
}).then(device => {
console.log('Got device:', device.name);
console.log('id:', device.id);
return device.gatt.connect(); // Chromium 49 and below use `connectGATT()` but from Chromium 50 it will use gatt.connect();
})
.then(server => {
console.log('Getting Battery Service…');
return server.getPrimaryService('battery_service');
})
.then(service => {
console.log('Getting Battery Characteristic…');
return service.getCharacteristic('battery_level');
})
.then(characteristic => {
console.log('Reading battery level…');
return characteristic.readValue();
})
.then(value => {
value = value.buffer ? value : new DataView(value);
console.log('Battery percentage:', value.getUint8(0));
})
.catch(exception => {
console.log(exception);
});
Writing values would typically require entering the appropriate values to be parsed as a BufferSource, which are either an ArrayBuffer or a view onto an ArrayBuffer like a DataView object (You can see a list of buffer source types). For example, for resetting the enerygyExpended field in a heart rate monitor, we can use the writeValue() method like so:
navigator.bluetooth.requestDevice({
filters: [{
services: ['heart_rate']
}]
}).then(device => {
console.log('Got device:', device.name);
console.log('id:', device.id);
return device.gatt.connect();
})
.then(server => server.getPrimaryService('heart_rate'))
.then(service => service.getCharacteristic('heart_rate_control_point'))
.then(characteristic => {
const resetEnergyExpended = new Uint8Array([1]);
// A value of `1` is a signal to reset it.
return characteristic.writeValue(resetEnergyExpended);
})
.then(value => {
console.log('Reset value of energy expended field');
})
.catch(exception => {
console.log(exception);
});
If you don’t have a device which exposes GATT services but still want to play with the API, try out the BLE Peripheral Simulator App.
Advanced uses
Different devices will expose different services and have documentation describing how to access those services. For example, the BB-8 Toy by Sphero has some of their documentation on how to do that over here.
Using this, it’s possible to create a web app that can control the BB-8 toy! Check out the code for it.
It would also be cool for websites to access the current RSSI (Received Signal Strength Indicator) and txPower levels, as well as any associated URLs shared through the Eddystone protocol without the need to pair with each individual device. All these exciting things are yet to come.
You can check out the implementation status on various platforms as well as a hardware compatibility list. If using Android, we recommend using the latest version for best and most consistent results.
]]>https://dev.opera.com/articles/working-with-theme-overlay/The New Start Page: Working With the Theme Overlay2016-02-15T00:00:00+00:002016-02-15T00:00:00+00:00Shwetank DixitFrom Opera 36 onwards, the start page will have a brand new look. It introduces various design improvements, right from the placement of key icons, to the sizes of the speed dial tiles. As part of this, it also introduces a translucent gray overlay on themes.
Previously the title text for speed dial tiles was always having a white background and black text. The new design got rid of it, and overall speed dial tiles look much better. However, a side-effect of it was that reading the text totally depended on the background picture in the theme.
A solution to this is to introduce a subtle gray translucent overlay on themes and have the title text color for speed dial tiles white by default. We wanted to create a design that could work for any image you would try (or already have installed), meaning that even busy images would work just well and you will have a good experience using the new start page. While this solves the legibility issue by making the text very easy to read, some theme designers might want to not have this overlay, depending on their preference.
So we have introduced an option for theme authors to specify whether an overlay should be applied to their theme or not. If they choose not to apply an overlay on their theme images, then they can do so, and even specify the color for the speed dial text and other icons on the start page. This gives greater control in the hands of the theme creator.
What does this mean for theme designers?
As a theme designer, you have two choices. If you want the background image to work with the overlay, then there is nothing extra you need to do. The overlay is applied by default, and all the text and icons will be white in color to contrast with the overlay (which gives it a nice contrast, making sure its readable) so no extra work needed there.
However, if you would like the overlay not to be applied to your background image, you now have the option to do so. However, keep in mind that in this case, you have the responsibility to make sure that all text and icons are properly visible to users.
Disabling the theme overlay
Theme with overlay enabled and disabled
We have introduced a new option in the Persona.ini file. You can now use Use Overlay to tell Opera whether to have it enabled or not. If you don’t want the overlay, simply write
[Start Page]
Background = background.jpg
Position = center
Use Overlay = false;
This will disable the overlay.
Making text and icons readable
Once you disable the overlay, it is up to you to make sure all the text and icons are having proper contrast and are readable by the user. For this, the existing option of Title Text Color will matter a lot.
Let’s take the example of the following of a theme with a disabled overlay.
Now the image here is very light and provides very little contrast to the text, which is white in color. Let’s make it dark to provide it proper contrast. Let’s write the following:
[Start Page]
Background = background.jpg
Position = center
Use Overlay = false;
Title Text Color = #000000
This gives us the following result:
This is much better. However, you could go ahead and provide more style which matches the color scheme (rather than the standard black) while still providing good contrast. Let’s change the text color like so:
Title Text Color = #ff0000
This results in the image having good contrast and matching the color scheme.
Keep in mind that, despite the name, using Title Text Color will affect the color of not just the text, but also the icons on the start page.
In the above image, you can notice how the icons have the color applied to it too.
Conclusion
The new start page for Opera features an all new re-design. This features a new overlay for images which makes it work with a lot of images, even busy images, while still providing readability for users. Theme designers get greater control over how they want their background images to be displayed.
If they want to disable the overlay, they can use Use Overlay = false in the Persona.ini file. If overlay is disabled, then theme designers should keep in mind readability for text and icons on the start page by specifying an appropriate color for them using Title Text Color in the Persona.ini file.
]]>https://dev.opera.com/articles/offline-with-upup-service-workers/Building Offline Sites with ServiceWorkers and UpUp2016-01-19T00:00:00+00:002016-01-19T00:00:00+00:00Tal Ater
We are living in an increasingly mobile world. We rely on our phones to keep us connected wherever we go, and to provide us with the information we need to get through our day.
But connectivity hasn’t quite caught up with our dependence on it yet.
Every day we find ourselves without a working internet connection. Even in countries with near-perfect coverage, we lose connectivity when stepping into the elevator, or taking the subway. We have areas in our house that never seem to have a solid connection… and don’t even get me started about travel. The minute we leave our comfortable homes and offices, whether we’re boarding a plane, or just driving from town to town, we are at the mercy of the cell towers.
Now think of your users, and their dependence on the information you provide them. Are you running a travel site offering online hotel bookings? What would your users do if they just landed in Tokyo, without a local data plan, but they needed to access your site in order to find their hotel’s address? Does your store have a website? What would your users do if they were riding the elevator down to the parking lot while trying to find out your store’s opening hours?
Luckily we are living in very exciting times for web development. New technologies are coming out every day, unleashing new possibilities, and changing our perception of what is and isn’t possible in the browser. Two of the most important technologies to come out in recent years — service workers and the CacheStorage API — allow us an amazing level of control over the user’s browsing experience — even when their internet connection fails.
Taking control of the offline experience
One library to provide an easy solution for the connectivity problem is called UpUp. (Editor’s note: Tal is the developer of the UpUp library.)
UpUp allows you to define exactly what you want to show your users when they are offline, while handling all of the logic of intercepting requests, detecting when they fail, returning the right content from cache, managing that cache, and generally dealing with all the headaches of cross-browser compatibility.
The content you show your users can be as simple as one page (e.g. your business’ info, address, etc.), all the way to fully customized offline experiences with data customized for each user (e.g. a travel site’s user could browse his bookings, and get details on each booking, even while offline).
The best part of all, UpUp lets you do all of this in just a few lines of code:
In this article we’ll first look at how you can use UpUp to add offline capabilities to your site in under 10 minutes. We will then dive deeper behind the scenes, and see how UpUp achieves all of this.
10 minute tutorial
Let’s begin with a simple site, and add offline features to it:
Our sample site, Lonely Globe Advisor, offers visitors a list of the top fictional hotels in Rome.
But what happens if our user just landed in Rome and doesn’t have a local data plan? She’ll be out of luck.
We can improve on this experience by loading UpUp, and telling it what content we want it to show the user if she is offline.
<h1>Top Hotels in Rome</h1>
<ol>
<li>Villa Domus — Via Piacenza 9, Rome, Italy</li>
<li>Hotel Trivelli — Piazza Barberini 11, Rome, Italy</li>
</ol>
<script src="/upup.min.js"></script>
<script>
UpUp.start({
'content-url': '/offline.html'
});
</script>
With just this tiny bit of code, we’ve added an offline experience for our site, and allowed our users to see the best hotels in Rome… even when they can’t access the web.
Any user that visited our site in the past, and is now trying to access it again without an internet connection, will now see the content of offline.html. Make sure you create this file and place it in the location you defined under content-url.
The sample above just shows a simple html page. You can improve on your offline content by including stylesheets, images, or even videos in your offline.html. You just need to make sure to tell UpUp what files you’re using, and it will cache them so they are available for your users when they are offline.
With just one command and a couple of settings, we can create rich offline experiences for our users. These can be as simple as the example above, or as robust as a full single page application using frameworks like AngularJS, with content customized for each user, videos and files the user can access while offline.
There’s a more detailed tutorial available on the official site, as well as complete documentation of UpUp’s API.
How does it work?
How does UpUp serve this content to our users if they aren’t connected to the internet?
tl;dr
UpUp uses a new type of script called a ServiceWorker. This script runs even when the user is offline, and wraps every request made to the server with a promise. If the server can’t be reached, that promise is broken. The script catches broken promises, checks in its cache to see what offline content you’ve chosen to show and returns that instead of an error.
ServiceWorkers
In order to understand how this works, let’s first understand how ServiceWorkers work.
A ServiceWorker is a special type of script that any site can register in the user’s browser. Once registered, this script sits in a very interesting position between the browser windows and that site’s server.
As you can see, while the ServiceWorker runs within the user’s browser, it isn’t attached to any one window. Instead it runs in the background, and can communicate with the windows in its scope (the site that registered it).
From this unique location in the browser, ServiceWorkers have the power to examine each request as it is sent from the user’s browser, decide what to do with it, and then send it to the server. The ServiceWorker can then examine the response as it is returned from the server, decide what to do with it, and then pass either the original or a modified response back to the user’s window.
In a way, you can think of a ServiceWorker as a local proxy server inside the user’s browser. A proxy written in JavaScript that has the power to change requests and their responses.
Now if you think about this flow, you can probably begin to see the many different possibilities this grants us as developers.
For example, you could have a templating engine written entirely inside a ServiceWorker. This ServiceWorker would intercept requests to the server for HTML, asking the server for JSON instead. It would then parse that JSON against a template it has stored within it, and finally return simple HTML as the response. This could save us from rendering the HTML on the server, save bandwidth in the responses, and save us from having to include the templating logic in every page of our site. In other words, the server returns simple JSON, and the web page receives simple HTML.
Another idea could be a ServiceWorker that redirects requests to video files to either SD or HD videos based on the user’s connection speed or settings — this could be done without requiring each page to hold the logic for making that decision, or involving the server in the decision, allowing us to use a server optimized for delivering static files.
ServiceWorkers and UpUp
UpUp uses the power of ServiceWorkers to provide a solution to the lost connectivity problem described above, and serve content to the user even when their connection is down.
Let’s follow what happens behind the scenes of UpUp.
We’ll begin by registering a ServiceWorker. Once registered, all requests from the browser to our server go through the ServiceWorker, where they are wrapped in a JavaScript promise, and pass on untouched to our server. If that promise is broken (ie. we did not receive a response from the server), the ServiceWorker catches that error before it is shown to the user. It will then check for the cached content we’ve decided to show the user, and return that as the response, instead of an error .
To the browser’s window, responses returned from the server or from the cache by the ServiceWorker look exactly the same.
Where does the offline content come from?
The final piece of the puzzle is the new caching technology used by UpUp — CacheStorage. Note: don’t confuse this with the browser’s own cache, or with that douchebag, the Application Cache. This is something new and much more powerful.
When we first registered our ServiceWorker, we told it what content to store in cache for later (we defined this in the content-url and assets settings). The UpUp ServiceWorker script went ahead and fetched that content, and stored it using the CacheStorage interface.
This content will now be available for the ServiceWorker the next time the user is offline.
Important ServiceWorkers Considerations
When using ServiceWorkers, there are a few things you need to always keep in mind.
HTTPS Only
To preserve the user’s security and privacy, ServiceWorkers can only detect requests over a secure connection.
During development you can use UpUp through localhost or file (e.g. both http://localhost/ and file:///Users/tal_ater/index.html are OK), but to deploy it to production you’ll need to have HTTPS set up on your server.
Browser Support
UpUp plays nicely with all browsers, progressively enhancing browsers that support ServiceWorkers, while leaving users with older browsers unaffected.
UpUp currently supports Opera (since version 27), Chrome (since version 40) and Firefox (since version 41). If your users are using a different browser, they simply won’t notice anything different.
Where Should I Place My Files?
For security reasons, the browser only lets UpUp’s ServiceWorker see network requests within its scope.
The scope that the ServiceWorker can affect is determined by where you’ve placed upup.min.js and upup.sw.min.js. For example, if you place it on https://yoursite.com/js/upup.sw.min.js, UpUp will only be able to show your offline content when users try to look at the /js/ directory.
This is why it’s important to place both files on the same server as your content, and not in a subdirectory. This should ideally be in the root of your site (e.g. https://yoursite.com/upup.min.js).
What’s Next?
It’s hard not to be excited about all the new possibilities ServiceWorker opens up to us as developers.
Go ahead, and try UpUp on your own site, you can see it in action and find more details and tutorials on doing Offline First with UpUp.
If you’d like to dive deeper and play some more with ServiceWorkers, there’s a great introduction by Matt Gaunt. If you’d like a few other ideas of how to improve caching with ServiceWorkers, check out Jake Archibald’s Offline Cookbook.
]]>https://dev.opera.com/articles/release-the-beacons/Release the Beacons!2015-10-08T00:00:00+00:002015-10-08T00:00:00+00:00Bruce LawsonNorway is the nation that gave the world the paperclip and the cheese slicer, so it’s easy to see that R&D is a national tradition here (it stands for “research and development”, not “reindeer and dogsleds”, although those are nice too).
A “beacon” is defined as “a fire or light set up in a high or prominent position as a warning, signal, or celebration”, and this is very much the same in the context of the Physical Web (aka “The Internet of Things”). A beacon is a low-powered chip with its own power source that does one thing: it broadcasts information, using a Bluetooth low energy (BLE) message format like Eddystone, AltBeacon or iBeacon.
These formats compete with each other. The latter two broadcast a Unique Identification Number (UID), so users need an app specific for those beacons, or require Apple’s Passbook to do anything with those UIDs.
Eddystone, named after a famous British lighthouse, simply broadcasts a URL. This simplicity makes these URL beacons especially interesting in the context of the mobile web. (Eddystone actually supports broadcasting UIDs as well. This Opera Labs build currently only supports Eddystone-URL.)
When a user with Bluetooth software comes near a beacon, their device can pick up the URL. And what better way to handle a URL than with a browser?
Labs build
Today’s Labs build is Opera 32 for Android, with additional beacon goodness. Installing it won’t overwrite any existing installations of Opera for Android or Opera Beta. (If you have a previous Labs build of Opera, uninstall that one first.)
To use beacons, accept the dialog shown on first run. Beacons are shown in the “Nearby” panel, which you find on the right of the “Discover” panel. Two swiped to the right and you’re there!.
Here’s a photo taken at our local bus stop. The bus stop is broadcasting a unique URL (other bus stops can broadcast different URLs).
For those who don’t read Norwegian (why not?) it’s telling us that the number 30 to Bygdoy is coming now, the number 30 to the Opera office in Nydalen is coming in 5 minutes, which is lucky, or we’d be late for work again. (Not our fault! We were in the pub last night — checking out their beacons, naturally.)
Additionally, as there are few beacons “in the wild” at the moment, this Opera Labs build’s “Nearby” panel shows Wikipedia entries based on geolocation, so that there’s always something shown. This allows for a mix of geotagged “general interest” Wikipedia stuff, and very location-specific info coming from beacons.
Beacons will trigger an Android system notification, so you can easily find out if there’s a new beacon around. Wikipedia results on the other hand do not display a notification.
Security and privacy
Beacon signals are one-way only. They are emitted by the beacon, and picked up by your phone, and nothing is ever sent back to the beacon. This is great for privacy, because it means that the owner of the beacon cannot track anyone who steps within range.
There is, however, a privacy trap here that we could fall into if we’re not careful. Consider the naive beacon-scanning application: it sits in the background of your phone and scans for beacons. Every time it sees a new beacon, it resolves a shortened URL to a real URL. Then it fetches the web page at that location, in order to extract some metadata to show you. The problem here is that the owner of the beacon probably controls the web page. When they see that you request the web page, they know that you’re probably near the beacon. If they own a lot of beacons — maybe it’s an international chain store or a fast-food establishment — they can track your IP address wherever you go.
To better protect you, the beacon scanner in the Opera browser comes with an anonymizing service, which shields you from making direct contact with these web pages. Rather than fetching metadata from the web page directly, the Opera browser sends a request to our server. The server will resolve URLs, fetch and parse pages, and prepare icons, then return just the bits you’re interested in. This results in less data traffic used, fewer CPU cycles spent and most importantly, better privacy (provided, of course, that you trust Opera).
Populating the Nearby list
So maybe you’ve ordered yourself a handful of beacons, and you want to prepare your web pages for beaconization (new technologies require new words). But, how exactly does the “Nearby” screen in the Opera browser transform full web pages into simple list elements? If you want to make your page look good in the “Nearby” screen, you’ve got three choices at the moment — just use one. We recommend plain HTML.
HTML
This is maybe the most straightforward solution. Use the <title> element, the <meta name="description"> element to hold the description (any line breaks will be replicated in the “Nearby” panel) and point <link rel="icon"> tag point to a high-resolution icon. A 144 × 144 PNG will look great.
Open Graph
As an alternative to the approach above, you can use the following Open Graph tags, respectively: <meta name="og:title">, <meta name="og:description"> and <meta name="og:image">.
Schema.org
Finally, you can choose to annotate your HTML with Schema.org microdata. Specifically, we look for the tags <meta itemprop="name">, <meta itemprop="description"> and <meta itemprop="image">.
Example
As an example, the “bus stop” URL has the following markup:
<head>
<meta charset="UTF-8">
<meta name="description" content="
30 til Bygdøy via Bygdøynes om 2 min
56 til Solemskogen om 4 min
30 til Bygdøy via Bygdøynes om 12 min
30 til Nydalen klokka 14:54
56 til Solemskogen klokka 14:58">
<meta http-equiv="refresh" content="30">
<link rel="icon" href="ruter.png">
<title>Gullhaugveien</title>
</head>
The page title of the “Nearby” entry comes from the HTML <title>, the icon from the <link rel="icon"> and the main content from the <meta name="description"> element; line breaks in the content of the tag are reproduced in the Nearby panel. The <body> of the page is irrelevant, so one URL can be used to populate the “Nearby” panel and as a conventional web page.
Hardware support and battery usage
Depending on the Bluetooth hardware in the device, this Labs build can drain the battery. Newer hardware offloads scanning to the Bluetooth chip, and you will not notice any extra battery usage. But older hardware (like the Nexus 5) wakes up the device at specific intervals and will thus drain the battery faster. You can check this from “Nearby” → Settings cogwheel → Debug information. There we show the level of hardware support and estimated battery usage (low, medium, high).
Setting up your own beacons.
It’s easy to buy Eddystone beacons, and to set them up from a computer, using a Bluetooth 4.0 Low Energy dongle. Opera’s Tommy Thorsen wrote a python script to advertise a URL using Eddystone-URL.
Why are beacons a good fit for Opera?
We at Opera R&D really like beacons, especially URL-beacons. As a web browser, URLs are exactly what we’re good at, and new ways to discover more URLs is great news for us. But, what will we do with these URLs? And what can beacons really be used for?
You can divide technologies into two groups: technologies that have a specific use case vs. technologies that can do all sorts of stuff, but we’re not sure what the interesting use cases are. Some of the most revolutionary technologies fall within the latter group. Take the World Wide Web as an example; the technology is really just bits of text that can contain links to other bits of text. But, as people have started using and extending the technology, we’ve taken it to a level which surely no one could have imagined a few years ago. Or, SMS, which is just an afterthought in the GSM specification but, despite (or because of?) its limitations, became hugely popular.
Can beacons be the next groundbreaking thing? That’s hard to say, but the technology has that potential: like the web and SMS, it provides a simple but versatile service, on top of which developers can improvise and innovate. Linking beacons to the web, via the browser, is a solid step forward, and will hopefully accelerate that innovation.
]]>https://dev.opera.com/articles/installable-web-apps/Installable Web Apps and Add to Home screen2015-09-23T00:00:00+00:002015-09-23T00:00:00+00:00Andreas Bovens, Bruce Lawson
Today, we’ve launched Opera 32 for Android. Along with a host of bug fixes, stability improvements and an updated Chromium engine for maximum compatibility and security, you’ll find some features that are deliberately designed to bridge the gap between native apps and the “mobile web” (or, at least, the web viewed on mobile devices).
(Updated 30 September 2015: today’s update to Opera 32 for Android changes the name selection criteria.)
One of the bigger gaps has been the difference between bookmarking a site and installing an application. We know that, even on desktop, most people don’t use bookmarks. We also know that people love “installing” apps that live on a device’s homescreen, with a crystal-clear icon imploring them to tickle them into life with a tap of the finger.
When a user loads a site in Opera 32 for Android, taps the plus sign, and chooses “Add to home screen”, a shortcut to this site is placed on the home screen of her/his device, allowing for direct access and increased visibility.
Through the magic of web standards, site owners can make this even better: by serving the site over HTTPS and providing some metadata in a manifest file a web app can get an optimized icon, and be run in “standalone” or even “fullscreen” mode, with a custom orientation. These web apps also run in a separate process, just like a native app. We call this “Installable Web Apps”.
We’re very excited about Installable Web Apps, as they bridge the gap between native and web apps in a most elegant way: they allow you to build applications using the full web stack that run in the browser as well as outside of it, without sacrificing crucial functionality like hyperlinking, and without the need for app stores or gatekeepers.
If you want to read more about why this is an exciting evolution, Alex Russell of the Google Chrome team has an excellent write-up called Progressive Apps: Escaping Tabs Without Losing Our Soul that explains many of the advantages from both a developer and a consumer perspective.
Here are two more that appeal to us:
No update distribution lag
With a centralised app store distribution model, the user receives a notification that a new version of your app is available; they download it and install it. However, in many parts of the world, data is expensive or WiFi is a luxury, so people don’t update over their mobile connections. This means that outdated versions of your app continue to be used long after you’ve released an update. If the outdated version has a security flaw, this is a problem.
With Installable Web Apps, the app is actually on your web server, so the instant you update it, everybody gets it, at the time they need it — there’s no update distribution lag, and the user isn’t wasting their precious data to download a complete new version of your app.
Those occasionally used apps are taking up a lot of storage on a device that may be inexpensive and therefore have little space. According to Techrepublic,
Internal storage is particularly important, because this is where your apps are stored. If you buy a budget or entry-level phone, you’ll probably find around 512 MB of internal storage. With this low amount of storage, you’ll only be able to install a few apps.
Over a quarter of new Android devices have only 512 MB of RAM
In short, installing and running various apps on low-end devices is not always so straightforward.
It’s here that installable Web Apps come in: they typically only store an icon, a text-based JSON manifest and some cached data on the device, which is likely to use less storage.
Installation mechanisms
In this release, site visitors can add a website to their home screen by tapping the + icon on the left of the address bar.
In a future release, we’ll make it more discoverable: under certain circumstances Opera will prompt the user to add the site they’re visiting to the Home screen.
Defining start-up characteristics
To make your site fully “installable”, you need to declare some characteristics in a special manifest file.
The manifest file is a simple JSON text file; link to it from the <head> with a line like this:
<link rel="manifest" href="/manifest.json">
Defining icons
Your app will be added to Home screen with its own icon, rather than that of the browser. For this, the manifest has an icons property. This takes a list of icons and their sizes, format, and target screen density. Having these optional properties makes icon selection powerful, because it provides a responsive image solution for icons – which can help avoid unnecessary downloads and helps to make sure your icons always look great across a range of devices and screen densities.
In Opera, the icon will be fetched from the manifest (if there is one),
regardless of HTTP/HTTPS status. if there is no manifest, the first favicon or alternatively, a generic fallback icon is used.
Defining the name
If your app is hosted on HTTPS, the manifest is parsed and the short_name is displayed on the Android home screen. Keep it short — a truncated name isn’t a good user experience, and doesn’t look very professional.
If Opera can’t find a short_name, it’ll use name and, if that’s not present, the HTML title is used.
Display modes
The specification defines display modes, which are different ways to show your web app.
Opera for Android supports
fullscreen — the app will take all the screen; hardware keys and the status bar will not be shown. Note, this is not the same as HTML5 fullscreen mode.
standalone — no browser UI is shown, but the hardware keys and status bar will be displayed.
browser — the app will be shown with normal browser UI, ie. as a normal website. Note that custom orientations are not yet supported in this mode.
The minimal-ui mode is not supported; it falls back to browser as the spec requires.
In Opera for Android, only sites on HTTPS can be displayed in fullscreen or standalone mode. Insecure sites are always displayed in browser mode, regardless of the manifest definition, to better protect the user; we show the URL bar so the user can always see the real address of insecure sites (hackers could, for example, spoof a bank site). Note that this is different from the behaviour of the current Chrome for Android (Chrome 45).
In modes without browser UI, Opera supports pull-to-refresh, making it feel more app-like.
Start URL
Sometimes you want to make sure that when the user starts up an app, they always go to a particular page first. The start_url property gives you a way of indicating this.
{
"start_url": "/firstPage.html"
}
With this, you can include the manifest on every page of your web app so the user can install it from wherever they are, but send them to a common home page when they start it from the Home screen, rather than returning them to the page from which it was installed.
theme_color
The manifest theme_color is not yet supported. Use the HTML meta tag to set it in Opera and Chrome:
<meta name="theme-color" content="#ababab">
This will colour your app’s toolbar and make it more distinguishable in system functions such as task switching. You probably want to choose the predominant colour of your page or branding.
Navigating outside the app’s scope
If the user follows a link that takes them outside the domain of an installed web app, the browser will flash 68 times, the device will vibrate like a demonically-possessed hippopotamus, and a klaxon will sound (your device may not support this). On all devices, the externally linked site will open in a new tab in Opera, showing the address bar, so you know where you are.
Differences between Opera and Chrome for Android
Opera’s implementation currently differs from Chrome’s in four main ways:
HTTP-hosted sites will only display with browser UI, regardless of what the manifest states
when the user follows a link that takes the user out of the domain of the installed app, a new tab is spawned, with browser chrome. (Chrome shows a small address at the top of a standalone-app. We prefer to make it more obvious to the user that they have gone outside your app.)
Opera doesn’t (yet) support background_color; this will be added in a forthcoming release.
Chrome has a mechanism to suggest to a user that they add a site to Home screen called App Install Banners, depending on certain heuristics. We are experimenting with the suggestion criteria, and expect to include a similar mechanism in a future release. Chrome requires a 144x144 png icon as one criterion.
Read more, see more
Spec author Marcos Cáceres and Bruce documented what goes in the manifest in an HTML5 Doctor article called HTML App Manifest. You can check out the one we made for Dev.Opera on GitHub. The Chrome team has compiled a list of resources on Progressive Web Apps.
You can also check out how it works on sites with a manifest, for example:
At Opera, we’re excited to promote Web Apps to be “first-class citizens” on Android devices and beyond, with visibility alongside native apps; we love the Web and we want to see it thrive.
]]>https://dev.opera.com/articles/houdini-f2f-report/Houdini Task Force meeting report2015-09-04T00:00:00+00:002015-09-04T00:00:00+00:00Bruce LawsonHoudini is a joint W3C Technical Architecture Group and CSS Working Group initiative to specify hooks into existing CSS. Its primary aim isn’t to give us “new CSS” but to add API hooks into the browsers’ built-in CSS capability so developers can hook into it, use the native implementation where we want (rather than duplicate it) and extend it. It’s applying the Extensible Web Manifesto’s philosophy to CSS. (If you’d like to know more about the aims and back story, read Sex, Houdini and the Extensible Web by Brian Kardell.)
The Houdini Task Force held its first meeting in Sydney in February 2015 and a follow-up in the beautiful offices of Mozilla, Paris in August 2015.
I attended as an observer, as I’ve been excited and intrigued by the project since its inception. In attendance were delegates from Apple, Opera, Mozilla, Microsoft, Google, Adobe, HP, and invited experts like Florian Rivoal and Lea Verou. (See the full participants list.)
What follows isn’t a full record of the meeting, but my notes on the main questions I had; much of the meeting was taken up with discussion of implementation details and, as I wasn’t representing an implementor, they weren’t of primary interest to me. Simon Pieters was formally representing Opera.
(You can read the full IRC logs of day 1 and day 2.)
It’s important to note that many of the specs discussed are very nascent; some of them are little more than boilerplate prose.
I came to the meeting with a concrete set of use-cases that developers had told me they wanted, against which I attempted to measure the utility of the extensions discussed. After all, although one of the recurring jokes of the meeting was “Houdini Group: not immediately useful”, there’s no point in extending CSS for purely philosophical satisfaction; the outcome must be useful to developers at the end of the process.
Sample questions I had:
Will I be able to do sane (but currently impossible) layouts that depend on arbitrary element foo “knowing about” arbitrary element bar and match it/ react to it?
Will I be able to do something as simple and desirable as the proposed (and rejected) text-wrap: balance? (Update: I’m wrong; it wasn’t rejected. It’s in CSS Text Level 4.)
Will I be able to do the much-requested h1 {font-size: just-make-it-big-enough-and-kern-it-pleasingly-so-that-it-fits-the-width} (For example, see fittext.js.)
The first thing on the agenda was the CSS Script API, AKA “CSS Worker” (or maybe “Isolated Worker”; bikeshedding continues) which is a bedrock that much of Houdini depends.
It’s an “API for running scripts in stages of the rendering pipeline independent of the main execution environment. This allows other APIs such as Style/Layout/Paint which effect [sic] different parts of the rendering pipeline to be exposed to the author safely, without major changes to the main execution environment APIs.” Similar to Service Worker, “the CSSWorkerGlobalScope may be destroyed / created at anytime. “
There was concern over performance; Simon Fraser
(from Apple) was reluctant to add too many hooks into CSS that people can hang JavaScript on and slow down the pages, preferring to see declarative methods of achieving effects that the browser can optimise.
I agree, primarily because declarative methods are easier for authors; for sought-after use cases, we shouldn’t require developers to start scripting CSS or downloading libraries. (Also, as Andrea Moreati told me as I was live-tweeting, “CSS and <p> zero days are a lot rarer than JavaScript zero days”.)
But that ship’s already sailed — already, sane additions to HTML like <table sortable> are already batted away with “someone should create a web components library”.
Nevertheless, Ian Kilpatrick (the editor), said that Google have a prototype of CSS Workers and the Custom Layout spec that allows them to replicate a subset of Flexbox in unoptimised JavaScript that’s about half as fast as native.
Custom layout API
The Custom layout API has a minimum set of features balancing making it useful for authors while not striking terror into the hearts of implementors:
Expose minInlineContent/maxInlineContent
AbsPos is handled automatically (in the same fashion as flex/grid).
The custom layout container establishes a formatting context, which implies that:
Floats cannot intrude into the custom layout
Margins do not collapse
Blockify all children (similar to flex/grid)
Float does not have any effect on children of a custom layout container (similar to flex/grid).
No changing paint order (like the CSS order property on flex/grid).
I initially read the latter point (no changing paint order) to suggest that I couldn’t lay out stuff independent of source order (thinking “no” forbade an equivalent to CSS order property). That would be pretty lame; it’s hard to think of an exciting new layout that slavishly follows source order. But I’m a buffoon and W3C’s Chris Lilley set me right: “paint order meaning order in which overlapping items are painted; not layout position.”
Stuart Langridge grumbled “hrm. That’s scripting. I already have scripting. Providing more hooks for js to use is nice, but it’s not CSS”. That’s true; any kind of polyfill/prollyfill uses script to simulate a native implementation.
The difference with Houdini is that you don’t have to emulate everything. You can get the information you need about boxes, heights, widths etc direct from the CSS Engine, via Houdini APIs, rather than have to jump through horrible hacky hoops with JavaScript. Ian Kilpatrick mentioned a previous version of Google Docs in which a font was copied to an off-screen iframe and then measured with JS; in the future™, that information will be available with the Houdini APIs.
Ian explained (after the meeting): “the iframe in Google Docs is subtle. It’s not just specific to Docs. The iframe is used to limit the amount of layout work that is needed to query the element’s width/height. Docs & others who perform layout use this “trick” to contain the amount of layout work, (as the browser only has to layout a small iframe, rather than a large page). They can’t use a trick like FastDom as these layouts are usually iterative. So to do the custom layout, they layout thrash, but only on a small DOM. Custom layout you are performing this layout as part of the layout pass so, querying a child’s width/height is contained to just that subtree (and hence fast).”
Then you plug in whatever custom things that CSS doesn’t currently support, and the browser’s CSS parser continues doing its job, but with knowledge of what you’ve done. Instead of doing all the work yourself, you’re just plugging the hole rather than replicating the entire CSS in JavaScript.
CSS Custom Paint API
The custom paint API allows you to have other things as a background apart from still images. The spec gives an example using canvas and background-image: paint(circle):
Notice this uses a custom property, as defined in Houdini’s Custom Properties and Layout module; the -- prefix is an “empty” vendor prefix (eg, not -moz- or -webkit-, as it’s defined by the individual author.
The script to accomplish this is:
this.registerPaint({
name: 'circle',
dependencies: ['--circle-color'],
paintCallback: function(ctx, geom, properties) {
// Change the fill color.
var color = properties['--circle-color'];
ctx.fillStyle = color;
// Determine the center point and radius.
var x = geom.width / 2;
var y = geom.height / 2;
var radius = Math.min(x, y);
// Draw the circle \o/
ctx.beginPath();
ctx.arc(x, y, radius, 0, 2 * Math.PI, false);
ctx.fill();
}
});
Of course, you could do this with an extra canvas element behind the element that you want to set a background on, but that would require more markup and ensuring that the canvas and the “real” element were always the same size and overlapping.
In a new version of CSSOM, value objects would be preferable, but we can’t rely on TC39 standardising those in time, so it’ll use normal objects (strings are too slow). As this is a “framework dev”‘s API, I raided the Mozilla kitchen for 9 kilos of their excellent goat cheese and gave that my attention.
GCSS
Lea Verou proposed Generalized Cascading Sheets to W3C, so that a general set of rules could be derived so the CSS Parser could be used (hooked into, adapted and — when necessary — over-ridden) by the “proliferation of languages with CSS-like syntax and rules”.
The CSS Parser API gives most of the hooks (although shorthands are currently a mess), and Houdini APIs “expose what the browser does to turn characters into CSSOM”. Google reps were reluctant to add the Cascade to that because their implementation isn’t generic, but that’s easy enough to implement in JavaScript, if you can get specificity of a selector from Houdini (and not all CSS-style languages cascade, anyway).
I’m unclear about what (if anything) was resolved as the next step. If I were implementing, I’d want to concentrate on the core Houdini specs that let web authors do more stuff™ before specifying a meta-CSS for non-web authors, with all the research and cross-interest group argy-bargy that would require, although I agree it’s a useful long-term goal.
Font Metrics
Font metrics API will allow authors to get info about a glyph (and potentially more info about its parent font — does it have an oblique variant, what’s font’s x-height?).
Use cases are things like lining up images with top of a drop cap; exposing font baselines on 2 different things and lining them up.
I think the group didn’t know enough about what designers need to know about fonts to further specify this w/o consulting authors. But it’s early days, and they’d love constructive comments and feedback
Custom Compositor
Custom Compositor was originally called “UI Worker” — here’s a video from BlinkOn3 with the basic use-case spelled out.
Later on it became “CompositorWorker” (and elsewhere, “Async Style”; like I said, bikeshedding continues) with an explainer document that says “the key problem facing the Web Platform is providing a thread that can run user code, respond to input, and update visuals without janking”.
From the explainer: the goals of this API are to
Interact well with scroll customization, Web Animations, and input,
Permit custom effects synchronized with threaded scrolling and CSS animations,
The proto-spec says things like “Exactly once per frame, the browser should run the pipeline from start to finish (i.e. left to right).”
I’m all for APIs that give us a common representation of browsers’ different internal structures, but I’m less sure of a specification that requires a particular order of processing at specified intervals. While the text quoted above seems sensible enough, who’s to say that a browser will never come up with a way to optimise speed or CPU by doing things differently? I’m wary of painting ourselves into a corner or forcing Chromium’s workflow on other browsers here.
Conclusion
When it came to prioritisation, I said (from a highly unscientific process of reading what was said by people geeky enough to be tweeting me on a warm Saturday afternoon) that authors seemed most enthused by Custom Paint, Custom Layout, and Font Metrics.
Many attendees expressed concerns about potentially requiring them to re-factor code to homogenise implementations (rather than simply adding hooks to expose information within their current implementations), and all were wary of performance implications of shipping foot-guns.
The ultimate end-result, of paramount importance to me, is that Houdini doesn’t stop development of declarative CSS by batting all new proposals to scripting against Houdini. I hope it functions as a method for developers to try out ideas which are then rolled back into the declarative language for native implementation and optimisation. Time will tell.
Thank you to Ian Kilpatrick (Google) for corrections and contributions to this report, to Mozilla for hosting and giving me goat cheese, and to the Houdini Task Force for allowing me to attend and providing me with a comfortable cage.
]]>https://dev.opera.com/articles/on-a-moratorium-on-new-browser-features/On PPK’s moratorium on new browser features2015-08-03T00:00:00+00:002015-08-03T00:00:00+00:00Bruce LawsonFamed developer and commentator Peter Paul Koch (PPK) recently called for “a moratorium on new browser features for about a year or so”. If you haven’t read his article Stop pushing the web forward, give it a look; he raises interesting points, as he always does.
(Let us say now: we’re all big fans of PPK; he’s undergone personal attacks for his article — we’re going to disagree with his central thesis, while continuing to love him deeply, and thanking him for starting this discussion.)
In many ways, we Opera devrel folks feel his pain. Each of us is familiar with the feeling of coming back from a vacation and not understanding the Twitter conversations about specs that were launched in the fortnight we were lounging next to a pool / winning hearts with our bachata / touring ancient ruins / having it large in Magaluf / doing emoji poos and wishing we hadn’t eaten so many U+1F364s last night. (Delete as appropriate depending if you’re Bruce, Shwetank, Mathias, Vadim, or Andreas.)
There’s a lot to learn, and the web platform is becoming more complex. Even Ian Hickson, the editor of HTML5, said:
The platform has been too complex for any one person to fully understand for a long time already. Heck, there are parts of the Web platform that I haven’t even tried to grok — for example, WebGL or IndexDB — and parts that I continually find to be incredibly complicated despite my efforts at understanding them
…and that was two and a half years ago!
But it’s not necessary to remember the minutiae of every specification. It’s necessary to know what’s possible, and have access to a search engine to find the spec or tutorials to find details. How many of us memorise the syntax for CSS gradients, or remember every piece of the Web Audio API syntax? But that doesn’t stop us using them when we need to.
But PPK’s complaint isn’t primarily about complexity:
We should focus on the web’s strengths: simplicity, URLs and reach. The innovation machine is running at full speed in the wrong direction.
PPK cites an example:
To me, Navigation Transitions exemplifies what’s wrong with new browser features today. Its purpose is to allow for a smooth transition from one web page to another, to the point of synchronising the animations on the source and destination pages […] We’ve done without for years. More importantly, end users have done without for years, and are quite used to a slight delay when they load another page […] But why do web developers want navigation transitions? In order to emulate native apps, of course. To me, that’s not good enough.
But the point here is that users do want such things, because they’ve now become used to experiences available in native apps. And we know that consumers love the app experience; in April 2014, the mobile analytics firm Flurry reported
Apps continued to cement their lead, and commanded 86% of the average US mobile consumer’s time, or 2 hrs and 19 minutes per day. Time spent on the mobile web continued to decline and averaged just 14% of the US mobile consumer’s time, or 22 minutes per day.
Many of the new “features” coming to the web, like Service Worker or Installable Web Apps, are designed to enhance the web experience for end users — experiences they’ve become accustomed to from native apps but weren’t achievable previously on the web. That’s a win.
We also respectfully disagree with PPK that there’s a dichotomy between adding native-like user experiences and protecting the web’s core strengths of simplicity, URLs and reach.
Let’s address those core strengths in reverse order:
Reach
We’re reaching the point when some organisations are willing to forfeit the reach of the web because they want the features of native. For instance, Myntra does this — and its parent company Flipkart is planning to do so soon as well; they have disabled their site on mobile and urge people to use the app (although you can still use the site on desktop).
Uber’s service is only available through the app. Arguably, that’s understandable because sometimes the Geolocation API is not very accurate on web, and really accurate location info is critical to a taxi hailing service. But that’s an argument for making the Geolocation API better, rather than stopping development.
If we slow development of the web, we risk losing more services to native, thereby diminishing the web’s reach.
URLs
If you get a great big saucepan, and boil the web in it all weekend, periodically skimming off the scum of YouTube comments, porn and photographs of horrible kittens (tautology?), when you look under the lid on Sunday night you’ll find you’re left with URLs. (Or URIs. Or URNs. Who cares what the difference is?)
It’s called “the web” because it’s a network that joins resources together, and those resources are individually addressable.
Modern standards are designed to preserve URLs. Take Service Worker, for example; the explainer document for Navigation Controller (the previous name for what’s become Service Worker) says
It forces you to have URLs! Some modern apps platforms have forsaken this core principle of the web and suffer for it. The web should never make the same mistake.
Similarly, the Web Manifest spec defines a web app’s start and scope in terms of good old-fashioned vitally-important URLs. The proposed Upgrade Insecure Requests spec tries to ensure that no links break if a developer upgrades their server to HTTPS in order to provide a better (more secure) user experience.
There’s a lot the web can learn from native (without slavishly emulating it), but linkability is something that native needs to emulate from the web; see the Rube Goldberg machine-like App Links proposal to see how Facebook is trying to bring “deep linking to content in your mobile app”. We have URLs; PPK is right that we need to jealously preserve them, so modern standards attempt to do just that.
Simplicity
There’s a deeper complexity to the modern web platform than the sheer volume of features. It’s to do with the way the specs were written, the timescale over which they’ve been written and the fact that some features that we rely on have never been specified at all.
One example is HTML5 Parsing. For years, developers had to deal with the different DOMs that browsers constructed from invalid markup (which, as we know, is the vast majority of the web). This was allowed because HTML 4 never specified what to do with bad markup, so browsers were free to do as they saw fit.
HTML5 changed that, and now all browsers worth shaking an angle bracket at produce the same DOM regardless of the validity of the markup. This has produced a huge boost in interoperability, benefitting consumers and saving developers megatons of heartache.
A more current example is XMLHttpRequest which was never formalised and standardised until years after Microsoft implemented it and everyone else reverse-engineered it and copied it.
XHR is hardly a beautiful API, and will be replaced by the Fetch Standard which aims to simplify and unify network requests. Its preface says
At a high level, fetching a resource is a fairly simple operation. A request goes in, a response comes out. The details of that operation are however quite involved and used to not be written down carefully and differ from one API to the next.
Numerous APIs provide the ability to fetch a resource, e.g. HTML’s img and script element, CSS’ cursor and list-style-image, the navigator.sendBeacon() and self.importScripts() JavaScript APIs. The Fetch Standard provides a unified architecture for these features so they are all consistent when it comes to various aspects of fetching, such as redirects and the CORS protocol.
Modern standards are all about explaining the platform to simplify development, and ensuring a solid, understandable foundation upon which to build.
This is built on a design philosophy called the Extensible Web Manifesto. It’s too much to explore here, but The Chair of the W3C Extensible Web Community Group, Brian Kardell, wrote us an article about it called Sex, Houdini and the Extensible Web.
Immediacy
A central pillar of the web that PPK doesn’t mention is what I call “immediacy”. When you make a change to a web site, the next visitor gets the updated version immediately. With native apps you have to publish to an App Store, your user is alerted that there’s an updated version and, when they have Wi-Fi, they’ll update it. Maybe.
Installable Web Apps give us an app-like experience — an icon on the homescreen, potentially working even while offline — but retain the immediacy of the web because the app is hosted on a server. In fact, the app is actually — wait for it — a web site with a URL pointed to by the homescreen icon. We combine the strengths of the web with the user experience of native.
Conclusion
At Opera, a lot our developers work on bringing the web to people who otherwise wouldn’t get it, either with Opera Mini, or by reducing Chromium’s memory consumption so that it works on the lower-specification devices that most of the world uses.
We know that the fastest growing mobile phone markets don’t use apps, so by artificially slowing the pace of evolution on the web, we’re deciding that these people should get a second-class online experience.
It’s imperative, we believe, for the web to continue to add new features — like Service Workers and Installable Web Apps, just as we added native video, the Audio API, the <picture> element, Storage APIs — that extend what the web can do so that it continues to grow and provide the reach that PPK wants, and that we want.
Opera welcomes new developments that make the web better for users. We’re the only browser manufacturer that isn’t also trying to sell an Operating System or locked-down device. So for us, it’s vital that the web continues to thrive — and we believe it’s vital for everybody.
This was written by Bruce Lawson, with input from the rest of Opera’s Developer Relations team. Disagree? Please, write a commentary post and tweet us the link!
]]>https://dev.opera.com/articles/making-animated-themes/Making Animated Themes For Opera2015-07-24T00:00:00+00:002015-07-24T00:00:00+00:00Shwetank DixitSupport for themes has been there for quite a long time, but it was using JPG, PNG or other such non-animated images. However with Opera 32 and above, you have support for animated themes in which you can use a WebM video file or an animated WebP file.
In the video below, you can see an example of animated themes in action.
In the above video, you can see the Still Lake animated theme being installed by dragging the .zip file to the opera://themes page, after which you can see the theme in action when we go to the speed dial page. Later in the video, we open up the preferences page. You will notice that the background theme is applied there too. In fact, the background theme will be visible on all such internal pages.
All themes you install will be visible in the My Themes section of the opera://themes page.
The maximum file size supported for WebM and animated WebP files in themes is 50 MB. Animated GIFs and animated PNGs are not supported.
Making an animated theme
There are four simple steps to make your animated theme and to test it out on your local machine:
Add the required WebM or animated WebP file(s) in a directory.
Specify details about the theme in a persona.ini file.
Zip up the persona.ini file along with the WebM or animated WebP file(s).
Go to opera://themes. Drag and drop the .zip file to the window.
If all things are valid, your theme should be installed in the Opera browser running on your local machine.
You can easily make an animated theme using the theme creator in Opera.
Open Opera and go to opera://themes.
On the left hand side menu, click on Create your theme.
Enter relevant details and select the WebM or animated WebP file you want.
Click on the Create button.
The persona.ini file
The persona.ini file is just a file which lists essential details about the theme. This includes the theme name, the author, name of the .webm file(s) you want included in the theme, and other such things. Let’s see a sample persona.ini from Still Lake theme to know more.
; Licensed under CC-BY
; Video by NatureClip
; http://natureclip.co.nr/
[Info]
Name = Still Lake
Author = Vadim Makeev
Author URL = http://pepelsbey.net
Version = 2
[Start Page]
Background = video.webm
Position = center bottom
First Frame Image = firstframe.jpg
[Web UI Pages]
Background = cover.jpg
Position = center bottom
The [Info] section contains all the information about the extension. The things you lists under it are the following:
Name: Title of the theme.
Author: Author name.
Author URL: A URI that points to the author’s home page or e-mail. Valid schemes are http, https, and mailto.
Version: Version 2 indicates themes for Opera 18 and higher.
The [Start Page] category lists the details required for the theme when start page is displayed. The start page is the page displayed whenever you open a new tab (this typically includes the speed dial view you see). You need to list the following things under this section.
Background: File name of the image that goes behind Speed Dial.
Position: Position of the start page image — optional, any CSS keyword for position: left, top, right, bottom, center.
First Frame Image: An image of the first frame of the video. This is useful as a fallback image in case the video takes a slight delay to come up. (Note: This fallback image will automatically created by the server if you have upload your animated theme to the Opera add-ons catalog, so you only really need to mention this if you don’t plan to share your animated theme through the add-ons catalog). This is available on Opera 35 and above.
The [Web UI Pages] section lists the things needed for the other web UI pages. For example, the downloads, settings, and extension management pages.
Background: File name of the image that goes behind other pages.
Position: See above for positioning details.
In the above section, we just used a .jpg image here. However, we could use another video here too (and even include a First Frame Image file as a fallback for it if we desire).
You can includes comments in the persona.ini page as well. They need to be in a separate line of their own, and need to be started by a semi-colon ;.
Keep in mind you can set different resources for the Start Page and the Web UI pages. So you can have, say, a video file for the Start Page (this will also be reflected in the history, tabs, bookmarks page and themes management page) and another video (or even image) for the Web UI pages (which will be reflected on the downloads, settings, plug-ins, password management page, and extension management page).
It is important to note that the video or animated WebP only consumes resources when it is in view. When you are not browsing an Opera internal page, then the theme will not be visible, and hence will not consume resources.
Choosing the right background animation
There are a few things to consider when making an animated theme. The video being used should look nice as a background, and preferably should look good when played in a loop. If you intend to submit the theme to the Opera Addons Catalog, then it should abide by all the relevant acceptance criteria. If the source video requires attribution, then please provide that in the description text in the addons page (and if you want, then as a comment in the persona.ini file as well.)
Testing and uploading to the Opera Add-ons catalog
Once you have zipped up the persona.ini file along with required .webm or animated WebP files, and have tested it out by installing the theme in your local Opera install, you’re ready to publish it on the Opera Add-ons catalog.
Just head over to the Upload Add-on section of the Opera Add-ons catalog, and submit your theme. Once the moderator approves, it will be published on the Opera Add-ons catalog.
]]>https://dev.opera.com/articles/making-sites-work-opera-mini/Making websites that work well on Opera Mini2015-06-03T00:00:00+00:002015-06-03T00:00:00+00:00Bruce LawsonI recently gave a keynote talk at Velocity conference called “Ensuring a Performant Web for the Next Billion People” about the importance of developing economies and their use of proxy browsers such as Opera Mini.
Slides are available and here’s the 20 minute YouTube video made by the organisers.
The most common question I got in the hallways was “How can I make my site work well in Opera Mini?”. The answer is simple: use the development methodology known as Progressive Enhancement.
Note that throughout this article, when we refer to “Opera Mini” we mean the full proxy version: that is, Opera Mini/iOS in Opera Mini mode, Opera Mini/Android in Extreme Mode, and any version of Opera Mini on Windows Phone or feature phones. When testing your sites on iOS or Android, please ensure your device is in these modes. (More on Opera Mini modes.)
Progressive Enhancement
Progressive Enhancement is not a new technique; in fact, it’s built into the very fabric of the web’s original design, and ensures your website works everywhere — not just on Opera Mini and other proxy browsers.
Send HTML to the device
HTML is a lightweight text format that allows the browser to get to work straight away. It’s become bizarrely fashionable to send JavaScript (with a framework such as Angular, for example) which must be parsed and executed before it can do the same job as plain HTML. This slows the site down and uses more CPU.
Therefore, Progressive Enhancement is better for all users. Airbnb wrote:
We’ve launched our first Holy Grail app into production! […] It looks exactly the same as the app it replaced, however initial pageload feels drastically quicker because we serve up real HTML instead of waiting for the client to download JavaScript before rendering.
Plus, it is fully crawlable by search engines. […] It feels 5× faster.
Use SVG rather than icon fonts
Opera Mini doesn’t download web fonts; these are often large files, and are for aesthetic/branding purposes. Fallback fonts are used instead. On many low-specced devices, system fonts are carefully optimised for the device and give a better user experience.
However, icon fonts are sometimes used by developers and these won’t be displayed; this can mean some important information or navigation items are invisible. Use SVG images instead; these can be compressed to become smaller than icon fonts, and can be made responsive with media queries.
This doesn’t just benefit Opera Mini users; many people with mild dyslexia have a special system font to aid legibility, which breaks icon fonts. See Seren Davies’ presentation Death to icon fonts which explains how icon fonts impact her dyslexia.
Style your HTML with CSS
Opera Mini deliberately disables some CSS which would otherwise need to be converted to bitmap images and would therefore bloat page size.
Most notably, CSS border-radius isn’t rendered. CSS animations are similarly disabled, to preserve battery life.
CSS gradients are also disabled. Ensure that, if you’re using a gradient as a background, that you also set a CSS color for the background that contrasts well with text. A common error is white text on a gradient and leaving the default white background unchanged; in Opera Mini this results in illegible white-on-white text. So, for example:
button {
background: black;
/*
Fallback for Mini and other browsers
that don’t support CSS gradients
*/
background: linear-gradient(
to bottom right,
red, rgba(255, 0, 0, 0)
);
color: white;
}
Opera Mini is sent a black background for the white text, and so the button’s text is visible; this is overridden in browsers that support CSS gradients.
Test your site without JavaScript
Test your HTML and CSS site with JavaScript disabled. In Opera Desktop, for example, open the Developer Tools (right-click anywhere, choose “inspect element”, click the settings cog icon, check “Disable JavaScript”).
Everything should still work, although it will probably be much more clunky. That’s OK; if your site works clunkily and your competitors’ sites don’t work at all, you’ll get the business.
Ensuring your site functions without JavaScript doesn’t only benefit proxy browser users; research by GDS, the UK Government’s Digital Services agency, shows that 1.1% of browsers don’t run JavaScript for various reasons: the user may have disabled it, or corporate firewalls block it, for example.
Opera Mini runs some JavaScript on page load, but JavaScript-only APIs don’t work. Treat JavaScript as an enhancement to your core HTML site, not as a pre-requisite.
Making sure your site loads fast is a must — for all browsers, not just Opera Mini. To help you, Google published Optimizing Performance in their Web Fundamentals course.
Other considerations
If you rely on some sort of Geo IP tool for detecting a visitor’s location, note that the IP address you find in the headers is that of our compression proxy. The user’s original IP address is passed on via the X-Forwarded-For HTTP header. (Read more about Opera Mini request headers.)
A note on version numbers
Because Opera Mini renders on our servers, all Opera Mini clients use the same server version, so all use the same Presto version. JavaScript and CSS support is therefore identical on all clients, with the exception that user may enable Small Screen Rendering which removes a lot of CSS rules.
Version numbers refer to different versions of the client UI and capabilities (whether it supports night mode, private tabs, progressive loading, etc.)
Opera Mini 4.x clients load the whole transcoded page at once, as they have no progressive loading. This slightly reduces the time allowed for JavaScript execution (including XHRs). With newer clients, the transcoder is more generous, since it is able to send the compressed page to the client in chunks.
Testing in Opera Mini
There are several ways to do this.
Download Opera Mini
You can download Opera Mini onto your device, of course. Point your pocket-dwelling chum at m.opera.com and download it for Android, iOS, Windows Phone or any generic feature phone — Opera Mini works on 3000+ different devices.
Set the browser to the correct mode
If you’re using the iOS version, note that you have to switch it to Mini mode to go through Opera’s Mini servers (this mode is not the default). Tap the red “O” menu, and choose “Opera Mini”. Opera Mini for iOS also compresses videos. See more information about Opera Mini for iOS.
If you’re using Opera Mini 11 for Android (or later), ensure that the browser is set to Extreme (this is the default). Tap the red “O” menu, and ensure that “Savings mode” next to the Data Meter is set to “Extreme”; tap to change if not. (More about Opera Mini 11 for Android.)
Test from Desktop
For development and testing purposes, it can be useful to install Opera Mini on your computer. You’ll need Java and MicroEmulator, in which you’ll run an instance of Opera Mini for J2ME-enabled feature phones. Installing Opera Mini on Your Computer has all the information you need.
Many developers choose to use ngrok to securely expose a local web server to the internet. As their website explains, “ngrok creates a tunnel from the public internet (https://subdomain.ngrok.com/) to a port on your local machine. You can give this URL to anyone to allow them to try out a web site you’re developing without doing any deployment”. Then you simply point Opera Mini at subdomain.ngrok.com to test your site. ngrok is open source, and also provides a paid-for service.
Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.
]]>https://dev.opera.com/articles/browsers-modes-engines/Opera Browsers, Modes & Engines2015-06-02T00:00:00+00:002015-06-02T00:00:00+00:00Andreas BovensThe Opera browser is available on a wide range of platforms, in a number of flavors with different modes, engines and levels of standards support. As things can get somewhat confusing — did you know that Opera Mini on iOS comes with three rendering modes, one of which is powered by UIWebView & Opera Turbo? — we decided to create a simple product overview that details some of these technical differences.
We’ll keep this table as up-to-date as possible, so be sure to bookmark this page for later reference!
: these modes (powered by our Opera Turbo servers) also have a Video Boost compression option.
† : when in High mode and connected to Wi-Fi, data savings are disabled, unless the user has explicitly opted in by activating the Wi-Fi data savings option in Settings.
Opera Turbo mode compresses data up to 80%. Opera Mini mode compresses data up to 90%.
If you’re doing IP-based geo-detection, you should always check if there is an X-Forwarded-For header. That way, you can also correctly locate browser users using proxy functionality, powered by Opera Mini and Opera Turbo.
Opera Mini comes with “limited” standards support: this means that advanced JavaScript, CSS and other dynamic elements might not work as expected, due to the peculiarities of server-side rendering and limited client capabilities.
Older Presto-powered Opera products that are no longer under active development, such as Opera 12 for computers, Opera Mobile Classic, etc. are not listed here.
]]>https://dev.opera.com/articles/drum-sounds-webaudio/Synthesising Drum Sounds with the Web Audio API2015-05-26T00:00:00+00:002015-05-26T00:00:00+00:00Chris LowisThe Web Audio API
The Web Audio API is a new way of working with audio on the web. It provides a way to playback pre-recorded audio, synthesise arbitrary new sounds and control the precise moment of sound generation accurately and reliably, irrespective of what else is happening in your application.
In this article, we’re going to learn more about the API by building a simple drum machine. We’ll learn just enough about the API to play a simple loop constructed from sounds we synthesise ourselves, and we’ll see how to use recordings of real-life sounds too. From these bare bones, you’ll be able to extend the machine yourself, or apply the techniques you’ve learnt to other applications. Let’s get started!
Sampling or synthesising?
Early on, we have a decision to make. Shall we synthesise the sounds of our drum kit from scratch in the computer, or shall we use a recording of real-life sounds — a technique also known as “sampling”? There are pros and cons to both approaches.
Synthesising, recreating the sound of a drum using a model of its acoustics and attempting to recreate that model in code, gives us infinite control, but it can be very difficult to accurately synthesise a realistic sounding drum. Sampling on the other hand means we can start with any sound we like, but we are limited to just that sound, perhaps with some simple transformations (playing the sound back faster or slower, or applying some effects, for example).
In this article we’ll try and create something that sounds a bit like the classic electronic drum machine, Roland’s TR-808. We’ll synthesise the kick and snare, and create a hi-hat sound from a recording of the original machine.
The kick
We’ll kick off with the basis of all good drum loops, the kick drum. To generate audio using the Web Audio API, your browser needs to know about the sound producing device available to your computer, and what capabilities it has. This information is contained in the AudioContext.
var context = new AudioContext;
console.log(context.sampleRate);
// → 44100
console.log(context.destination.channelCount);
// → 2
We can describe audio digitally as a series of numbers. Each number describes the amplitude of the sound at a particular point in time. We call each one of these numbers a “sample”. (“Sampling” gets its name from the process of turning a recording of a real sound into a series of samples.) Calling context.sampleRate tells us how many samples per second our device can produce. A typical sample rate is 44,100 samples/second, as this is sufficient to reproduce sounds at frequencies as high as we humans can perceive. context.destination.channelCount gives the number of simultaneous channels of audio our device can produce — on my computer that’s two: one for the left speaker, and one for the right.
It would be possible, but not very user-friendly, to create the sound we want to make by giving the computer 44,100 numbers per second, if we knew which numbers to give it to create the sound of a kick drum. But the Web Audio API makes the process easier by providing us with a higher level, declarative set of commands to describe to the computer how to make the sound we want.
var oscillator = context.createOscillator();
oscillator.frequency = 261.6;
oscillator.connect(context.destination);
oscillator.start(0);
If you type the code above into your developer console, you should hear a low-pitched, single frequency tone at 261.6 Hz (if you’re a musician, that’s a middle C).
Make it stop? OK.
oscillator.stop(0);
There’s a few things to note in the code above. Firstly createOscillator is a method on context — it needs to know about the audio environment it’s operating in to generate the sound. All of the applications you build with Web Audio will work within an AudioContext.
Secondly, we connect the oscillator to the destination of the context. This is an important concept within the Web Audio API. We call oscillator and destination instances of “nodes” and by connecting them together we create a graph. (This diagram was generated using the Web Audio developer tools in Firefox Developer Edition.)
Node graph of oscillator connected to destination
Thirdly, calls to start and stop take the time as an argument. 0 means to perform the operation immediately, but we can supply any argument and it will be interpreted as the number of seconds from now. What time is now?
If you’ve worked with other timing mechanisms in JavaScript before, such as setTimeout, this concept of time may be slightly unfamiliar. Here, when we say start(0.5) the browser will attempt, as much as it can, to play the sound in half a second, and unlike setTimeout, will not interrupt this as much as practical. This is essential for our drum machine, as we want to schedule sounds precisely and with an exact rhythm.
Back to our kick drum. A lot of people have researched the acoustics of drums and how they make sound. I’ve included some further reading at the end of this article if you’re interested in this fascinating subject. For two-skinned drums, such as the kick drum, they’ve noticed that the sound starts at a higher frequency — the ‘attack’ phase when the striker hits the skin — and then rapidly falls away to a lower frequency. While this is happening, the volume of the sound also decreases. Once we’ve struck the drum there’s nothing to keep producing sound so it simply decays. Let’s tackle the latter part, the “envelope” of the sound, first.
var oscillator = context.createOscillator();
oscillator.frequency = 150;
var gain = context.createGain();
oscillator.connect(gain);
gain.connect(context.destination);
var now = context.currentTime;
gain.gain.setValueAtTime(1, now);
gain.gain.exponentialRampToValueAtTime(0.001, now + 0.5);
oscillator.start(now);
oscillator.stop(now + 0.5);
In the code above, we’ve created this audio graph:
Node graph for an oscillator with an envelope
A gain node is like a volume control. We can use that to control the amplitude of our oscillator over time. It has a parameter gain which we can automate. We do that by calling the functions setValueAtTime, which sets the gain to be 1 at time 0 and exponentialRampToValueAtTime which decreases the gain to close to zero over the next 0.5 seconds. Any parameter on any node in the Web Audio API can be automated in this way if it implements the AudioParam interface:
Armed with this knowledge, we now know how to complete our kick drum synthesis: by dropping the frequency of the oscillator rapidly after the initial attack.
oscillator.frequency.setValueAtTime(150, now);
oscillator.frequency.exponentialRampToValueAtTime(0.001, now + 0.5);
If you’ve been following along with the code in this article, you may have noticed that once you call stop on an oscillator, it’s impossible to call start again. This is intentional — it allows the browser to garbage-collect the nodes more efficiently in large audio graphs — but it does make working with these drum sounds more complicated as we’d like a way to trigger them multiple times. We can solve this by wrapping the code we’ve written in a simple object:
We store a reference to the audio context when we create the kick, and then each time we trigger the kick sound we can pass in a time, which creates the audio graph and schedules the parameter changes.
var kick = new Kick(context);
var now = context.currentTime;
kick.trigger(now);
kick.trigger(now + 0.5);
kick.trigger(now + 1);
The Snare Drum
A snare drum has a rigid shell holding two, taut drum membranes. When the top membrane is struck, a series of wire springs held underneath the lower membrane rattle in sympathy. There’s a complexity to the snare sound that makes it more challenging to synthesise. But we can tackle it in stages to make the process easier.
First, the rattle of the wire snare underneath the drum can be synthesised using a burst of noise. We can create noise using a random number generator.
function Snare(context) {
this.context = context;
};
Snare.prototype.noiseBuffer = function() {
var bufferSize = this.context.sampleRate;
var buffer = this.context.createBuffer(1, bufferSize, this.context.sampleRate);
var output = buffer.getChannelData(0);
for (var i = 0; i < bufferSize; i++) {
output[i] = Math.random() * 2 - 1;
}
return buffer;
};
In this code we create a “buffer” of individual samples, which we can later trigger at a precise time. The call to createBuffer specifies that the buffer has a single channel, 44100 individual samples, at a sample rate of 44100 Hz. That is, 1 second of audio in total. This should be sufficient for our purposes since the sound of an individual snare hit is very short.
We fill the buffer with random numbers between -1 and 1. This even distribution of random numbers creates “white” noise, which is noise with equal energy at every frequency. Removing some of the lowest frequency sound from this noise creates a more realistic sounding snare. We can do that using a filter:
We set the cutoff frequency of the filter at 1000 Hz. This means noise below 1000 Hz will be removed. We also need to shape the amplitude of the noise burst using an envelope, as we did before with the snare drum.
A short burst of filtered noise on its own doesn’t create a very good sounding snare. Adding a sharp “snap” to the front of the sound helps to make the snare sound more percussive. We can achieve this using an oscillator set to generate a triangle waveform, and again shape that using a GainNode as an envelope.
We have created this graph of nodes for our snare sound:
Node graph for an synthesised snare
Now we just need to provide some parameters for each of the nodes. After some fiddling, I found these parameters created quite a satisfying, snappy snare:
Synthesising a realistic-sounding hi-hat is hard. When you strike a disk of metal the sound that is produced is a complex mixture of unevenly-spaced harmonics which decay at different rates. It’s not an impossible task, and if you’re interested there’s some further reading below, but for this post we’re going to cheat a little by sampling an existing sound. By doing this you’ll also learn how sampling, taking short recordings of sound and using them as the basis of new sounds, can be achieved with the Web Audio API.
When we instantiate the HiHat object, we give it a buffer of samples. The setup function assigns the buffer of samples to a BufferSource node, and calling trigger plays the samples back at the given time.
Where do we get our source buffer of samples from? Remember from our snare drum example earlier, we generated a buffer using a random number generator. But we can also create one by loading a file:
var sampleLoader = function(url, context, callback) {
var request = new XMLHttpRequest();
request.open('get', url, true);
request.responseType = 'arraybuffer';
request.onload = function() {
context.decodeAudioData(request.response, function(buffer) {
callback(buffer);
});
};
request.send();
};
This function takes a URL of a sound file and makes an asynchronous GET request for it using XMLHttpRequest. When the data is loaded, the call to context.decodeAudioData turns the audio file into a buffer of samples, and triggers a callback. The file formats that decodeAudioData understand are the same as those supported by the <audio> tag in your browser. In Opera, OGG, WAV and MP3 are supported, for example.
Remember that the network and decoding requests are asynchronous, so we have to wait until they are completed before we can create the HiHat that uses the loaded buffer:
sampleLoader('./hihat.wav', context, function(buffer) {
var hihat = new HiHat(context, buffer);
hihat.trigger(context.currentTime);
});
Timing
In this final section, we’re going to combine the three drum sounds we’ve made into a simple loop. As we’ve seen, the Web Audio API provides a precise timing mechanism which allows you to schedule audio events to happen relative to the AudioContext’s currentTime.
Internally, the browser is executing these events on a thread that is separate to the thread in which normal JavaScript events are run. This means that there is overhead in passing data between the two threads. For this reason, it is not possible to create a callback that fires when an audio event happens (such as when one of our drum sounds starts or stops playing), and register changes in reaction to this (such as scheduling a new drum sound to play).
To build a loop, especially one where we have control over the tempo, the parameters, and which notes play, we have to listen for changes in the main thread, and schedule those changes to happen in the future on the audio thread. We don’t want to schedule them too far in the future though, as this makes our application unresponsive. Scheduling them too soon is also a problem — we might cause glitches in the sound if something happens in the rest of our application and we miss the scheduling of the changes.
In this HTML5 Rocks article, Chris Wilson describes the issues with timing in more detail and gives some code examples of good and bad practice. Other developers have taken these ideas and wrapped them up in libraries that make working with time in Web Audio applications much easier:
WAAClock packages the ideas from Chris Wilson’s article into a library, with a simple interface and some clear examples.
Dilla is a timing library specialised for building drum machines. It models the concept of beats, bars, and loops and has a notation language for describing the timing of sounds in the loop.
Tone.js is a comprehensive set of libraries for making all kinds of sounds. As well as a timing library, it also has built-in synthesisers and effects processors which provide abstractions over more complicated Web Audio node graphs.
All of these libraries make it easy to build a simple loop, and it’s a fun exercise to try each one and see which one is the best fit for you and the application you are building. As an example, I’ll use Tone.js to build a simple loop.
var play = function(buffer) {
var kick = new Kick(context);
var snare = new Snare(context);
var hihat = new HiHat(context, buffer);
Tone.Transport.bpm.value = 120;
Tone.Transport.setInterval(function(time){ kick.trigger(time) }, '4n');
Tone.Transport.setInterval(function(time){ snare.trigger(time) }, '2n');
Tone.Transport.setInterval(function(time){ hihat.trigger(time) }, '8t');
Tone.Transport.start();
};
sampleLoader('./hihat.wav', context, play);
In this code, Tone.Transport is the interface to the Tone.jstiming library. We set a tempo for our loop using the bpm property — here 120 beats per minute. The Transport.setInterval method is used to schedule repeating events. We can think of it as working like a regular setInterval but for scheduling of events relative to the audio clock. The time value passed to Transport.setInterval can be expressed, as here, in a musical way rather than in seconds. 4n means 4 beats to the bar, 2n is two beats and 8t creates eighth-note triplets on the hi-hat. The value is converted into seconds and passed in as the time parameter to our trigger methods, so we don’t need to modify our code to work with this library.
Finally, we call the play method when the hi-hat sample has loaded, which starts our loop. We haven’t loaded Tone.js into this page, so if you’re following along in the console, try the code on the demo site.
Conclusion
In this article we’ve seen how to synthesise and sample drum sounds and combine them as a loop. We’ve learnt the basics of the Web Audio API and seen how to solve some common problems. If you’d like to play with the code and hear it in action, I’ve put it on GitHub, and if this article has piqued your interest in the Web Audio API, you might be interested in my weekly newsletter Web Audio Weekly where I share links, tips and news from the Web Audio community.
Further Reading
We’ve only scratched the surface of drum synthesis in this article. For further details you might find these resources helpful:
The Synth Secrets series from Sound on Sound magazine is a goldmine of interesting articles on synthesis using hardware synthesisers. With some thought, many of the techniques can be recreated using the nodes provided by the Web Audio API. The articles on synthesising a snare drum, kick drum and cymbal were very useful for this blog post.
The Dance Music Manual by Rick Snoman is an in-depth look at electronic music production and has a very informative section of drum machine synthesis.
]]>https://dev.opera.com/articles/fixing-the-scrolltop-bug/Fixing the <code>scrollTop</code> bug2015-05-20T00:00:00+00:002015-05-20T00:00:00+00:00Simon PietersThe CSSOM View specification has a handful of widely-implemented properties on the Element interface related to scrolling: scrollTop, scrollLeft, scrollWidth, scrollHeight. These give the current scroll position of the element, and the size of the scrolling area. scrollTop and scrollLeft can also be set to cause a scroll. When these are used on the root element, they instead reflect the scroll position and scroll area of the viewport. The clientWidth and clientHeight properties similarly reflect the viewport dimensions instead of the element’s dimensions for the root element.
However, WebKit (Safari) and Blink (Chrome and Opera) do not behave this way. They make the body element reflect the viewport instead, and the root element returns 0 and does nothing on setting. IE11 and Firefox follow the specification. This is an interoperability problem that Web developers have to work around in some way, possibly by UA sniffing.
We want to fix this bug, but we need your help to fix sites that rely on the bug based on UA sniffing.
What’s bad about the WebKit/Blink behavior?
In general, we want to avoid special-casing the body element and just let the root element be “the viewport element”. Also, the body element can be independently scrollable from the viewport, by setting the overflow property on both html and body to something other than visible. In WebKit and Blink, the scrolling APIs on body in this case still reflect the viewport, rather than the body element itself.
Both WebKit and Blink have previously tried to fix this bug, but had to revert because there were Web pages that expected the buggy behavior when the browser identified as “WebKit”.
Project Spartan / Edge
Microsoft’s latest browser engine, codenamed Project Spartan and used in the upcoming Edge browser, also identifies as “WebKit”, like WebKit and Blink, and so they have to copy WebKit/Blink’s bugs in order to be compatible with the Web.
Quirks mode
Quirks mode is the mode that browsers use for documents without a doctype or an “old” doctype, to be more compatible with the behavior of old browsers. In quirks mode, all browsers use the body element to reflect the viewport for the scrolling APIs. This is also specified in the CSSOM View specification. (However, contrary to the behavior of current WebKit and Blink, if the body is independently scrollable, the scrolling APIs will reflect the element itself instead of the viewport.)
Typical workarounds
There are several strategies for dealing with this interoperability problem, but they are all problematic in one way or another.
Using APIs on window instead
scrollX/scrollY or pageXOffset/pageYOffset give the viewport’s scroll position and window.scrollTo(x, y) scrolls the viewport. This is what e.g. jQuery does.
Problem: scrollX, scrollY, pageXOffset, and pageYOffset are not supported in IE8 and below.
Using both elements
For example, for getting:
var y = document.documentElement.scrollTop || document.body.scrollTop;
or
var y = document.documentElement.scrollTop + document.body.scrollTop;
Problem: This prevents browsers from fixing the bug. We need to fix this!
How do I know if my site is affected?
Is your page in quirks mode? Check document.compatMode in the console in the browser’s web developer tools. If it says BackCompat, you’re not affected (but you should not use quirks mode!).
Run Chrome or Opera with chrome://flags/#enable-experimental-web-platform-features enabled (or more specifically with the --enable-blink-features=ScrollTopLeftInterop command line flag). This makes Chrome/Opera use html as the scrolling element (in standards mode).
See if your site still works. If something is now broken, possibly your site is using UA sniffing to determine html vs body for scrolling APIs.
Towards a fix: document.scrollingElement
In order to have a reliable alternative to UA sniffing, we are introducing a new API to get the right element for scrolling the viewport.
Use the document.scrollingElement polyfill and switch from document.documentElement or document.body to document.scrollingElement when using e.g. scrollTop to scroll the viewport.
Feature-check for scrollingElement support and fall back to your current workaround (falling back to a UA check is OK).
If you notice that a JS library uses UA sniffing to get “the scrolling element”, or that a site is broken with chrome://flags/#scroll-top-left-interop enabled in Chrome or Opera, please file an issue in Chromium’s bug tracker. Include “ScrollTopLeftInterop” in the summary. Thank you!
Summary
Browsers disagree on whether html or body reflects the viewport for scrollTop et al. Some sites are using UA sniffing to decide which to use. Browsers want to align and use html (in standards mode), so sites that UA sniff need to be changed. Use the document.scrollingElement API if available, and fall back to a polyfill or UA sniffing. If you notice any problems, let us know!
]]>https://dev.opera.com/articles/worldreader-interview/Spreading knowledge in the developing world for free: An interview with the Worldreader team2015-05-18T00:00:00+00:002015-05-18T00:00:00+00:00Shwetank DixitI recently got to ask some questions with the team from Worldreader — a non-profit organization which provides free e-books to people in developing countries. It’s fascinating work, and something which presents its own challenges and rewards. Their target demographic is unusual for most web developers, especially those who live in developed economies.
The following interview will highlight some aspects of their work and their organization.
Please let our readers know about what Worldreader is, as an organization?
Worldreader is a global non-profit organization providing access to free e-books in the developing world, be that digital textbooks in schools, children’s leveled readers in libraries, or novels and short stories on mobile phones. The organization was established in 2010 and has since built a digital library of over 15,000 culturally relevant books, distributed on nearly 10,000 Kindles to students across sub-Saharan Africa, and via two mobile phone apps that have been downloaded on more than 2 million low-end feature and smart phones across the world. Through our efforts and our partnerships with device manufacturers, mobile operators, teachers, governments, and the communities where we work, Worldreader is working towards a world in which every child and her family have the books they need to improve their lives, the practice of reading is commonplace, and where illiteracy is a thing of the past.
What is your app, Worldreader Mobile, all about?
Worldreader Mobile is a single place to discover, read, and collect free e-books in a variety of languages, from different parts of the world. It’s an app that enables reading anywhere, anytime since it’s available on any internet-enabled mobile phone, including the simplest of feature phones. Readers from all over the world, and especially in areas facing poor connectivity and shortage of physical books, can enjoy a library of digital books in 70 genres and 44 languages. From textbooks, to fiction novels, to health information, to short stories — all books on Worldreader Mobile are designed to empower and improve people’s lives.
You already have native applications for Worldreader, but now you’ve placed heavy emphasis on the web platform too. What, in your opinion, makes the web such an attractive platform, especially for an application like yours? What are the advantages that the web provides, compared to other platforms?
Our goal is to reach as many people as possible with the books they need to succeed in life. A web app, by nature, is the right choice for working towards reaching this goal since it breaks down barriers of access. Web apps are device agnostic and require no app stores. Users of our reading application only need a connected mobile device, a browser and they’re on their way to getting lost in the world of e-books.
Proxy based browsers like Opera Mini are really popular amongst the target demographic of Worldreader. What steps did you take to ensure a great reading experience, especially for proxy browsers like Opera Mini?
Proxy browsers are commonly used on small-screen devices, so we took that into account when laying out the book for reading. We formatted the text so that it didn’t have any large tables or images that would break the layout. The user interaction capabilities also needed to be taken into account; everything was to be formatted in a single column to avoid the need for horizontal scrolling and, on keypad devices, keeping the scrolling consistent with link selection. The goal was to make it so you only have to use the down and center buttons to read a book. In addition, we added some tips to Opera Mini’s shortcuts to remind people how to scroll one page at a time.
Worldreader categories & book details in Opera Mini
The buttons were designed in such a way that accommodates how fast users can scroll from the top of the page to the buttons. This was mainly for the bracket-based navigation, which is still used in older versions. We placed one menu link at the top of the page instead of multiple links to avoid users having to press a new button to skip each link before being able to scroll. Many of our users have inexpensive mobile devices with lower quality touchscreens and so, to ensure the experience remained optimal for these users, we produced larger buttons that facilitate navigation on all devices.
What are some of the challenges you faced when making the web app, and what approaches did you take to solve them?
While building the offline readability function for the web application, some challenges were faced. It was essential that our users be able to download books and read them offline. In the Opera Mini setting, programing logic to the page to enable offline reading was not possible. To work around this, we created a solution leveraging the built-in saved pages functionality in Opera Mini. To read a book offline now, the user goes to a specific “Save for offline” version of the book, which he or she can then save to the browser’s saved pages as if it’s a single page.
Keyboard input is another feature we took into consideration. From previous feedback we knew that users often get discouraged when required to type in excessive amounts of personal details. Therefore, the app allows readers to immediately start reading a book without a user account. If they do choose to create an account in order to benefit from extended features, they simply need a username and password.
What improvements or changes (whether it was performance, or other factors) did you see with the web application?
One of the biggest differences we see with our web app, in comparison with our other native apps, is the reach. The amount of people reading on a daily basis using the web app has significantly increased. This is primarily thanks to our partnership with Opera, who have exposed our app to their users in Africa. We also see a lot of social interaction on the web app: our users like to share their current reads with friends through social media.
What is next for the Worldreader web app? What improvements could users expect with further updates?
We are continuously working on improving the overall user experience. Further updates will work towards creating a lighter and faster reading experience with improved design and the option for readers to localize the app in several languages: initially Arabic, French, Spanish and Swahili. The content of the library will also continue to expand, with relevant content, in an increasing range of languages. Lastly, we aim to encourage a culture of reading by adding features that give rise to social activities related to books, such as reading clubs.
Best of luck for the future. Worldreader has touched the lives of so many, and we hope it continues to do so for millions more.
Thank you!
]]>https://dev.opera.com/articles/houdini/Sex, Houdini and the Extensible Web2015-05-11T00:00:00+00:002015-05-11T00:00:00+00:00Brian KardellThe backstory
When the Web was created, it was a really big idea: Tim Berners-Lee proposed (it wasn’t a standard yet) a worldwide system to retrieve documents coded in such a way that one document could link to another document. Although the idea was big, it was really simple. It was declarative and forgiving and had a clear, familiar mental model. Nearly everyone was familiar with a book, nearly everyone had written (or at least gotten) a letter, nearly every business was built around paper, so it was designed similarly.
Here is what the first website looked like, and for a little while it was representative of the state of the art. It was what the small handful of users that Tim convinced to try it out expected from the Web.
The simplicity and high-level aspects of the Web were an incredible boon. As more hobbyists learned that they could create content, they did. More content to draw people to the Web, in turn lent more credibility and encouraged more people still to have a look and get involved.
As they did, a number of people brought new ideas about how it should work. They extended the language and very quickly, as author Matt Ridley explained in his 2006 TED Talk: Their ideas had sex. They mixed and combined, inspiring new, more complex and better innovations making both the user and developer experience markedly better. This is natural because sexual reproduction is, in biological and evolutionary terms, one of the key ingredients that allows nature to arrive at logarithmically complex design. Through sharing of ideas we very quickly added things like forms, images, image maps, and tables. We also got started on CSS. Within just a year or two from the earlier picture, the state of the art looked more like this:
So ideas bloomed, but almost as importantly: Some things entirely failed to catch on. They just weren’t right. Tim’s original proposal for HTML contained only 20 tags and more than a third of them (7) weren’t ultimately standardized.
As the Web grew, the impact of this positive feedback loop increased, and the need for stability became apparent: If the Web starting fragmenting, the feedback loop would be broken and the whole thing would be doomed. Thus, the W3C was formed to ensure that the Web remains built on free and open standards.
A paradigm shift
Some interesting things happened between then and now: The DOM was introduced, and it was scriptable. Standards remained stable for a long time while the W3C worked on a potential successor (XHTML2) and in this stability developers turned to solving problems for themselves.
Previously, “innovation” happened by vendors creating proprietary extensions which, by nature, were incompatible. Now, however, innovation was happening in libraries. Libraries were built on standards, so they would work for everyone. Freed from processes, their ideas again had sex: They combined, competed and improved.
Once again, some things failed, but all of them (successful or not) were wrapped up in non-standard libraries. It was an interesting trade-off and introduced new dynamics: Instead of being able to get increasingly better at using standard APIs, many people got increasingly better at using a library, like jQuery. Since no standards were settling at the low levels where there was agreement, each higher level of innovation had increasingly deep dependencies.
Imagining high level abstractions remained just as difficult and error prone as ever because they required giant leaps and had to get everything right, or be mostly useless. This was a keystone that many worried could break the positive cycle that set the Web in motion in the first place.
Then, suddenly, browsers began developing again. Library makers got involved with Web standards. In 2010, Remy Sharp introduced the idea of polyfills and more recently browsers began auto-updating. The whole game was dramatically shifting.
Enter the Extensible Web
By 2011, the community at large seemed dissatisfied and a conversation began. By 2013, this conversation led to an agreement on expression of core philosophy agreed to by 21 people called The Extensible Web Manifesto.
It posits that we need to recognize what has changed, plug into its strengths and its community in new ways. It aims to create a virtuous cycle capable of building up complexity and adapting to needs. It suggests that the necessary ingredients for success involve — wait for it…. The ability to experiment and fail fast, the ability for ideas to have sex and gain key improvements, and the ability for ideas to compete amongst developers, developing standards on data and success rather than prescription. Wherever possible, it suggests that we prollyfill standards — that is, to provide a useful implementation that works everywhere before it is a standard and gain that data. As an early (and imperfect) example, see Google’s Polymer library which prollyfills various Web Components specifications, allowing authors to see what worked and what didn’t, and tweak the spec (and adjust the prollyfill) accordingly.
The manifesto is crafted to correct what is historically a hard incentive imbalance: Developers were disincentivized to look at standards until they are already available because of their (often) years-long time frame and inability to experiment. Once delivered, those standards often fell short of actual developer expectations because working groups don’t really understand the needs and desires of real developers. AppCache, for example, is a famous whipping boy, but one could make the argument that it does exactly what it was designed to do (as Ian Hickson explained).
However, if developers are provided with something useful that solves their problems now, with the potential of becoming standardized, they are incentivized not only to try it, but to try to help make it better before it does so.
For the past couple of years, the community and standards bodies have been working hard on projects and efforts to do that: Transpilers helped us provide early access to many ES6 features. Custom Elements have a number of prollyfills that allow people to use custom tags in HTML and help us build up new proposals or look across sites for common vernacular.
Magic
Note that a lot of the Web is high-level, even simple seeming things contain “magic” that browsers all know about but are not specified. Lots and lots of things have to fetch data, stream it and so on — but none of this is currently explained. This creates a kind of “unspoken” architecture that makes it hard to polyfill or even to add new features and limits the number of ways/places that we (or browsers) can plug in.
Therefore, the Extensible Web Manifesto argues that explaining the underlying magic in the platform, minimizing the introduction of new magic and enabling the sort of environment where this sort of evolution can take place should be the immediate priority of standards bodies. The Fetch and Streams standards are examples of specs trying to do just that.
In practical terms, when we have a new proposal, we should first look to unexposed aspects that lie hidden in the existing platform first. When we can’t find anything, we should find what lower-level thing would allow explanation of not only the larger problem, but related problems by defining it and how it fits into the larger picture. Not only should the end-result be better, but developers increase their familiarity through participation and standardization should be easier and faster.
Abracadabra CSS
Things like MutationObservers, Service Workers, Custom Elements, Fetch and Streams provide the raw materials and basic workings that allow an author to plug into reasonably-well explained systems. If you had an idea for a new element, there’s a pretty high chance you could provide something pretty close for people to experiment with in high-level fashion with reasonable forward compatibility safeguards. If you wanted to polyfill an element which was supported in three browsers, you could. That’s incredible. It’s awesome.
But what do you do if you want to propose a new pseudo element for CSS? What if you had an excellent idea for a new layout module? What if you wanted to polyfill something?
Here’s what you’d do historically: Forget it.
CSS contains so much magic that we might have more aptly named it “Hogwarts”. First, you need to be able to parse the stuff because the parser drops unknown rules entirely. Unknown properties or values are dropped too — believe me, it’s non-trivial. Second, you need to make sense of it all: specificity, inheritance, imports and at-rules. You need to understand that all modules have shorthands which expand to long hands. The list goes on just to parse it. In some cases though, you need to serialize modifications back out. And in most cases, of course, you need to actually apply it live, any time someone changes the DOM and as the page is still loading.
The browser itself, of course, knows how to do all of this and has a host of optimizations to make it efficient — but it’s all just magic on the outside. If you need any piece of it, you’ve got to understand and recreate all the underlying magic yourself.
The W3C Technical Architecture Group (or TAG for short) are tasked with kind of making sure that the long term vision of the Web and stuff that the W3C is working on is healthy and on a good track. They’ve taken note of this problem — the disconnect between the Extensible Web ideas that are permeating everything else, and the inability to apply them well to CSS, so they’ve formed a joint TAG/CSS WG task force to work on this problem.
Enter Houdini
This new task force is codenamed “Project Houdini”. Around the turn of the 20th century, Harry Houdini became the world’s most famous magician. There seemed to be no way to contain him. He could escape from anything: Handcuffs, straitjackets, chains, and boxes, even when suspended upside down or underwater. He was also repulsed by the growing practice of people using tricks and illusions and playing on people’s emotions to extort money, so began to investigate and explain their “magic”; he even testified before the US Congress trying to criminalize such practices. So — boxes, sealed, explaining magic — “Houdini” sounded like an excellent name.
The Houdini task force recently held its inaugural, 3-day long meeting in Sydney, Australia (incidentally, Houdini also made the first manned flight over Australia) to discuss what could or should be done. The full minutes are available from the meeting link, but I’ll attempt to sum it up here. First, this captures the sentiment pretty nicely:
Show that we care about extending the browser, and continue to iterate on it. I don’t think we can fix or even think of everything to fix from the beginning, it needs to evolve.
Daniel Glazman, CSS WG co-chair
And, more importantly, this wasn’t a radical statement, it was the norm. At the next TAG meeting, Travis Leithead from Microsoft asked the question “what was the most exciting thing?” to which the response was:
[The most exciting thing was] that nobody was arguing. We’ve wanted a lot of this since the 90s and now is the first time when someone hasn’t said “no” or “it can’t be done”.
Peter Linns (TAG co-chair, CSS WG co-chair)
The task force agreed to begin work on eight new drafts whose aim it is to explain and expose different aspects of CSS. In reality, it’s more like ten as there were already two underway (custom properties and aliases/custom-pseudo classes). We’ve set up a really basic wiki, a public mailing list and a home on github. It’s still very early days, and it will take some time to get rolling as people close out existing work and make ways to prioritize, but it’s a start.
These drafts, which involve everything from the parser to fragmentation and layout, should begin closing the gap between CSS and everything else, making it increasingly plausible to polyfill CSS and innovate/experiment — our ideas can have sex, becoming better/richer than any one of us dreamed.
The specs and what they enable
Parser API
If you can’t parse CSS, you can’t do much — even editors and code highlighters need this functionality and as I explained: it’s really hard to do accurately or and near impossible to do with any kind of comparative performance. Once parsed, you’ve got to actually do something with the information, which means you need a standard way of understanding the parsed stuff. All existing pre-processors and polyfills have to do this and they aren’t fully capable, fully compatible and they don’t agree on the output. A similar problem existed in ECMAScript: transpilers, editors and syntax highlighters for JavaScript are essentially the same problem, and so they created Esprima. This allows us to gain so many of the benefits of the extensible web.
CSS Property and Value Extensions API
Of course, the browser has already parsed things and you don’t necessarily want to do it again if you can avoid it. Furthermore, the browser’s parser also fundamentally has to be a little more capable security-wise. More ideally, in many cases it would be better to plug into the existing system instead with a definition of what should be done. At the very least, it would help define something that the browser shouldn’t throw away as an invalid property or value. This is one of the key features that will allow us to build prollyfills and polyfills. Proposals that satisfy similar use cases as CSS Regions, but which are currently way too hard, suddenly become plausible. This proposal would also expose the ability to do custom @rules.
CSS Aliases and Custom Pseudo-classes
This one didn’t come from Houdini itself, so it already has an editor and a rough draft, but Houdini expands its scope a bit. Its aim is to make it possible for authors to create simple aliases for selectors or even wholly new pseudo-classes.
CSS lacks the ability to create something like a constant that you can refer in a much simpler way later; this creates an explosion of repeated selectors and it’s one of the reasons that people use pre-processors even for very trivial things. An extremely trivial example is something like selecting a button — there are a couple of ways to make a button and you don’t want to the various selectors every time — you just want to define a simple (author-defined) shortcut like :--button and then use it. In the current proposal that might look something like this:
A quick note on the syntax of CSS: CSS has always had forward-compatible parsing rules in which the syntax has been designed with room for extension. Originally this was for vendor prefixes in the format -vendor-*, but they were a really bad idea. Houdini introduces author prefixes, which simply have an empty ("") vendor, and thus are written as --foo.
In addition to aliases, this spec let us define things that are more complex — for example, a pseudo-class for dealing with numeric attributes as numbers instead of strings. Given something like the selector plugin architecture in jQuery this is pretty trivial to do, but these things are really hard to define in CSS. There are selectors and pseudo-classes which have been in proposal status for more than a decade — given something like this, we give authors immediate benefit and gain data about what is useful and streamline the standards process.
Font Metrics API
A lot of times the thing that you need to calculate require context and information which is not currently available to you. Take, for example, drop-caps. Adobe worked hard on creating dropcap.js which is worth a look (including the linked blog post) if you want to understand the complexity and challenges and compromises we currently have to make to do something as “simple” as drop-caps. The Font-Metrics API would work on exposing the necessary information one would need to help fill things that involve font-oriented information.
Custom Layout
CSS has all kinds of crazy layout modes and still, it’s really hard to do some things that it shouldn’t be so hard to do — so, for example, we have alternative proposals like Grid Stylesheets (GSS) which use a constraint-based layout. Figuring out this stuff is hard and it takes an astoundingly inordinate amount of work to get it specified, correct and interoperable. Custom layouts will allow us to register a custom display value and own layout computations making whole classes of new proposals possible to figure out in the community and without impossibly complex barriers.
Custom Paint
At some point you have to paint — that is, actually splat colors onto the screen for CSS to render text and DOM atop. There are any number of challenges which currently involve abusing DOM to get correct visual effects like effects and gradients. Custom paint will allow you to do this.
Input Extensions
Lots of things affect how your app responds or paints, user input like scrolling, for example. Simple things like pull to refresh interfaces involve things like physics and sometimes that makes a really big difference. The Input Extensions spec aims to allow us to plug into that and make it increasingly possible to create really good custom or experimental user experiences that work with this kind of input.
Async Style
This one is still a little bit vague, but essentially the idea is to figure out how we create ways to introduce limited asynchrony and isolation in the DOM. While the description I’m giving is lacking, the ability to identify things that can be pushed into workers or threads is a potentially giant gain for everything from mashups to synchronized effects. Currently almost all work is done on the same main thread — this means that the Web can’t take good advantage of all those cores that your machine (even your cell phone) have which makes effective UIs hard. It will be really interesting to see what comes out of this research.
Conclusion
Of course, this is just a high level view of things and it’s still early days for Houdini — anything is subject to radical re-thinking, but the commitment from so many to dig down and explain the platform in order to make it extensible and adaptable, and to work to build a healthier process around standards is intensely positive.
The Extensible Web isn’t about abandoning declarative HTML and making everything JavaScript; the declarative nature of HTML was what made it so successful in the first place.
It means that rather than spending years on high-level APIs and getting them wrong, high-level ideas can compete — they can have sex and deliver real value along the way. I believe that ultimately, this extensibility and ability to adapt, refine and share sensible high-level features are the cornerstone on which we will allow the Web not just to generally improve, but to remain interesting and competitive for decades — and recapture some of the most important things that made it successful in the first place.
]]>https://dev.opera.com/articles/wifi-ble-javascript/Electronics for the JavaScript Developer using Wi-Fi and Bluetooth LE2015-04-22T00:00:00+00:002015-04-22T00:00:00+00:00Sayanee BasuIntroduction
The Internet of Things is gaining momentum in the recent years as more embedded computing devices are being connected to the Internet. What does this mean for us web developers? This article will explore two common wireless protocols, Wi-Fi and BLE and will take you through the starting steps in connecting sensors and servo motors to the Internet. Then we will learn how to control these devices and access the sensor data using JavaScript!
This article assumes that you are already an intermediate to advanced level JavaScripter. We will primarily use node and npm for server side and simple frontend JavaScript to create some control UI on a web browser. You don’t need any prior knowledge of electronics. Seeing you can effect change and gather data from the physical world can be exciting and I hope through this article you will get that first excitement to dive into the fun world of electronics and web technologies! Let’s get started!
Spark and Wi-Fi
One of the reasons why Spark is a great platform especially for any electronics beginner are its detailed documentation as well as the community forum. In this section, we will play with a light sensor and then control a servo from the web browser. Let’s first list the electronics components you will need so that you can buy them if you want to physically follow through the examples:
Tip: Use the same color wires as the schematic so that it will be faster to trace the wires for debugging. E.g. use Red for power and Black for ground.
Tip: The capacitor used in this example has polarity. On the plastic above one of the pins you’ll see a light colored strip with a negative sign – on it. Always connect that pin to GND pins or rails.
1. Setup
In this section, we will connect the Spark Core to your Spark account and then connect it to the local Wi-Fi. To setup the Spark Core, signup for an account. Then connect the Spark Core to your laptop via the USB cable. You should see a fast-paced blinking blue light which means the Spark Core is waiting for Wi-Fi credentials.
To associate the Spark Core with your account (also known as “claiming the core”), we will use the spark-cli module. Next, we will give the Spark Core our local Wi-Fi credentials so it can connect to the Wi-Fi network.
$ npm install -g spark-cli
$ spark setup # connect the Spark Core to your account
$ spark setup Wi-Fi # connect the Spark Core to your Wi-Fi
If you have setup the Spark Core correctly, you will see a breathing cyan light as shown below.
Next, we will note down two important values (device id and access token) for your Spark Core that will be needed for any secure communication. Open Spark’s web editor, Spark Build for this and note down these 2 values.
In the next couple of sections we will go through two examples. These two examples show two different ways you can use Spark:
Sensing with an LDR (light dependent resistor) with:
express, spark-io and johnny-five npm modules to built a simple button that can turn the servo from the browser
2. Sensing photocell values
Blink the on-board D7 LED.
As the very first step, we will learn how to blink an LED. This is the hello world of electronics. Open the Spark web editor and copy the simple blinking LED code. Here it uses a simple firmware code to blink the on-board LED D7 every 1 second. To flash the firmware code onto your Spark Core, click the flash icon at the top of the left sidebar and wait for the LED on board to come back to the breathing cyan pattern. You should see the LED D7 blinking.
Wire up the breadboard for detecting photocell values.
Here we will need a couple of jumper wires, one photocell and 1kΩ resistor. We will firstly wireup the Red wire to pin Vin and the horizontal lines +. And similarly, the Black wire to pin Gnd and the horizontal line -. Next we will connect the photocell (or LDR) to pin A0 on the Spark Core and the ground, horizontal line -. LDRs do not have any polarity, so we can connect either of the legs to Gnd. Finally, with the 1kΩ resistor, we will connect to pins A0 and Vin on the Spark Core. This circuit might remind you of your high school physics voltage divider circuit.
Flash the firmware code to read the photocell values
While you see the breathing cyan on the Spark Core, take the LDR firmware code and flash it onto the Spark Core with the web ide. The firmware code does a couple of things. Every 200ms, it take the analog reading from pin A0, to which we connected the LDR and then publishes it as a Variable on the Spark Cloud which can then be queried using standard Web APIs. For easy detection and debugging we are also turning on and off the on-board LED D7 to indicate our code is running.
Here’s now the fun part and we will query the sensor values using the simple spark code in a file ldr.js
var spark = require('spark');
spark.login({
username: process.env.EMAIL,
password: process.env.PASSWORD
}).then(
function(token) {
// Your program can successfully connect
// to the published data from the sensor
console.log('Connected to your light sensor successfully!');
// console.log('Access Token: ' + token.access_token);
spark.listDevices().then(
function(devices){
// console.log('\nDevices: ', devices);
var device = devices[0];
// With every published event getLight,
// display the sensor value
device.onEvent('getLight', function(reply) {
var now = new Date();
if (reply && reply.data) {
// Some fun derivations based on the sensor value
if (parseInt(reply.data) < 1000) {
// Shine a torch light on the LDR
// amend 1000 according to your environment
console.log(
now.getSeconds() + ': ' +
reply.data + ' bright!'
);
} else if (parseInt(reply.data) > 2000) {
// Cover the LDR amend 2000
// according to your environment
console.log(
now.getSeconds() + ': ' +
reply.data + ' dark! '
);
} else {
console.log(
now.getSeconds() + ': ' +
reply.data
);
}
}
});
},
function(err) {
console.log('List devices call failed: ', err);
}
);
}, function(err) {
console.log('Ooops error: ' + err);
}
);
Let’s run this code from the command line using your Spark account’s email and password:
You should next see a stream of sensor data. Shine a torch light on the LDR and the value should change and a comment would be displayed. Cover the LDR totally and you will see another comment! So now whatever you do physically in the real world can be sensed with node and JavaScript! Such sensors can be used to sense open/close cupboard doors and light levels in rooms.
This is just the start in playing with the Spark JavaScript API for the server-side. There are many more firmware code libraries available that you can instantly flash to your SparkCore and collect the results via the events api.
3. Control a Servo
Let’s wire up the breadboard with a servo this time!
We will use a servo motor and a capacitor. Wire up the Black / Brown wire to the Gnd pin of the Spark Core, Orange / Red to the Vin of the Spark Core and finally the Yellow wire will be used to wire up to the analog pin A0 of the Spark Core. We will also use a capacitor between the Vin of the Spark Core and Gnd of the Spark Core to stabilize the power to the servo. Capacitor is optional, but it’s good to have it for stability.
The control of the servo is fairly easy. It can rotate 180 degrees. So, when the signal is 0V, it will rotate to 0 degrees and at the other end, when the signal is 5V it will rotate to 180 degrees. To help us do the analog output of these signals, we will use a firmware called VoodooSpark.
VoodooSpark will allow a local TCP connection instead of the usual HTTP protocol that we used in the earlier example. This allows controlling the Spark Core in real-time. Finally, we will use Express to create the routes that will trigger the rotation of the servo through an html page.
Use JavaScript to send signals to the servo via a web browser
$ npm install express johnny-five spark-io
We will need 3 modules. Spark-io to output the TCP packets which VooDooSpark firmware on the Spark Core understands. Johnny-Five package uses Spark-io and provides higher level interfaces to many devices such as sensors, motors, switches, etc. And finally Express to serve a webpage and pass HTTP requests from the browser to the Spark Core.
Store the Spark device id and access token in config file.
Create file ~/.sparkrc to store your config and add the file to your profile with source ~/.sparkrc:
var express = require('express')
var five = require('johnny-five');
var Spark = require('spark-io');
var app = express();
var servo;
// Connect to the Spark Core with the authentication info
var board = new five.Board({
io: new Spark({
token: process.env.SPARK_TOKEN,
deviceId: process.env.SPARK_DEVICE_ID
})
});
// Use analog pin A0
board.on('ready', function() {
servo = new five.Servo({
pin: 'A0'
});
console.log('Servo is ready!');
});
app.use(express.static(__dirname));
// Move to servo to a certain degree
// github.com/rwaldron/johnny-five/blob/master/lib/servo.js#L241-251
app.get('/rotate/:deg', function (req, res) {
if (servo) {
servo.to(parseInt(req.params.deg))
console.log('Rotate ' + req.params.deg + 'deg');
}
})
var server = app.listen(3000, function () {
console.log(
'Control the servo at http://localhost:' + server.address().port
);
})
Finally we will create the super simple html page index.html which will call the routes for the different angles.
Run the code with the node server and click the angles to make the servo move in the physical world!
$ node servo.js
This example is just the tip of the iceberg in how you can control many other devices such as motors and switch with the web interface. I find the Johnny-Five library files very useful to peek into many more things we can hook up and play with!
TI Sensor Tag and BLE
In this section, we will use the Bluetooth Low Energy (BLE) protocol with the TI SensorTag, which is designed for developers to play with various sensors and BLE. The SensorTag comes with a BLE chip on-board along with sensors such as IR temperature sensor, humidity sensor, pressure sensor, accelerometer, etc in a compact handy device. The advantage of using BLE is its low power consumption. The SensorTag can be powered with just a coin cell potentially for years.
To play with the TI SensorTag, you need a couple of things:
The machine on which you will run the JavaScript code should have BLE hardware.
The main npm module that we will be using to interface with the SensorTag is senstortag which is based on an underlying generic node BLE central module, noble. We will attempt to read the IR temperature from the SensorTag and log the gyroscope data while rotating the sensortag. Let’s get started by requiring the modules and connecting to the sensortag.
Create a file sensortag.js, connect, discover and then disconnect the device:
Because the events connect, discovered and disconnected should happen sequentially when the previous event is done, we will use the npm module async to deal with callbacks.
Read the IR Temperature once between the events discovered and disconnected:
Finally, we will add in the gyroscope reading and when the SensorTag is physically rotated, the JavaScript should output the updated values from the gyroscope. We hook onto the gyroscope events after the IR temperature reading. We have to specifically enable the gyroscope readings using the notifyGyroscope API.
That is just a tiny example on how to interface with a BLE device. To dabble more, have a look at all the sensors data you can query in the SensorTag as well as the underlying noble module. The author of both these modules, Sandeep Mistry has open sourced many more BLE related npm packages such as the ones we can interface with iBeacons or Arduino library. Have a go at them!
More resources
The easiest way to start learning to interface web technologies with electronics is to choose a hardware platform which already comes with a JavaScript API. Here are some examples of more such platforms other than the Spark and SensorTag that we covered:
Hardware and electronics interfacing might be daunting at first, but the good news is there are many community events, forums, blog posts and modules/libraries available online. Here are some to check out:
Nodebots — JavaScript based robotics events around the world
Nodecopter — Node and drones community hacking events
I hope this article gave you not only the initial steps for getting started, but plenty of resource to hack on your own or even get involved with the community! It might be challenging at start, but seeing your code literally come to life in the physical world will be immensely rewarding.
Come and hack away with electronics and JavaScript!
]]>https://dev.opera.com/articles/ux-accessibility-aria-label/UX accessibility with aria-label2015-04-09T00:00:00+00:002015-04-09T00:00:00+00:00Heydon PickeringWAI-ARIA, the accessibility extension technology for HTML, has a reputation for being complex — if not entirely impenetrable — in its specification.
How WAI-ARIA’s suite of attributes relate to one another, the underlying HTML and the circumstances under which they are set or mutated is not a trivial affair. And that’s before you try to establish the differing interaction conventions of desktop versus web applications or begin to reconcile the notion of interoperable state with your visual design process.
Basically, it’s a big bum ache. An interesting and ennobling bum ache, but a bum ache nonetheless.
However, while integrated WAI-ARIA widgets, which require an exacting deployment of interrelated HTML attributes and key bindings, can be daunting prospects, not all of WAI-ARIA is organized in such a strict fashion. The aria-label attribute, on account of being a global property, can be called upon anywhere in a page, independently of any other WAI-ARIA features, as and when you need it.
As I shall describe, aria-label is a useful tool to ensure a good user experience for assistive technology users, elevating your design from merely technically compliant to well signposted and usable. There’s also more than one “effect” that aria-label can be used to achieve.
The virtue of text
Here is a rule of thumb:
Whenever you communicate anything on the web not using text, you’re probably doing so inaccessibly
The Web is a conduit for text and web accessibility is about making sure that text is — really and truly — text. Not pictures of text, but text. It’s not quite that simple because there’s focus management to worry about, but that’s pretty much it.
Text nodes are accessible because they are text
Semantic HTML elements are accessible because they prompt the interface to announce descriptive text
WAI-ARIA property and state attributes are a standardized means of supplementing content with qualifying, assistive-technology-announceable… text
The aria-label property falls into the third of these three camps.
Why is text so central to accessibility? Because text is highly interoperable. That is, systems of letters can be translated into code points and interpreted by all sorts of different software. Oh and humans understand text already, of course.
Because different machines can all read and write text, information can be interpreted and conveyed to humans in different ways. Primarily visually (in letter forms) but also aurally (as synthesized speech) and even by touch (refreshable Braille displays, for instance).
Accessible names
HTML elements have roles and names. These are both bits of text. If you were to think of them as people, you could say their role is who they are and their name is what they have to say. Regarding interactive elements like <button>s, names are important because they tell you what the element is for and what it will do. Their role is “button” and their name might be “press me to do x”.
The “button” role piece of text is provided simply by using the <button> element, but the name must be written manually, by the author. The easiest (and best) way to supply a name for an element is to write some text between the opening and closing tags, like so:
<button>Launch missile at my own face</button>
Text nodes are great because you can read them by looking at them or have them read to you. (Mostly) everyone has access to text nodes.
Astonishingly, some web developers seem to spend a lot of their time trying to avoid using text nodes in their interfaces. To them, using text for the purpose of using text is all too obvious. They like to use vectors, rasters or inexplicable pictograms instead.
It is in this circumstance that someone has to add an accessible name separately.
Accessible name calculation
So common is the practice of not using text in a medium principally designed for the conveyance of text that, over the years, we have devised a number of ways to add remedial text after a visual design has been “finished”. This adding of an invisible accessible name usually employs one of the following:
The title attribute
The alt attribute
The aria-label attribute
The aria-labelledby attribute
Some text in a hidden <span> that’s been flung off the side of the screen by an excessive 9 million pixels just in case screen resolutions get so high that this floating bit of text becomes visible to the 8 people who can afford that super-high-resolution model of Apple™ computer.
Some of the attributes are incredibly unreliable (title) and others can only legally — and successfully — be used on certain elements (alt), leaving the two dedicated ARIA attributes aria-label and aria-labelledby.
In the calculation of which bit of (remedial) text should take precedence when more than one is present, aria-label and aria-labelledby also rank most highly, overriding the other methods.
Providing an accessible name with aria-label
If no accessible name is available, screen readers try their best to come up with something based on the element and its attributes. This, inevitably, leads to some utterly perplexing results.
Have you observed the habit of using <a> elements as buttons? Then perhaps you’ve seen a spoof href like # here and there?
It may surprise you that when focusing this “button” the screen reader JAWS announces “number link”. Number? Yes, the screen reader, bereft of an accessible name, desperately blurts out the href value, which it interprets as “number” — as in “the #1 book on web application accessibility”. “Number link”? What on earth does that mean?
The aria-label attribute can be used to easily add a proper name to the element, like so:
<a href="#" class="button" aria-label="Launch missile at my own face"></a>
It’s still the wrong type of element because it’s a link and launching a missile at one’s own face is not a linking action, but at least the name tells you what the interactive element will do. Now screen reader users get the same warning that the button will launch a self destructive missile.
Support for aria-label is also dependable, making our missile warning system still more robust. The ‘aria-label` attribute works across the full gamut of popular browser and screen reader combinations including NVDA, JAWS and VoiceOver paired with Internet Explorer, Firefox, Chrome and others.
Providing better text with aria-label
As I already covered, aria-label is favored in accessible name calculation. Apart from aria-labelledby, it will override all additional naming methods. This means you can use it to provide better text for assistive technologies without altering text intended for visual users.
When would you want to do this? There are a couple of scenarios worth considering.
Interpreting icons
It’s rarely wise to rely entirely on icons in your design lexicon. Even those who can actually see the icons are liable to waste valuable time trying to guess what they are supposed to mean. Nonetheless, there are some conventions that are well understood, like the × symbol used to denote a close button.
The trouble is, “button multiplication”, “button times” and such are not very helpful labels as substitutes for the visual signifier. So we supply an aria-label to override the text node of × without disturbing the actual letterform:
<button aria-label="close">×</button>
Now the “accessibility layer” of the interpreted interface includes the instruction to tell assistive technologies to use the “close” name, prompting them to announce “button close” or something similar.
Improving non-visual context
It has become popular to use the so-called “hamburger icon” to denote a button that opens a site’s main navigation menu. The ≡ character used for this purpose is often a unicode character meaning “identical to” in mathematics. Screen readers like NVDA do not understand the symbol so just ignore it (or unhelpfully read out “symbol 8801” in certain modes). JAWS simply says “equals”.
Myself and others are not convinced that everyone understands even the visual symbol to mean “the main menu of this site” and resolve to add an adjacent “menu” to clarify:
<button>≡ menu</button>
Now, when you focus that button using JAWS it will read “button equals menu” which, depending on how you look at it, is either a lie (the button itself is not the menu) or a tautology (“this menu button is the menu button”).
You could use the global aria-hidden property to clear up confusion by eliminating the “equals” announcement:
Because the span has no semantics — no role to be announced — focusing this button would now read “(button) site navigation menu” as a seamless run of speech.
If the design is successful, the position of the button in the visual layout and the use of the ≡ symbol already imply that this particular menu is the site’s navigation menu. We’ve now made this context explicit in a paradigm where visual clues cannot be relied upon. This is the essence of accessible User Experience Design.
Adding context using containers
In the last two examples, we exploited aria-label’s ability to override text nodes, but there is a way to provide contextual information via aria-label while preserving the text node of the focused element. This is by supplying an aria-label to a parent (container) element.
Multiple navigation landmarks
The navigation landmark (role="navigation" in ARIA speak or <nav> in basic HTML) is most frequently used just once per page, to denote the site’s main navigation. It’s what would hide behind the hamburger icon, if you will.
However, as the spec’ suggests, navigation landmarks can be used “for navigating the document or related documents”.
Why not both? Why indeed. You could have a navigation landmark to navigate between pages and one to navigate around the current page. The trick is in differentiating the two upon entering either landmark. This is where aria-label comes in once again.
Consider these two, complementary navigation landmarks, one for the site and the other for just the about page:
When navigating by keyboard and entering one of these landmarks, you will focus the first of the links provided. But it’s not just the link role and its name that will be announced. The landmark will also be identified, as well as the existence of the list (handy for informing the user that there are multiple links).
In our case, the label will be prepended to the announcement as well, telling the user what sort of navigation landmark they are in. Each of these little bits of information helps to paint a clearer picture of the interface in hand.
So, when the user focuses the first of the links in the “site” navigation landmark, the NVDA screen reader — for example — will announce “site navigation landmark, list of four items, home link.” By the same token, when the “about page” landmark is entered the output is “about page navigation landmark, list of four items, introduction same page link.” (Note how the # in the about page links’ hrefs prompts the NVDA reader to clarify that the link is to a location on that same page.)
Conclusion
In that final example, a number of techniques — ARIA role deployment, accessible naming, semantic HTML and known AT convention — were combined to make the interface clearer and therefore provide a better experience for the user. But, in effect, we were just composing a sentence, piece by piece. The introduction of aria-label to that sentence improves the UX by labelling that part of the interface.
WAI-ARIA is not intended to affect the behavior of HTML interfaces. In ARIA widgets like tab interfaces, it’s the JavaScript that actually changes the state of the widget as you use it. Behavior is a part of UX, of course, but its much the same whether you are using the interface visually, aurally or both at the same time.
A state change is a state change. But it’s with the provision of text, labels, words that the nature and the state of an interface can be made accessible. It’s worth bearing that in mind when you embark on designing more complex ARIA-based patterns. Hopefully, things will fall into place more easily.
]]>https://dev.opera.com/articles/media-features/Interaction Media Features and their potential (for incorrect assumptions)2015-03-23T00:00:00+00:002015-03-23T00:00:00+00:00Patrick H. LaukeThe Media Queries Level 4 Interaction Media Features — pointer, hover and the more recent any-pointer and any-hover — are meant to allow sites to implement different styles and functionality (either CSS-specific interactivity like :hover, or even JavaScript behaviours, when queried using window.matchMedia), depending on the particular characteristics of a user’s input modalities.
Note: the Media Queries Level 4 Interaction Media Features are still at the Working Draft stage, so some of the wording/functionality – as well as the way in which it is implemented in browsers – may still change before they become stable recommendations. This article is based on the specification’s Editor’s Draft, 24 March 2015.
Common use cases cited for interaction media features are often “make controls bigger/smaller depending on whether the users has a touchscreen device or is using a mouse/stylus” and “only use a CSS dropdown menu if the user has an input that allows :hover-based interactions”.
Some classic use cases for pointer or hover
@media (pointer:fine) {
/* ok to use small buttons/controls */
}
@media (hover:hover) {
/* ok to use :hover-based menus */
}
@media (pointer:coarse) {
/* make buttons and other “touch targets” bigger */
}
@media (hover:none), (hover:on-demand) {
/* suppress :hover-based menus */
}
What’s the primary input?
One of the problems with pointer and hover is that, by design, they only expose the characteristics of what a browser deems to be the primary input device – and current browser implementations may, in some cases, not be as smart as they should in making this assessment, since what constitutes a primary input may not always be obvious.
Traditionally, we could say that a phone/tablet’s primary input is the touchscreen. But on desktop/laptop devices, any hard distinction already becomes blurry: these devices usually have both a keyboard and mouse/trackpad. What is the primary input in this case? Currently, browsers make the assumption that in these situations, it’s the mouse/trackpad. But what if I’m actually a user who navigates only using the keyboard (which, depending on how things are coded, can be considered a pointer:fine — for focusable elements like links and buttons — or pointer:none device — in the case of custom interfaces, reliant on JavaScript events with coordinates, such as a <canvas> — lacking :hover)? This particular case is (sort of) acknowledged in the spec:
For accessibility reasons, even on devices whose pointing device can be described as fine, the UA may give a value of coarse or none to this media query, to indicate that the user has difficulties manipulating the input device accurately or at all.
At the time of writing, there are no options in browsers/UAs that let a user explicitly say “I’m a keyboard user” (let’s not even mention the “I’m a user with reduced mobility” scenario, where a user may in fact be using a mouse/trackpad — or even an alternative input method such as a head wand, or a virtual mouse, which translates back to actual mouse inputs — but with great difficulty and reduced accuracy).
Beyond the accessibility angle, there are further issues with the concept of primary inputs. What about devices like a Microsoft Surface, with a touchscreen, stylus and (with addition of a type cover) a trackpad and keyboard? Arguably, these devices blur the definition of primary input completely (though there is potential here for browsers to implement heuristics — consider Windows 10’s ability to switch to “Tablet mode”, which browsers could take as indication to treat any available touchscreen as primary).
Note: For a similar take on this problem, see Stu Cox: The Good & Bad of Level 4 Media Queries, although his post refers to an earlier iteration of the spec, which only contained pointer and hover and a requirement for these features to report the least capable, rather than the primary, input device.
So, right out of the gate, the fact that pointer and hover only relate to what the browser believes to be the primary input may lead to wrong results on devices with potentially two or more different primary inputs.
Fundamentally then, the problem with the original pointer and hover is that they don’t always adequately cover multi-input scenarios, and rely on the browser to be able to be able to correctly pick a single primary input. A user may for instance have paired a bluetooth mouse to their phone/tablet — suddenly, instead of a pointing device with pointer:coarse and hover:none, they have an additional pointer:fine, hover:hover capable one. But in all current implementations, browsers will still regard the touchscreen as the primary input. If a web developer relies purely on pointer and hover to add specific styling or functionality, no extra media queries based on these capabilities would kick in.
feature
touchscreen
touchscreen + mouse
desktop/laptop
desktop/laptop + touchscreen
pointer:none
false
false
false
false
pointer:coarse
true
true
false
false
pointer:fine
false
false
true
true
hover:none
false
false
false
false
hover:on-demand
true
true
false
false
hover:hover
false
false
true
true
Note: from my (admittedly limited to Android/Blink) testing, it seems that on touchscreen devices, hover:on-demand, rather than hover:none, returns true — probably a conscious decision on the part of Blink, related to the fact that :hover (and even compatibility mouse events like mouseover) can be triggered by a touchscreen “tap”.
That’s where any-pointer and any-hover are supposed to come into play.
Testing the capabilities of all inputs
Instead of focusing purely on the primary input, any-pointer and any-hover report the capabilities of all available inputs. Going back to the original use cases for the interaction media features, instead of basing our decision to provide larger/smaller inputs or to enable/disable :hover-based functionality only on the characteristics of the primary input, we can make that decision based on the characteristics of any available inputs. Roughly translated, instead of saying “only offer a CSS menu if the primary input has hover:hover”, we can build media queries that equate to “only offer a :hover based menu if at least one of the inputs available to the user has hover:hover capability”.
Per the specification, user agents should re-evaluate media queries in response to changes in the user environment. Once properly implemented, the any-pointer and any-hover interaction media features will change dynamically when inputs are added/removed — so a site/app could immediately react to, say, a mouse being paired with a touchscreen device.
In order to support multi-input scenarios, where different inputs may have different characteristics, in the case of any-pointer and any-hover
more than one of their values can match, if different input devices have different characteristics
(compared to pointer and hover, which only ever refer to the capabilities of the primary input). In current implementations, these media features evaluate as follows:
feature
touchscreen
touchscreen + mouse
desktop/laptop
desktop/laptop + touchscreen
any-pointer:none
false
false
false
false
any-pointer:coarse
true
true
false
true
any-pointer:fine
false
true
true
true
any-hover:none
false
false
false
false
any-hover:on-demand
true
true
false
true
any-hover:hover
false
true
true
true
Interaction Media Features in Opera on an Android phone with paired bluetooth mouse
Certainly, it’s valuable for a developer to be able to know the characteristics of any input device that the user has at their disposal. However, as with similar feature detection methods, developers need to be aware of what exactly they’re detecting (in a similar way to the problem I outlined in my article on Detecting touch: it’s the “why”, not the “how”) and to understand the fundamental limitations of the current approach: that in many cases, it doesn’t matter so much what inputs (and their specific characteristics) are potentially available to a user — what matters, in my opinion at least, is what input the user is using right now.
Take the example of a phone/tablet with a paired mouse: any-hover:hover will be true, as there is a hover-capable input present — but does that mean that we can now rely on hover-based functionality? What if the user, regardless of the mouse, is still using the touchscreen?
Assumptions based on any-pointer or any-hover
@media (any-pointer:fine) and (any-hover:hover) {
/* at least one device is mouse-like…
we can use small buttons and :hover-based menus, right?
what if they’re using a touchscreen… */
}
Targeting the least capable input
Since we cannot know for sure which input is currently being used, I would suggest that any-pointer and any-hover are most valuable for checking the lowest common denominator, the least “capable” input. In the example of the phone/tablet with a paired mouse, we’d still only be able to use the information provided by any-pointer and any-hover to determine that yes, even though there are different inputs available, one of them is still coarse and does not support hover.
Use any-pointer or any-hover for lowest common denominator
@media (any-pointer:coarse) {
/* at least one input is “coarse”
make buttons and other “touch targets” bigger */
}
@media (any-hover:none), (any-hover:on-demand) {
/* at least one input has no or (usually clunky)
“on-demand” hover suppress :hover-based menus */
}
Instead of testing for the presence of a particular capability, we could of course test for the absence of less capable inputs, and suppress styles that would otherwise be needed if those limited input types were present. However, the limited way in which the logical not works in Media Queries Level 3 (which don’t support chaining multiple tests together with a comma — the logical or — and negating the whole resulting expression) makes this unnecessarily cumbersome, since we can effectively only test for the absence of one of the values at a time:
Explicitly test for absence of “less capable” inputs
@media not all and (any-pointer:coarse) {
/* no inputs are “coarse”
they may be “fine” or “none” */
}
@media not all and (any-hover:on-demand) {
/* no input with “on-demand” hover is present
they either have “hover” or “none” */
}
@media not all and (any-hover:none) {
/* no input without hover is present
they either have “hover” or “on-demand” */
}
Note: normally, the all and part would be superfluous, but it seems that in many current browser implementations, not only works correctly with an explicit media type as part of the query.
We could try to work around the limitations of not by using nested @media blocks, but this further increases complexity and has the potential for cross-browser incompatibilities at this point:
Nested @media queries
@media not all and (any-hover:none) {
@media not all and (any-hover:on-demand) {
/* neither “none” nor “on-demand” hover inputs are present
meaning all inputs have `hover:hover`
safe to use hover-based features?
still does not identify keyboard users at the moment */
}
}
Lastly, we could wait for the “full boolean algebra” approach of Media Queries Level 4 media conditions — but this is not currently supported in any browser:
MQ Level 4 full boolean algebra media condition
@media not ((any-pointer:none) or (any-pointer:on-demand)) {
/* as above, but far more readable
sadly, not supported in any browser yet */
}
Regardless of which specific approach we opt for, in the end, we can use any-pointer and any-hover to find our baseline for the least capable input, rather than trying to determine the most capable one.
Query responsibly
For me, the take-away from all this is: pointer and hover tell you about the capabilities of whatever the browser/UA determines to be the primary device. In current implementations this information is mostly useless, as there may be additional input methods, and the browser may have made assumptions which are not correct. any-pointer and any-hover tell you about the capabilities of all connected inputs, and with some degree of media query acrobatics we can even narrow down the overall range of potential capabilities available. But none of these tell you specifically about the capabilities of the input device your user is using right now — and of course, you can only know what specific input a user will be using once they already started an interaction, at which point it’s likely too late to switch around style or functionality.
By all means, you can start using Media Queries Level 4 Interaction Media Features to make your site respond to different input device capabilities — but beware false assumptions about what these media features actually tell you, particularly in current browser implementations. Or keep it simple: design for all types of input and/or offer the user an explicit way to switch to their preferred mode.
(With thanks to Stu Cox and Florian Rivoal for their invaluable feedback on the early stages of this article)
]]>https://dev.opera.com/articles/state-of-web-type/The State of Web Type2015-03-03T00:00:00+00:002015-03-03T00:00:00+00:00Bram SteinTypography has a long and rich history, but much has been lost in the transition to the web. While browser support for typography has advanced a lot in the last couple years, we still have a long way to go. Features print designers take for granted are either nonexistent on the web or have insufficient browser support in order to be useful. Challenges unique to web browsers such as responsive design and web font loading could use some improvement as well. Let’s take a look at some of the features we need for an optimal and beautiful reading experience.
OpenType Features
Typeface designers often put extra features in a font that can be used to customise text rendering. These are called OpenType features and include character spacing, alignment, ligatures, alternative characters, and so on. There are in fact more than 140 registered OpenType features. Many of these features are optional, but some are actually required to properly render text (e.g. kerning and required ligatures). OpenType features are reasonably well supported by modern web browsers, but still come with a lot of caveats that make them hard to use.
From left to right: contextual alternates set in Caflisch Script Pro, ligatures set in Warnock Pro, and small caps set in Chaparral Pro.
An important caveat is that not all fonts include all 140+ OpenType features. Most fonts only contain a small subset of features, such as kerning and ligatures. Others may include discretionary features, such as swashes and alternate characters. With the proliferation of web font and subsetting services we can’t always rely on information about OpenType features and character support provided by typeface designers. We need better tools to look inside our font files to see which features and characters are supported and which are not.
If a font includes the features you wish to use, you still need to check if your target browsers support OpenType features. While most modern browsers support either the low-level font-feature-settings syntax or the high level font-variant-* syntax, there are still several browsers in common use that don’t support either syntax. Notable examples are Internet Explorer versions 6 to 9 and all versions of Android WebKit until 4.4. Fortunately, the fallback behaviour for most OpenType features is graceful: text is still readable without them.
Unfortunately, even if a browser supports the OpenType feature syntax it is not always guaranteed that it will support all individual features. A good (or rather bad) example is Safari which technically supports the font-feature-settings syntax, but ignores any value. Instead it explicitly enables a select number of features which you have no way of turning off.
Justification & Hyphenation
Many web developers think of justification as a solved problem (or worse, one to avoid). Set text-align to justify and you’re done, right? Not quite. The algorithm used in all web browsers is actually a very ineffective justification implementation. Tools like TeX and InDesign use a more sophisticated line breaking algorithm that optimises break points over an entire paragraph, whereas browsers only look at a single line. This leads to suboptimal justification and large spaces between words.
Left: a justified paragraph, middle: extraneous word spaces are highlighted, right: word spacing and justification is improved by enabling hyphenation.
Browsers could implement the same line breaking algorithm as used in TeX, but have decided not to for performance reasons. This is an odd reason — TeX was developed and runs on computers much less powerful than those commonly used in mobile phones. Another way to improve poor line breaking is by hyphenating words. This introduces more potential line break points and reduces the chance of awkward line breaks. A common misunderstanding is that hyphenation is only useful for justified text. This is not true. Hyphenation is also a useful tool to control the raggedness of center, left, and right aligned text. The CSS hyphens property can be used to control hyphenation. Setting it to auto will enable hyphenation (provided the document or element specifies a language using the lang attribute), while setting it to none disables hyphenation.
IE8
IE9
IE10
IE11
Chrome
Firefox
Safari
Opera
No
No
Yes
Yes
No
Yes
Yes
No
The hyphens property is supported by almost all modern browsers except those based on the Blink rendering engine. Chrome and Opera previously supported the hyphens syntax but neither browser shipped with hyphenation dictionaries. In a surprising move they recently dropped support for the hyphens syntax completely. The Blink developers decided to remove the hyphens property because it was never fully implemented and broke feature detection. While such regressions are not common, they are worrisome. A feature required for correct text layout should be supported everywhere. So, for now, you’ll need to rely on either server-side hyphenation or one of the two client-side hyphenation libraries: Hypher and Hyphenator.
Font Loading
Web font usage has increased significantly in the past couple years. This is great news. However, it also means that web fonts have become a critical part of web sites and, by extension, a performance bottleneck. You may have experienced the dreaded Flash Of Invisible Text (FOIT) while visiting a website on a slow network connection. The decision by some browsers to block rendering of text until web fonts have downloaded is opposite to the tenets of progressive enhancement. Content should come first and web fonts are an enhancement. After all, you can still read the text, even though it might not render in the intended font (well, unless your browser hides text while it is downloading fonts — better pray it uses a timeout).
Not all browsers hide text while downloading web fonts. For example Internet Explorer always renders text in a fallback font while it is downloading fonts. This has been dubbed the Flash Of Unstyled Text (FOUT). This is a misnomer. The FOUT is a feature and a condition everyone should anticipate and design for. Selecting and testing fallback fonts is an important task while designing and building a site.
IE9
IE10
IE11
Chrome
Firefox
Safari
Opera
font rendering
FOUT
FOUT
FOUT
FOIT
FOIT
FOIT
FOIT
timeout
n/a
n/a
n/a
3 sec.
3 sec.
∞
3 sec.
The above table shows the usage of the FOUT and FOIT across browsers. Note that Safari (and older Android WebKit versions) do not have a timeout. On these browsers, text won’t render until fonts have completely loaded.
Browser vendors are working on a proposal for a new CSS property to control font loading and rendering. It is meant to give developers more control over the blocking and swapping behaviour of web fonts. The proposed font-rendering property accepts three parameters:
block: block rendering of the text while fonts are downloading with an optional timeout;
swap: use a fallback font and render the font when it becomes available with an optional timeout;
optional: use the font if it is cached and otherwise use the fallback font. Do not re-render the page, even if the web font becomes available at a later time.
These parameters can also be used to develop custom font loading schemes. For example, for an important and fast loading font we can block text rendering for 1s. If the font doesn’t load within that time we can allow up to 10 seconds where it is acceptable to re-render the page.
font-rendering: block 1s swap 10s;
Browsers should standardize the default font loading behaviour once the font-rendering property is implemented. Ideally the default value should be block 0s swap infinite as used by Internet Explorer (i.e. the Flash of Unstyled Text). Blocking text rendering while loading fonts should be opt-in and not a default. Browser should treat web fonts as progressive enhancement by default and make content available as soon as possible. Opting out of that behaviour is the responsibility of a web developer and not the browser.
Until the font-rendering property is implemented we can use the CSS Font Loading API to implement the same behaviour in JavaScript. The Font Loading API is supported by Chrome, Opera, and soon Firefox. There is also a Font Loading API polyfill for browsers that do not support it natively.
Looking to the Future
This is just the tip of the iceberg. To compete with and surpass the typographic quality of print publications we need support for drop caps, colour fonts, advanced layout (akin to shapes, exclusions and regions), sizing text to fit a container, widows and orphans, balanced text, math typesetting (though MathML is now an officially recommended standard, Chromium and Internet Explorer have no plans to support it), and so on. Clearly, we need to do better and push browser vendors for these features if we want to improve the web’s reading experience. You can help out by participating in the W3C mailing lists, building demos, implementing polyfills and drafting specifications for features you want to see. Don’t worry about getting it right the first time. Sometimes the best thing to come out of a specification is a new and better specification.
Another way to contribute is to draw attention to partially implemented specifications and bugs by keeping track of what works and what doesn’t. That’s why I recently launched a new project called the State of Web Type. Its goal is to contain up to date browser support data for all type and typography features on the web. The project is open source and contributions and corrections are more than welcome. Let’s work together to make the web a better platform for publishing and reading!
]]>https://dev.opera.com/articles/web-notifications-pubnub/Working with Web Notifications using PubNub’s Realtime Data Stream2015-02-24T00:00:00+00:002015-02-24T00:00:00+00:00Tomomi ImuraNotifications are a great way for apps to indicate that they have something to tell you, for example, that you’ve received a new Twitter message.
The W3C Web Notifications API allows your web browser to display notifications as well: it is a great way to engage with your users because these notifications can be displayed even when the page is not active — note however that the page must be opened in a background tab for the notification to be triggered. The W3C doesn’t specify how notifications should look, so Opera has chosen to use native notifications so that your browser feels completely integrated with your operating system.
Today, I am going to show you how to use Web Notifications by creating an interactive multi-user app using PubNub’s realtime data stream JavaScript APIs.
What is the PubNub Data Stream Network?
PubNub is a secure global Data Stream Network that enables developers to build, scale, and manage realtime functionality for their applications and IoT devices. It uses a publish/subscribe model, and its APIs are straightforward to use. (Full disclosure: I work for PubNub)
Common publish/subscribe messaging paradigms
What we’ll be building
For this article, I made an alternative version of the “Yo” app, which allows you to send the message “Yo” to your friends. With the “Oi” web app, instead of sending a message to your friends, you can send “Oi” to strangers online.
Let’s get started!
Checking for API support
The first step is checking if the Web Notifications API is supported by the user’s browser. This feature detection step is good practice and currently needed since not all browsers support the API yet.
For this exercise, let’s just simply terminate the app when the browser doesn’t support the API, since this app is useless without notification capability. When you’re building a real web app, you should of course try to provide a nice fallback for an optimal user experience.
if (!window.Notification) {
alert('Oops, your browser does not support the Web Notifications API!');
} else {
// Go ahead and use the Web Notification API.
}
Requesting permission
Each browser provides a built-in permission UI for the Web Notification API, so that you can control which web pages can send you notifications. When your page is loaded for the first time, a browser-specific permission dialog is shown to the user. After the user has granted permission, your page can send notifications, otherwise (denied), it can’t.
Notification.requestPermission(function() {
if (Notification.permission === 'granted') {
// Now your page can send the user notifications!
}
});
Try for yourself and see. You can always reset the permission setting by going to opera://settings, selecting Websites from the left column, and scrolling down to the Notifications section.
Connecting users using PubNub Data Stream
Once the user has granted permission, the next interaction you expect is that they enter a name in order to get started.
<input type="text" placeholder="Type your name to start" autofocus>
When the user enters a name, then hits the return key (we’re listening for a keyup event with a keyCode === 13), we send the username to the PubNub stream to register the user.
document.querySelector('[type="text"]').addEventListener('keyup', function(event) {
if (event.keyCode !== 13) return;
if (!input.value) return;
username = input.value;
// Connect PubNub and register the user …
});
Now, let’s initialize the PubNub client API environment, with the user’s username as a uuid (unique identifier). Also, we create a channel called “oi”.
var channel = 'oi';
var pubnub = PUBNUB.init({
subscribe_key: 'your_sub_key',
publish_key: 'your_pub_key',
uuid: username
});
Populate a list of users using presence detection APIs
You can subscribe the channel for the client to the PubNub network to create an open TCP socket and begin listening for messages.
PubNub also provides “presence detection”, which allows you to check up on your users’ presence status, for instance, when they come online and when they leave. This feature is useful to populate an up-to-date list of every user currently subscribed to a channel.
In this demo, we update the DOM with the current list of users you can send “Oi” messages to, using PubNub’s here_now APIs. The following function is called each time each time a user joins or leaves. (The subscribe API is explained later).
var updateList = function() {
pubnub.here_now({
channel: channel,
callback: function(m) {
// get current users and update DOM
}
});
};
To make this article simple and focus more on the essential parts, I’m skipping the details of presence detection, but you can always take a look at the source code to see how it is done!
Sending messages
When the user clicks a username in the list, the app will publish a message. The publish() function is used to send a message to all subscribers of a channel. You can simply pass an object as a message payload. In this demo, only from and to info is passed but you can send any messages in the object.
var list = document.querySelector('.list');
list.addEventListener('click', function(event) {
if (!event.target.id) return;
pubnub.publish({
channel: channel,
message: {
from: username,
to: event.target.id
}
});
});
You can pass an object with any data you want as the message. So instead of the default “Oi!” message, you can also modify the script and allow your users to send custom messages.
Receiving messages
When somebody sends the user a message, the web app will trigger the browser to display a notification.
To make to this demo very simple, rather than establishing a 1-to-1 private connection, we let our web app broadcast messages to all users simultaneously. However, only a designated person will receive a web notification.
To retrieve the live messages, you simply use PubNub subscribe() API. If the message is sent to a particular user, that user will see a notification.
Creating a web notification is super-simple: just call the Notification constructor.
var notification = new Notification(title, options);
The title must be a string, and options may contain an object with the properties:
dir (direction, can be either auto, ltr, or rtl. Used with bidirectional text)
lang (language)
body (extra text)
tag (used to coordinate multiple instances)
icon (the URL of an icon image)
Let’s complete the showNotification function. This displays a notification, and closes it after 30 seconds. If you would like to leave it until the user dismisses the popup, just omit the last part.
The tag member is used by each instance to coordinate how many notifications to show. For example, even if you have the app opened in multiple tabs with the same username, you only receive one notification popup when they share the same tag.
function showNotification(data) {
var notification = new Notification('Oi!', {
body: 'From: ' + data.from,
tag: channel,
icon: 'images/oi.png'
});
notification.onshow = function() {
setTimeout(notification.close, 30000);
};
}
Ta-da! Now you can annoy random strangers online by sending them an “Oi!” message. The entire source code is available on GitHub.
This demo is very basic, and quite frankly, a bit silly, but web notifications can be really interactive and useful when you use them wisely!
]]>https://dev.opera.com/articles/appearin-workshop/Appear.in workshop and extensions2015-01-28T00:00:00+00:002015-01-28T00:00:00+00:00Andreas BovensBackground
In early December 2014, we invited the team behind the fantastic WebRTC-powered appear.in video chat service for a 1-day workshop in Opera’s Oslo office: for about 6 hours, we sat together with engineers, designers and product people from both companies — mostly powered by good coffee and tasty pepperkake — and came up with a number of experiments using appear.in.
The Appear.in and Opera workshop in December
A number of these experiments focused on various backend improvements, but we also looked at a number of interesting frontend tweaks: most of these were implemented as extensions as this allowed us to quickly prototype functionality on top of the existing appear.in service, without making major changes to the underlying code.
We’ve polished these extensions a bit more and have published them to the Opera extensions catalog. Here’s an overview.
This is a simple extension to quickly create an appear.in room. Simply click the appear.in icon, and then “Go to room”. The extension remembers your three most recent rooms, and allows you to edit the suggested room name to something of your liking. Super simple, but we found it comes in handy for starting an appear.in call within seconds.
This extension adds a small appear.in icon in Facebook chat and Twitter DM, which you can use to quickly generate an appear.in link for your contacts to use. Instant video chat gratification!
The Appear.in Social extension integrated in Facebook chat
This extension allows you to easily transfer an ongoing appear.in video chat from your desktop browser to your Android phone. Check out the video below for a demonstration of the desktop-to-mobile flow.
]]>https://dev.opera.com/articles/perfect-javascript-framework/In search of the perfect JavaScript framework2014-10-28T00:00:00+00:002014-10-28T00:00:00+00:00Krasimir TsonevNowadays, in front-end development, we have many frameworks and libraries. Some of them are good, some of them are not. Often we only like a particular concept, module or maybe a certain syntax. The truth is that there is no universal instrument. This article is about the future framework — the framework that does not exist yet. I’ve summarized the pros and cons of some of the available JavaScript frameworks and I dare to dream about the perfect solution.
Abstraction is dangerous
We all like simple tools. Complexity kills. It makes our work difficult and gives us much steeper learning curve. Programmers need to know how things work. Otherwise, they feel insecure. If we work with a complex system, then we have a big gap between “I am using it” and “I know how it works”. For example, code like this hides complexity:
var page = Framework.createPage({
'type': 'home',
'visible': true
});
Let’s say that this is a real framework. Behind the scenes, createPage generates a new view class that loads the home.html template. Based on the visible parameter we append (or not) the newly created DOM element to the tree. Now, let’s put ourselves in the developer’s shoes. We read in the documentation that this creates a new page with a certain template. We do not know any particular details because this is an abstraction.
Some of today’s frameworks have not one, but many levels of abstractions. Sometimes, in order to use the framework properly, we have to know the details. Abstracting, in fact, is a powerful instrument because it wraps functionalities. It encapsulates design decisions. However, it should be used wisely because it leads to untraceable processes.
What if we transform the above example to the following:
var page = Framework.createPage();
page
.loadTemplate('home.html')
.appendToDOM();
Now the developer knows what is going on. The template and the appending are exposed to different API methods. So, he/she can do something in between and control the processes.
Let’s take Ember.js. It is a great framework. It gives us the power of building single page applications with just a few lines of code. However, this comes at its own price. It defines several classes behind the scenes. For example:
The framework creates three routes, and each one of them has a controller attached. You may or may not use these classes, but they exist. The framework needs them to power up the application.
Very often, our project requires custom functionality. There is no framework that covers all use cases. So, we meet problems that do not have simple solutions. We have to understand how everything works in order to find the right way of doing things. Every other direction that we take looks more like hacking the framework and not playing with it.
Backbone.js, for example, introduces just a few predefined objects. They contain the core functionality, but the real implementation is up to the programmer. The DocumentView class below extends Backbone.View. That’s it. We have only one level between the code that we use and the framework’s core features.
Personally, I prefer to use a framework that doesn’t have many levels of abstractions — a framework that provides transparency.
The missing constructor
Some of the frameworks accept our class definitions, but they do not produce constructors. The framework decides where and when to create an instance. I would like to see more frameworks that let us do exactly this. For example, in Knockout:
We, again, define our class, but we are not running it. We just say that this is our controller, and the framework decides how to process it. We may find this confusing because we lose the key points — the key points that we use to visualize the application’s flow.
DOM manipulations
Whatever we do, we need to interact with the DOM. It is important how we do it, because typically, every manipulation of the nodes on the page fires a reflow or a repaint, which can be expensive operations. Let’s, for example, consider the usage of the following JavaScript class:
var Framework = {
'el': null,
'setElement': function(el) {
this.el = el;
return this;
},
'update': function(list) {
var str = '<ul>';
for (var i = 0; i < list.length; i++) {
var li = document.createElement('li');
li.textContent = list[i];
str += li.outerHTML;
}
str += '</ul>';
this.el.innerHTML = str;
return this;
}
}
This little framework generates an unordered list with given data. We send the DOM element, which will host a list, and call the update function that shows the data to the screen.
In order to illustrate why this is bad design, we will add a link to the page and will attach a click event listener. The function will call the update method again but with different items.
We’re sending almost the same data; we only change the first element of the array. However, because we are using innerHTML, a repaint is triggered after each click. The browser does not know that we need to modify only the first row. It repaints the whole list. Let’s use Opera’s DevTools and run the profile. Check out the following animated GIF demonstrating the result:
Notice that after each click the whole content is repainted. This is a problem, especially if we use the same technique heavily on the page.
It is much better if we remember the created <li> nodes and only update their content. That way, we are not modifying the whole list but only its children. The first change that we have to make is in setElement:
Like this, we do not need a reference to the host element anymore. We just need to create a new <ul> element and append it once.
The logic that improves the performance is in the body of the update method:
'update': function(list) {
for (var i = 0; i < list.length; i++) {
if (!this.rows[i]) {
var row = document.createElement('LI');
row.textContent = list[i];
this.rows[i] = row;
this.list.appendChild(row);
} else if (this.rows[i].textContent !== list[i]) {
this.rows[i].textContent = list[i];
}
}
if (list.length < this.rows.length) {
for (var i = list.length; i < this.rows.length; i++) {
if (this.rows[i] !== false) {
this.list.removeChild(this.rows[i]);
this.rows[i] = false;
}
}
}
return this;
}
The first for loop goes through the data that is passed in and creates <li> elements if necessary. this.rows keeps the created tags. If there is a node at a certain index, the framework updates its textContent property when applicable. The loop at the end removes nodes if the passed array has fewer elements than the current one.
Here is the result:
The browser repaints only the part that is changed.
The good news is that frameworks like React are already handling the DOM manipulations correctly. The browsers become smarter and they also apply tricks to decrease the repaints. However, it is always good to have this in mind and check what our framework of choice provides.
I hope that in the near future we will be able to stop thinking about such problems: frameworks should automatically cover them for us.
DOM events handling
JavaScript based applications usually communicate with the users through DOM events. The elements on the page dispatch messages and our code processes them. Here is a piece of Backbone.js code that performs an action when the user interacts with the page:
So, there should be an element matching the .header.menu selector and once the user clicks on it we have to toggle the menu. The problem with this design is that we bind the JavaScript object to one particular DOM item. If we tweak the HTML and change .menu. to .main-menu we have to modify the JavaScript too. I believe that our controllers should be independent, and we should decouple them from the DOM.
By defining functions, we delegate tasks to our JavaScript classes. If these tasks are handlers of DOM events, then it makes sense to construct them in the HTML.
I like how AngularJS handles events:
<a href="#" ng-click="go()">click me</a>
go is a function registered in our controller. Following this approach, we do not have to think about DOM selectors. We just apply behavior directly to the HTML nodes. It is a powerful approach because we skip the boring interaction with the DOM.
In general, I would like to see such kind of logic inside HTML. Interestingly, we spent ages convincing developers to split the content (HTML) and the behavior (JavaScript); we taught them to avoid inline styling and scripting. However, now I see that doing this actually can save us much time and makes our components flexible. Of course, I don’t mean code like this:
It should not be like JavaScript coding in HTML, but more like setting configurations.
Dependency management
Managing the dependencies is an important job in our development process. We usually depend on external functions, modules or libraries. In fact, we are producing dependencies all the time. We don’t write everything into one method. We split the application’s tasks into functions and wire them. In the ideal case, we want to encapsulate logic into modules that behave like black boxes. They know details only about their job and nothing else.
RequireJS is one of the popular instruments for resolving dependencies. The idea is to wrap your code in a closure that accepts the needed modules:
In the example above, our function needs two modules — ajax and router. The magical require method reads the passed array and calls our function with the proper arguments. The definition of the router looks like this:
Notice that we have another dependency here — jQuery. It’s also important to mention that we have to return our module’s public API. Otherwise, the code which requires our module can’t access the defined functionalities.
AngularJS goes a little bit further by giving us something called factory. We register our dependencies there, and they are magically available in our controllers. For example:
In general, this approach simplifies our job. We don’t have to use a function like require to fetch the dependency. All we have to do is to type the right words in the arguments’ list.
Ok, these two ways of dependency injection work, but they are bound to a specific style of code writing. In the future, I would like to see frameworks that eliminate this constraint. It will be much elegant if we are able to apply metadata during the variables’ definition. The language right now doesn’t offer such capabilities. It will be nice if the following is possible:
var router:<inject:Router>;
Placing the dependency along with the variable’s definition means that we will perform the injection only if needed. RequireJS and AngularJS for example work on a functional level. So, you may use a module only in specific cases, but the initialization and its injection happen every time. There is also a specific place where we have to define our dependencies. We are bound to that.
Templates
We use template engines a lot. And we do so because we need to distinguish the data from the HTML markup. How do today’s frameworks handle templates? Here are the most popular approaches:
This is used often because the template is placed in the HTML. It looks natural, and it makes sense because HTML naturally contains tags. The browser doesn’t render the contents of <script> elements so it doesn’t mess up the page’s layout.
The template is loaded using Ajax
Backbone.View.extend({
'template': 'my-view-template',
'render': function() {
$.get('/templates/' + this.template + '.html', function(template) {
var html = $(template).tmpl();
});
}
});
We place our code into external HTML files and avoid the usage of additional <script> tags. However, this means that we need more HTTP requests which is not always appropriate (at least not until HTTP2 becomes more widespread).
The template is part of the page’s markup — the framework reads the template from the DOM tree. It relies on already generated HTML. We don’t have to perform additional HTTP requests, create a new file or add additional <script> elements.
The template is part of the JavaScript
var HelloMessage = React.createClass({
render: function() {
// Note: the following line is invalid JavaScript.
return <div>Hello {this.props.name}</div>;
}
});
This approach introduced by React uses its own parser that converts the invalid part of the JavaScript to valid code.
The template is not HTML
Some frameworks don’t use HTML directly at all. They use templates in the form of JSON or YAML.
Final thoughts about templates
Ok, where do we go from here? The framework of the future should make us think only about the data and only about the markup. Nothing in between. We don’t want to deal with loading HTML strings or passing data to special functions. We want to apply values to variables and get the DOM updated. The popular two-way data binding should not be a feature, but a must-have core functionality.
In fact, AngularJS is close to the desired behavior. It reads the template from the provided page’s content and has the magical data binding implemented. However, it is still not ideal. Sometimes there is a flickering effect. It happens when the browser renders the HTML but AngularJS’s boot mechanisms are still not fired. Also, AngularJS uses dirty checking to find out what is changed. This approach could cost a lot in some cases. Hopefully Object.observe will soon be supported in all browsers, so that we have better data binding.
The question about dynamic templates comes up to every developer sooner or later. For sure, we have parts of our application that appear after the bootstrapping. The framework ought to handle that easily. We shouldn’t think about Ajax requests, and we should work with an API that makes the process look synchronous.
Modularity
I like the idea of turning features off and on. If we don’t use something, then why is it in our code base? It would be nice if the framework has a builder that generates a version containing only modules that we need. Like, for example YUI, which has a configurator. We choose the modules that we want and get a minified JavaScript file ready to use.
Even now, there are frameworks that have something usually called core. Additionally we are able to use bunch of plugins (or modules). However, we could improve that. The process of choosing the needed features shouldn’t involve downloading files. We should not include them manually in the page. It ought to be somehow part of the framework’s code.
After having appropriate setup capabilities, the perfect environment must provide extensibility. We should be able to write our own modules and share them with other developers. In other words, there should be a friendly environment for creating modules. We can’t develop a strong community without the existence of a proper developer environment.
Public APIs
So far, most of the frameworks provide APIs for their core functionalities. However, these APIs give access to parts that vendors think we need. And that’s the place where hacking becomes an option. We want to achieve something, but we don’t have the right instruments. We trick the framework with some ugly workarounds. Let’s have a look at the following example:
var Framework = function() {
var router = new Router();
var factory = new ControllerFactory();
return {
'addRoute': function(path) {
var rData = router.resolve(path);
var controller = factory.get(rData.controllerType);
router.register(path, controller.handler);
return controller;
}
}
};
var AboutCtrl = Framework.addRoute('/about');
We have a framework that has a built-in router. We define a path, and our controller is automatically initialized. Once the user goes to the right URL, our router fires the handler method of the controller. That’s great, but what happens if we need to execute a simple JavaScript function as a response to the URL matching? For some reason, we don’t want to create a new controller. This is not possible with the current API.
We could use another design like this one, for example:
var Framework = function() {
var router = new Router();
var factory = new ControllerFactory();
return {
'createController': function(path) {
var rData = router.resolve(path);
return factory.get(rData.controllerType);
}
'addRoute': function(path, handler) {
router.register(path, handler);
}
}
}
var AboutCtrl = Framework.createController({ 'type': 'about' });
Framework.addRoute('/about', AboutCtrl.handler);
Notice that we are not exposing our router. It is not visible, but now we have control of the two processes — creating the controller and registering a route. Of course, the proposed design matches our personal use case. We may find this approach much complex because we have to create controllers manually. While we design APIs, we have to think about the single responsibility principle and the idea of doing one thing and doing it right. I’m seeing that more and more frameworks decentralize their functionalities. They split the complex methods in smaller and smaller pieces. That’s a good sign, and I hope that we will see more of this in the future.
Testability
There is no need to convince you to write tests for your code. The point is not only in writing tests, but writing testable code. Sometimes this is extremely difficult and takes time. I’m sure that if we miss a test for something, even small, that’s the exact place where our application will start getting buggy. This is especially the case if we talk about client-side JavaScript. Several browsers, several operating systems, new specs, new features and their polyfills: there are so many reasons to start using test-driven development.
There is something else that we get from having tests. We are not only proving that our framework (application) works today. We make sure that it will work tomorrow and even after that. If there is a new feature that has to land in the code base, we write a test for it. And it is important that we make this test pass. However, it is also important that our previous tests pass as well. This is how we guarantee that we didn’t break anything.
I’d like to see more standardized tools and methods for testing. I wish I could use only one tool and test every framework with it. It’s also good if the testing is somehow integrated into the development process. Services like Travis need more attention. They act as an indicator not only for the programmer that makes the changes but also for the other contributors.
I’m still working with PHP. I had to deal with frameworks like WordPress for example. And a lot of people are asking me how I test my applications: what testing framework do I use? How do I run my tests? Do I even have unit tests? The truth is that I don’t. And that’s because I don’t have units. The same goes for some JavaScript frameworks. It is difficult to test some parts of them because they do not have units. The developers should also think in this direction. Yes, they have to give us smart, elegant and working code. But that code should be testable, too.
Documentation
I believe that without good documentation any project will die sooner or later. We have so many frameworks and libraries coming out every week. Documentation is the first thing that the developers see. No one wants to spend hours searching about what the certain tool is doing or what its features are. Only listing of the main functionalities is not enough. Especially for a big framework.
I could split the successful documentation into three parts:
What you can do section — the documentation has to teach the users, and it should do it right. No matter how awesome and powerful our framework is, there really has to be a proper explanation. Some people prefer watching video clips, others — reading articles. In both cases, the vendor should lead the developers from the very basic stuff to the advanced components of the framework.
API documentation — this is usually included. It’s a list of all the public methods of the framework, their parameters, what they return and maybe an example usage.
How it works section — usually this section is missing. It’s nice if someone explains the structure of the framework — even a simple schema of the core functionalities and their relation will help. This will make the code transparent. It will help the developers who want to make custom modifications.
Summary
It is, of course, difficult to predict the future. What we can do though is to dream about it! It is important that we talk about what we expect and what we need from JavaScript frameworks! If you have any feedback or want to share your thoughts, tweet them using the #jsframeworks hashtag.
]]>https://dev.opera.com/articles/opera-mini-chrome-os/Opera Mini on your Chromebook for fun and bandwidth2014-10-14T00:00:00+00:002014-10-14T00:00:00+00:00Vlad FilippovOpera Mini running on a ChromebookOpera Mini installing on Chrome OS
This summer Google previewed a way to run Android applications on Chromebooks using ARC — App Runtime for Chrome. At this time there are only a handful of applications that work on Chrome OS through official channels. However, there are tools and workarounds that allow users to run their favorite Android applications on Chromebooks. One of the applications that works well on Chrome OS is the Opera Mini browser.
It might sound a bit insane at first — why would you want to run a browser inside of a browser? Beside the mind-blowing “inception” factor, using Opera Mini on your Chromebook can actually help you save bandwidth when you are browsing using a cellular data plan. Developers can also utilize this Chromebook capability to easily test websites and see how well the web works with Opera Mini. Besides all that, it is a fun hack to play around with.
Running Opera Mini on Chrome OS
Here’s the fastest way to get Opera Mini running on your Chromebook, using an Android device and a custom runtime called ARChon (the difference in runtimes is explained later in the article):
Use the ARChon Packager on your Android device to convert Opera Mini for your Chromebook. This will generate a ZIP file. Transfer the ZIP file to your Chromebook. Use the “Tablet mode” and “Landscape” orientation when you are converting the application to get the best experience out of Opera Mini.
Unpack both ZIP files (the runtime and the application), navigate to
chrome://extensions/, enable “Developer mode” and load the two unpacked directories as “Unpacked extensions”. Make sure to load the runtime first. After you load the two directories just press “Launch” in the Opera Mini extension. The application will also be added to your Chrome OS launcher.
Chrome OS launcher integration
If you already use the official Android applications on Chrome OS, follow the instructions on GitHub to get Opera Mini working with the official runtime. At this time the official runtime can only run up to four applications on Chrome OS. If you do not have an Android device, then obtain the Opera Mini APK file and follow the instructions of the chromeos-apk project to get Opera Mini working using a Node.js conversion tool.
Opera Mini browsing in style
Most Opera Mini features, such as “Downloads” and “Find in page” work really well on Chrome OS. When you restart the application, your settings and history get saved. If you remove and reinstall the application, you get a fresh copy with all settings reset.
Most of the screenshots in this article are taken on a Chromebook Pixel. However, using the ARChon runtime for 32-bit and ARM devices you can try out Opera Mini on older hardware. This screenshot below is taken on a 32-bit Samsung Series 5 Chromebook from 2011:
Opera Mini on older Chromebooks
The Technology
The ARC (App Runtime for Chrome) is powered by the Native Client technology. This allows ARC to execute native compiled code in the browser. In this case, the Opera Mini application window is a basic HTML page with an embedded Native Client plugin component.
The runtime ships in three different flavors, for 64-bit, 32-bit and ARM processors. ARC consists of an ARM instructions translator, which allows Android applications to run in the plugin environment. There are also several libraries that emulate the Dalvik Virtual Machine and graphics hardware.
The custom runtime, called ARChon, is a forked version of ARC. ARChon is developed as part of the chromeos-apk project and allows running an unlimited number of Android applications on Chrome OS. ARChon also works on some Linux, Windows and OS X devices — this means you can try running Opera Mini on your desktop machine.
Currently it is not possible to run other complex browsers in these runtimes because of the native library requirement. Opera Mini does not have issues with native libraries and works outside of the box. It is also possible to tweak the application environment by editing the manifest.json file in the application directory. You can make the Opera Mini application window resizable or make the browser open files with different extensions. In addition, developers can turn on ADB (Android Debug Bridge) to take full control fo the sandboxed emulator for this specific application. The list of available runtime options is documented on GitHub.
Useful Links
The chromeos-apk project, the original conversion tool for Android applications to run on Chrome OS.
