<form action="process.cgi" method="post" enctype="multipart/form-data">
 <p><keygen name="key"></p>
 <p><input type=submit value="Submit key..."></p>
</form>

SSL is about “server identification” , “server AND client authentication” and “security”. During the normal SSL handshake the server presents its server-certificate so the browser can be sure that this is the correct server it is connecting to. But what should the server use to identify that it is the same user (browser) it is connecting to once the initial handshake has been done. For this purpose you need a client-certificate. The keygen element is used for creating a key for authentication of the user while SSL is concerned about privacy of communication and the authentication of the server.

Automatically detect mobile browsers.
Easy to integrate – no server side changes needed.
Open source – no expensive software or licenses needed.
Familiar HTML5, Javascript and JQuery Mobile tools used.
Supports iPhone, Android, Blackberry, Opera Mini and other browsers and devices.

If you have a WordPress site, plugins are available for the same. To see exactly how mobile.js works, check this section of the documentation.

Below is a sample markup using the schema.org vocabulary and microdata.

Original.

<img src="dell-30in-lcd.jpg" />
Dell UltraSharp 30" LCD Monitor
 
87 out of 100 based on 24 user ratings
 
$1250 to $1495 from 8 sellers
 
Sellers:
<a href="save-a-lot-monitors.com/dell-30.html">
  Save A Lot Monitors - $1250</a>
<a href="jondoe-gadgets.com/dell-30.html">
  Jon Doe's Gadgets - $1350</a>

With semantic markup added.

<div itemscope itemtype="http://schema.org/Product">
  <img itemprop="image" src="dell-30in-lcd.jpg" />
  <span itemprop="name">Dell UltraSharp 30" LCD Monitor</span>
 
  <div itemprop="aggregateRating" 
    itemscope itemtype="http://schema.org/AggregateRating">
    <span itemprop="ratingValue">87</span>
    out of <span itemprop="bestRating">100</span>
    based on <span itemprop="ratingCount">24</span> user ratings
  </div>
 
  <div itemprop="offers" 
    itemscope itemtype="http://schema.org/AggregateOffer">
    <span itemprop="lowPrice">$1250</span>
    to <span itemprop="highPrice">$1495</span>
    from <span itemprop="offerCount">8</span> sellers
 
  Sellers:
  <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    <a itemprop="url" href="save-a-lot-monitors.com/dell-30.html">
     Save A Lot Monitors - $1250</a>
  </div>
  <div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
    <a itemprop="url" href="jondoe-gadgets.com/dell-30.html">
     Jon Doe's Gadgets - $1350</a>
  </div>
  ...
</div>

Although this may seem a lot of extra work and time, the efforts will pay handsomely over a period as more people adopt semantic markup and companies come up with better tools and APIs to work with the new data.

Storage Events

Whenever a localStorage object is changed using the setItem(), removeItem(), or clear() functions, the storage event is fired (across multiple windows of the same origin) by the browser, we can trap this event and use it to share messages or data across windows. Check the following demo to see how this works in a simple case.

The above example works by using the storage event of the Window object. So whenever the localStorage object is modified, the storage event is fired and we use it to update the window content.

window.addEventListener("storage", displayStorageEvent, true);

Below is the skeleton code for the demo example.

// Input element
var data = document.getElementById('data');
// Element to display the updated data
var output = document.getElementById('event-data');
 
function displayStorageEvent(e) {
    if (e.key == 'storage-event') {
        output.innerHTML = e.newValue;
    }
}
 
function updateStorageEvent() {
    localStorage.setItem('storage-event', this.value);
}
 
window.addEventListener("storage", displayStorageEvent, true);
data.addEventListener("keyup", updateStorageEvent, true);

Sharing messages

Although in the above example we are sharing data across windows, we can use the same mechanism to share messages. In the above example we are using the ‘storage-event’ key to store the data we type in the input box. Instead we can pass a simple message. The syntax remains the same, only the semantics changes.

/* Store the 'checkPassword' message in the 'app.message.auth' key */
localStorage.setItem('app.message.auth', "checkPassword");
 
/* Store the 'dataSave' message in the 'app.message.status' key */
localStorage.setItem('app.message.status', "dataSave");

Security concerns

As the communication can only happen between windows with the same origin, there is little risk of data leak between sites. Still you should refrain from storing sensitive information in the storage.

Possible applications

Now that we have seen a simple proof of concept of ‘cross window messaging and data sharing’, what are the potential use cases of the same. An idea without a concrete and useful application is useless. Although many people will have good ideas for the above concept, I presently lack one. So if you can think of some nice use cases for this, please voice your ideas in the comments section.

Geolocation enables you as a developer or website owner to figure out where a particular user is located on the planet. This can be helpful in various web applications; for example in social networking, where you can find out where your various friends are currently located or in advertising where you can display targeted ads based on the users location.

Getting your users location

In the past, IP based geolocation was the only way to get a users possible location. Services and databases such as MaxMind or ip2location where used to locate the position of the user, based on the users IP address.

Now that Geolocation is available as a built-in API service in HTML5, it makes easier for developers to quickly integrate location based services into their applications.

Detecting Geolocation support

Before you write any Geolocation code you need to check if it is supported on your browser. The simplest way to detect if Geolocation is supported is to use the global ‘navigator’ object.

if(navigator.geolocation) {
    // Geolocation supported. Do something here.
}

Reading users location

Once we have checked that Geolocation is supported we can use the following to get the users location data.

navigator.geolocation.getCurrentPosition(success_handler, error_handler);

This will execute the callback function ‘success_handler’ if the request is successful or the ‘error_handler’ callback if some error occurs. The location data is available as a ‘position’ object in the ‘success_handler’.

function success_handler(position) {
        latitude = position.coords.latitude;
        longitude = position.coords.longitude;
        accuracy = position.coords.accuracy;
    }

Below is a list of all properties available:

User privacy

When you opened the demo web page given above you may have received a notification bar like the following; this bar requests your permission to share your location with the browser.

The HTML5 Geolocation specification mandates that before any location data can be retrieved the browser first request permission from the user to share its location. Only when the user allows does the browser retrieves the users location.

Note: If opted to ‘always share’ or ‘always deny’ in Firefox and later change your mind, you can easily revert permissions by going back to the website and selecting ‘Tools’ menu->’Page Info’ in Firefox. Then change the setting for ‘Share Location’ on the Permissions tab.

How does Geolocation work

Once you give permission to the browser to share your location, the browser gathers information about nearby access points and also your computer’s IP address which the browser then sends to the default geolocation service provider – Google Location Services in case of Firefox, to get an estimate of your location. This location estimate is then sent to the requesting website.

Location accuracy

You may have noticed above that the ‘position’ object returns a accuracy variable. accuracy represents a value in meters which specifies how close the latitude and longitude values are to the actual location. You can increase the location accuracy by passing a option to the getCurrentPosition function. Bear in mind that this is only a hint that you give to the browser; whether it returns a high accuracy result depends on the location service your browser uses.

navigator.geolocation.getCurrentPosition(
                                    success_handler, 
                                    error_handler, 
                                    {enableHighAccuracy:true});

Saving location to Cookies

Once we get the location data from the user it is better to store it for the entire session so we can use it on other pages. Storing it in cookies is one quick option. For this example I’ve used the jQuery cookie plugin, which provides a simple and clean way to save and retrieve cookies.

We can store the cookies in the ‘success_handler’ and then later check the same before issuing another location request.

function success_handler(position) {
        /* Get the location data */
        latitude = position.coords.latitude;
        longitude = position.coords.longitude;
        accuracy = position.coords.accuracy;
 
        $.cookie("posLat", latitude);
        $.cookie("posLon", longitude);
        $.cookie("posAccuracy", accuracy);
    }

Now that we have nicely saved the data, all the other site pages can now access the location data by reading them from the cookies.

/* Check if location data is available in the cookies */
if($.cookie("posLat")) {
    latitude  = $.cookie("posLat");
    longitude = $.cookie("posLon");
    accuracy  = $.cookie("posAccuracy");
 
    // do something here
}

Continuous Position Updates

In the above example the location was read once and stored for future use. But what if your application is on a mobile device and you are on the move. The Geolocation API provides another function navigator.geolocation.watchPosition that automatically retrieves the users current location if it ever changes. The function is similar to ‘getCurrentPosition’, the only difference is that it regularly polls the location and returns the new location data.

var watch_id = navigator.geolocation.watchPosition(
                                        success_handler, 
                                        error_handler
                                        );

The function return a unique numeric id which you can later use to stop the polling.

navigator.geolocation.clearWatch(watch_id);

Software developers worldwide know that a web application will only work the way it’s supposed to for its target market. Even if two countries speak the same language, there are plenty of other things to consider when it comes to localising an app. Take, for example, the UK and the United States. The date format in the UK is day/month/year, while the US uses month/day/year, which could be cause for problems if an app is not localised for its specific market.

But before we move forward, you’re due an explanation of what internationalisation and localisation are. Internationalisation is the technical process of preparing a web application for use in a range of different countries without further changes to the platform. Localisation means adapting a web application for a specific market, translating the text and taking into consideration every component of the app.

This is a two-step process, because internationalisation is a precursor of localisation. Developing an application to reach a large number of countries from the start will simplify the process of localisation later on. Having an internationalised web app from the get go will ensure that once you figure out the market, you’ll only need to translate the text and change the necessary formats, rather than having to start from scratch.

The internationalisation process

Not every web application can be internationalised in the same way. From differences in platform to the very basics of the application, there are key differences programmers must identify before starting work. Nevertheless, there are some basic internationalisation principles that can be applied universally.

If your application is to be developed using English as its base language, the best thing to do is use clear and simple language. Remember that once the localisation process begins, the text will have to be translated, and nothing makes the translation process more difficult than dealing with abbreviations, jargon or slang in the text.

Another thing you should keep in mind is that not all languages require the same amount of space. For example, a sentence in German will, in general, be around 30% longer than the equivalent sentence in English. If your app hasn’t been designed with enough space for extra characters then you may end up with serious formatting issues. It’s always a good idea to design apps with room for text to grow or shrink.

If you do have to set a fixed space for the text, remember to inform your translators of the available space before they start work, so they can work with that character limit in mind and won’t have to skip any text to make the content fit.

The localisation process

The most important part of the localisation process is translation. The best course of action is to hire a native translator. As you might already know, translation is more than just changing words between languages – it requires a cultural background in the target language to understand nuance and subtlety, which something machine translation programs can’t do.

Before you hire translators and start localising your app for a range of languages, though, it pays to take a closer look at which countries actually have a gap in the market that can be filled by your app – for instance, if you’ve developed an application that’s specifically designed to link with Facebook then there’s not really any point localising it for China, where Facebook has no market presence.

Once you’ve identified the best foreign markets for your app, the localization process involves researching the specific charts and tables of the country, such as date formats, measurements of length, temperature, weight, currency, etc, to ensure your app feels like it’s been designed specifically for that audience.

Cultural differences

There’s more to developing a localised software app than just translating the text and changing the formats and measurements, though. Visual symbols, colour, images and icons are also an important part. Colours can be crucially important, as they can have widely differing meanings in different cultures, for instance, white is often interpreted as being ‘peaceful’ in Western societies, but it’s a colour associated with death and funerals in China. A little research can go a long way to developing the perfect app for your market of choice.

Icons and images are another integral part of your web application and should be picked after thorough consideration. A ‘thumbs-up’ icon is widely accepted in western societies (see Facebook’s ‘like’ button), but it’s also seen as very offensive in some parts of the world, such as parts of Africa and the Middle East, where it has a similar meaning to the middle finger in western cultures. The same can be said of the ‘table’ icon, which signifies a spreadsheet to English-speakers, but not to anyone else.

Developing a multilingual internationalised and localised web application isn’t the easiest thing in the world, but creating a detailed project plan and conducting thorough research of your target markets will make the process infinitely easier.

This guest post was written by Christian Arno. Christian is the founder of professional translation agency Lingo24. Launched in 2001, Lingo24 now has over 150 employees spanning three continents and clients in over sixty countries. Follow Christian (@l24ca) and Lingo24 (@Lingo24) on Twitter.

“Wallaby” is the codename for an experimental technology that converts Flash content (FLA files) into HTML 5. This allows you to reuse existing Flash content on devices that do not support Flash. Once converted to HTML, you can easily edit them using Adobe Dreamweaver or any other editing tools.

Wallaby comes as a desktop Adobe Air application so you will need the AIR runtime installed on your system to run the application.

Wallaby uses SVG instead of Canvas to recreate the output because SVG is rendered natively by the browser while Canvas is drawn with JavaScript, which tends to slow down the rendering. According to experiments carried out by Adobe, Canvas was a lot slower than SVG on portable devices. Another point cited by Adobe for favoring SVG is that of readability. Using Canvas lowers the readability of the HTML since the output becomes a program instead of markup as in SVG.

Note that as of now not all Flash Professional features are supported in the HTML5 format, so Flash files above average complexity will not be rendered properly. I tried converting a few FLA files but met with a few conversion errors, mainly that of incompatible file format. As Adobe is desperate to make its presence felt in the portable devices market, expect a more complete working product by 2011 end.

You can download Wallaby from Adobe Labs.

What are Web Workers

Web Workers are basically a API specification that lets you create background JavaScript threads to process CPU intensive tasks. Normally in browsers a single thread is created to handle all the JavaScript code. So whatever JavaScript code is run in the browser is executed in that single thread; whether you are doing some calculation or updating page elements. The downside of this is that some CPU intensive piece of JavaScript can render the page unresponsive or slow it to a crawl.

Web Workers alleviate this problem by letting you create multiple JavaScript threads that will run independent of each other, this will prevent one CPU intensive piece of JavaScript from interfering with the UI code.

Checking Web Worker support

Before you create any Web Worker related code you will need to find if your browser supports HTML5 Web Workers. Failure to do this will send your Web Workers to slog in Never Never Land. The following code will allow you to check if your browser supports Web Workers.

/* Check if Web Workers are supported */
function getWebWorkerSupport() {
    return (typeof(Worker) !== "undefined") ? true:false;
}

Creating a simple Worker

Once we have checked that Workers are supported in the browser we are ready to put them to task. In this example we will create a simple Web Worker that will ‘Add’ or ‘Multiply’ two numbers. The example is deliberately kept simple to keep the discussion focused on Worker details; in reality you would not use Workers for such simple things, but for more elaborate and CPU intensive tasks. Below is a small piece of JavaScript code that does the actual arithmetic calculation. This our Worker. It is stored in the ‘arithmetic.js’ file.

/* arithmetic.js */
 
function addNumbers(x,y) {
    return x + y;
}
 
function mulNumbers(x,y) {
    return x*y;
}
 
/* 
   Add a event listener to the worker, this will
   be called when the worker receives a message
   from the main page.
*/
this.onmessage = function (event) {
    var data = event.data;
 
    switch(data.op) {
        case 'mult':
        postMessage(mulNumbers(data.x, data.y));
        break;
        case 'add':
        postMessage(addNumbers(data.x, data.y));
        break;
        default:
        postMessage("Wrong operation specified");
    }
};

Now that we have or Worker file ready we need to call it from our main file.
The following line will create a new Worker thread and run the code stored in ‘arithmetic.js’.

/* Create a new worker */
    arithmeticWorker = new Worker("arithmetic.js");

Once we have created Workers we need to send and receive messages from them. For that we need to add a event handler to the main calling code.

/* 
   Add a event listener to the worker, this will
   be called whenever the worker posts any message.
*/
arithmeticWorker.onmessage = function (event) {
    document.getElementById("output").value = event.data;
};

Now whenever a Worker posts a message the ‘onmessage’ event is fired and the code within it is executed. The data passed by the Worker is stored in the event.data container. We have seen how to receive a message from the Worker but how to we post one. Posting a message to the Worker is very simple.

/* Message sent by the main page to the Worker. */
arithmeticWorker.postMessage('Main says...');

The message can be a simple variable or a JSON object. The same event management applies to the Worker file. Whenever the main page posts a message to the Worker the Worker can receive the message in a ‘onmessage’ event handler, at the same time the Worker can post a message to the main page with the ‘postMessage’ method.

/* Message sent by a Worker to the main page. */
postMessage('Worker says...');

We have already seen the Worker code. Below is the code for the main file.

<!DOCTYPE html>
<body>
<input type="text" id="x" value="2" />
<br />
<input type="text" id="y" value="3" />
<br />
<input type="text" id="output" />
<br />
<input type="button" id="multButton" value="Multiply" />
<input type="button" id="addButton" value="Add" />
 
<script>
 
/* Check if Web Workers are supported */
function getWebWorkerSupport() {
    return (typeof(Worker) !== "undefined") ? true:false;
}
 
 
if(getWebWorkerSupport() == true)
{
    var x,y,message;
 
    /* Create a new worker */
    arithmeticWorker = new Worker("arithmetic.js");
 
    /* 
       Add a event listener to the worker, this will
       be called when the worker posts a message.
    */
    arithmeticWorker.onmessage = function (event) {
         document.getElementById("output").value = event.data;
    };
 
    /* Register events for buttons */
    document.getElementById("multButton").onclick = function() {
        /* Get the values to do operation on */
        x = parseFloat(document.getElementById("x").value);
        y = parseFloat(document.getElementById("y").value);
        message = {
            'op' : 'mult',
            'x'  : x,
            'y'  : y
        };
        arithmeticWorker.postMessage(message);
    }
 
    document.getElementById("addButton").onclick = function() {
        /* Get the values to do operation on */
        x = parseFloat(document.getElementById("x").value);
        y = parseFloat(document.getElementById("y").value);
        message = {
            'op' : 'add',
            'x'  : x,
            'y'  : y
        };
 
        arithmeticWorker.postMessage(message);
    }
}
</script>
</body>
</html>

Terminating Web Workers

Once the main page starts a Worker thread, the thread doesn’t terminate by itself. The calling page has to explicitly ask the Worker to terminate. This may become necessary because creating each new Worker consumes precious browser resources, which you will need to reclaim once the Workers task is no longer required.

/* Terminate the Worker */
arithmeticWorker.terminate();

Workers and DOM accessibility

Due to the threading nature of Workers they do not have access to the following JavaScript objects.

* The DOM (it’s not thread-safe)
* The window object
* The document object
* The parent object

VIEW DEMO

Encoding HTML characters

The function is quite simple. It encodes email, links or other string characters to their ‘Numeric character references’. For example ‘code‘ will be encoded to code – a decimal encoding or code – a hexadecimal encoding.
The function randomly encodes a character to a hex or decimal representation, so each page refresh will encode the same string to a different format.

<?php
 
function encodeString($email)
{
    $enc_email = '';
    srand();
 
    # Convert each character to decimal or hex representation
    for ($i=0; $i < strlen($email); $i++) {
 
        if(rand(0,1) == 0) {
            $enc_email .= "&#" . (ord($email[$i])) . ";";
        } else {
            $enc_email .= "&#X" . dechex(ord($email[$i])) . ";";
        }
    }
 
    return $enc_email;
}
 
echo encodeString("designhouse@host.com");
 
?>

This will convert the email ‘designhouse@host.com’ to

designh
ouse@ho
st.com

As it uses a random base (decimal or hex), the actual results may differ from yours.