Geeky songs and stuff from Daniel Davis

Menu

Tag Archives: HTML5

Mobile users are on the go. They’re rushing to get a train or busy meeting people. They don’t have much time and they’re on a slow connection. Right?

The answer of course is not necessarily. So-called mobile browsing could include shopping online while tucked up in bed, sending messages while watching TV or giggling at silly photos while relaxing in a cafe. It could also include being out and about but not using a mobile device.

In reality we have no idea what the users of our website are doing or where they are, and it would be a huge invasion of privacy if we did! Our fancy responsive designs should therefore not only look good but also be flexible enough to handle a variety of situations.

In other words, responsive doesn’t mean responding to screen size or even device capabilities. It means responding to the user’s environment (as much as possible).

Why use it

Knowing whether your user is plugged in or not and whether their battery has much juice left can influence how your site reacts. Battery-draining features such as repeated actions and animations can be reduced or disabled, for example. Or you could notify the user and offer to save the current state in case there’s a sudden shutdown.

How to use it

The spec had a rewrite recently and now uses shiny new promises. The advantage of this is that the API is asynchronous, meaning that when you call the getBattery() method the browser makes sure the BatteryManager object is ready before you try to read its attributes. Those attributes are:

charging (a boolean)

chargingTime (in minutes)

dischargingTime (in minutes)

level (a number between 0 and 1)

Each of these attributes has an event so you can listen for when they change. In practice, you could use the attributes and events like this:

Status

This API has the best support of the three with Opera, Chrome and Firefox having implemented it. In the case of Firefox, the implementation currently uses an old version of the spec so for the time being it’s best to allow for both versions in your code.

Why use it

You’re probably aware of the navigator.onLine HTML5 attribute and its wide browser support but that only tells us if the user is connected to a network or not. For more detailed information about the network we need the aptly-named Network Information API. With the data it provides you could opt to show smaller or lower-quality images to users on slow connections, or only show a video background when you know the network speed is fast. Be careful when making assumptions though — wifi doesn’t necessarily mean fast.

How to use it

When fully implemented this provides the type and speed of connection using two attributes (type and downlinkMax) on the global navigator object. Let’s jump straight into an example…

// Some browsers use prefixes so let's cope with them first
var connection = navigator.connection || navigator.mozConnection || navigator.webkitConnection;
// Check for browser support
if (!!connection) {
// Get the connection type
var type = connection.type;
// Get the connection speed in megabits per second (Mbps)
var speed = connection.downlinkMax || connection.bandwidth;
}

So easy! The type values are a pre-defined selection of self-explanatory strings:

bluetooth

cellular

ethernet

none

wifi

wimax

other

unknown

Network speed, when available, is exposed as downlinkMax, previously called bandwidth, although in reality this is difficult for browsers to measure so it may be a while before we’re able to use it. You can also attach a change event listener to navigator.connection to be even more responsive.

Status

In the browsers I tested only connection.type was supported properly and that was only in Chrome for Android and Firefox Mobile/OS (you may need to ensure dom.netinfo.enabled is set to true). It’s still early days for this API but its simplicity means it could easily be incorporated into your website or app.

Why use it

We’re probably all familiar with struggling to read a screen in bright sunlight. Increasing the contrast of what’s displayed on the screen or hiding distracting backgrounds can make content much easier to read in such cases. The opposite is true — reducing how vivid a design is can avoid users screaming and covering their eyes when in a dark environment.

How to use it

Tomomi Imura, AKA@girliemac, has the definitive lowdown on how to respond to differing levels of light. Eventually we’ll all be able to use CSS4 media queries so when the light-level is dim, for example, we can respond accordingly. In the meantime though, there’s the more precise JavaScript approach which gives you access to data from the device’s light sensor. You just listen for a devicelight event and use that event’s value attribute to get the brightness of the user’s surroundings measured in lux. For example:

What is this doing? Let’s go through it bit by bit. Assuming we have a video called myvideo.mp4, the simplest way to convert to WebM is with this little line:

avconv -i myvideo.mp4 myvideo.webm

Easy, but the quality will likely be rubbish hence the use of a few flags. The flags can be divided into three sorts: audio, video and the transcoding itself.

Audio flags

Concentrating on the audio first, we should specify the audio codec which for WebM is Ogg Vorbis: -acodec libvorbis

In later versions the audio codec is Ogg Vorbis by default but personally I specify it just in case.

The quality can be adjusted with the -aq flag from -1 to 10 with a higher number meaning better quality. I’ve found 4 or 5 to be more than adequate.

The number of channels, e.g. mono (1) and stereo (2), is controlled with the -ac flag.

Video flags

Moving on to the video quality and thankfully it’s nice and simple. Like the audio, we can specify a quality level. With the libvpx library used for WebM, this is actually a quantization level, set with the -qmin and -qmax flags ranging from 0 to 51. In my tests, setting qmin makes no difference so I ignore it. Setting qmax effectively controls the maximum compression that will be applied to each frame. In other words, a higher qmax means higher compression, which results in lower quality and smaller file size. Obviously you should adjust this to whatever’s best for your circumstances, but I’ve found 25 to be a good starting point.

Note that with both the audio and video, setting flags for bitrate (-ab for audio, -b for video) makes little or no difference. Instead, setting quality flags indicates the use of a variable bitrate.

Transcoding flags

Finally, I tend to also use the -threads flag. This simply sets how many CPU threads to use when transcoding. If your PC has multiple cores then a higher number means faster processing but with less spare capacity for running other programs. Incidentally it’s also possible to do 2-pass encoding with WebM using the -pass flag.

FFmpeg naming confusion

Note that due to what seem to be political reasons, using the ffmpeg command in Ubuntu results in a sad message.

Was:

*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.

Now:

ffmpeg: command not found

It turns out that FFmpeg is very much alive, as is Libav (avconv), both with similar goals but with slightly different ways of doing it. I don’t follow the details and arguments but for practical purposes, using either the ffmpeg or avconv command is fine for converting videos to WebM with the above flags (at the time of writing). Of course, this may change eventually but for the sake of regular users, I hope not.

Unfortunately whatever FFmpeg/Libav disagreement there was has resulted in ffmpeg being removed from Ubuntu and possibly other Linux distros. For the transcoding commands in this post at least, the parameters are the same so if you have problems using avconv try with ffmpeg and vice versa.

Opera colleague Bruce Lawson thought it might be spiffing if the description of the <ruby> element that appears in the HTML5 spec was clarified a bit, so here’s my attempt. I’m using Japanese as an example although it applies to Chinese and possibly other languages as well. Please note my definition of one syllable may differ from yours.

Step 1: The Japanese Writing System

In Japanese there are three alphabets—one semantic (thousands of characters) and two phonetic (roughly 50 each).

The semantic alphabet is called kanji, based on traditional Chinese characters, and each character has a meaning (although sometimes quite abstract). When you read words written with kanji you may understand their meaning but there are no clues as to their pronunciation.

日 = sun
本 = origin
日本 = land of the rising sun = Japan

The first phonetic alphabet is hiragana. This comes from highly stylised Chinese characters developed around the 5th century when only men were educated enough (or deemed intelligent enough) to use Chinese characters (kanji). Literate ladies of the ruling class used the easy-to-write hiragana, each representing one syllable and having no meaning, to write letters, poetry and novels (the original chick lit). When you read words written with hiragana you can pronounce them but you may not know their meaning.

に = ni
ほ = ho
ん = n
にほん = nihon = Japan

The second phonetic alphabet is katakana. This apparently was developed by monks also using Chinese characters as a basis for a highly simplified alphabet. Whereas hiragana characters are more rounded, katakana characters are more sharp and angular. They are used primarily for foreign words that don’t have a Japanese translation (e.g. “browser”) or for making a word stand out or appear modern. Like hiragana, when you read words written with katakana you can pronounce them but you may not know their meaning.

二 = ni
ホ = ho
ン = n
二ホン = nihon = Japan

Any piece of Japanese text (banner ad, article, legal doc, etc.) uses a combination of kanji, hiragana and katakana. It is sometimes the case that people reading the text can’t read the kanji, especially because kanji characters can have more than one pronunciation. People and place names are one example of kanji having numerous or irregular pronunciations.

日 = can be pronounced "nichi", "hi" or "ka"
本 = can be pronounced "hon" or "moto"
日本 = can be pronounced "nihon" or "nippon" = Japan

To help the reader, sometimes the pronunciation is written above the kanji using the hiragana alphabet. This is called furigana in Japanese and ruby in English (from the name of small type with a height of 5.5 points). It is often used in newspapers and books but not so much on websites, due to the difficulty of squeezing miniature text above larger text on a single line. The <ruby> element aims to solve this.

Step 3: Tell us how it works

According to the current HTML5 spec, the <ruby> element is an inline element and is placed around the word or character you’d like to clarify, like so:

<ruby>日本</ruby>

By itself this does nothing, so we add the pronunciation either for each character or, as in this case and my personal preference, for the word as a whole. For this, we use the <rt> tag, meaning ruby text.

<ruby>日本<rt>にほん</rt></ruby>

We could leave it like that and supporting browsers would show the hiragana pronunciation above the kanji text, but non-supporting browsers would ignore the tags and show both the text and its pronunciation side-by-side. To solve this, the masters of the HTML5 universe have given us another tag, <rp> meaning ruby parentheses, which cleverly hides characters (namely parentheses) in supporting browsers. This means we can write the pronunciation in parentheses which non-supporting browsers will show, and supporting browsers will continue to show the pronunciation without parentheses above the main text.

<ruby>日本<rp>(</rp><rt>にほん</rt><rp>)</rp></ruby>

Step 4: Say what?

Supporting browsers → ruby text is shown above main text

Non-supporting browsers → ruby text is shown next to main text but in parentheses.

Overall, the <ruby> element is a great help not just for learners of Japanese (or Chinese, etc.) but also for when uncommon characters are used in a piece of text. It could also be used in any language simply for clarifying a term or unfamiliar concept in an unobtrusive and accessible manner.

For reference:

Also, see this page for an example of how hiragana.jp uses the <ruby> element (and CSS for non-supporting browsers) to provide ruby text above all kanji words. Perfect for people learning to read Japanese. Note that they also use the <rb> tag to markup the kanji words but at the time of writing this is not officially part of HTML5.

Although it’s possible to use VLC for Ogg encoding, I had problems with the audio and video being out of sync. Fortunately I found another way – enter OggConvert.

Written in Python by Tristan Brindle, there are packages for the major Linux distributions as well as a version for Windows. Not only that, it’s open source (GNU LGPL), preserves metadata when converting and is extremely easy to use:

Fire up OggConvert

Select the source video (or audio) file

Click convert

Voila! Enjoy your Ogg video

By default, the target file is saved in the same directory and with the same name as the source file but with an .ogg or .ogv extension. The default quality settings seem a bit low but should be adequate for most purposes.

When done, your Ogg video is now ready to use in your HTML5 pages:

<video src="video.ogg" width="320" autobuffer controls>
<p>Sorry, your browser can't play this video but you can
<a href="video.ogg">download it here</a>.</p>
</video>

Firstly, an important caveat. The HTML5 validator is beta so may have erroneously missed or mis-detected issues. In addition, at the time of writing HTML5 is still a working draft only and public websites should not be expected to support it yet. Not being valid HTML5 means nothing unless the document’s doctype indicates that it’s HTML5, which none of them do at this stage. This is just intended to be a (hopefully educational) “what if” exercise. Having said that, several sites didn’t even validate against current standards – I’m looking at you list.opera.com, widgets.opera.com, bugs.opera.com, portal.opera.com, labs.opera.com and irc.opera.com!

Admittedly this only uses Opera’s websites as an example and they are more compliant than most, but I was still surprised at how little work would be needed to make any of these valid HTML5. I wonder if the folks at snapshot.opera.com know they’re already ahead of the game?