Dev Opera Articles

4: Web 標準のモデル — HTML, CSS, JavaScript

2009-11-05T09:30:52Z

Opera Mobile 10 beta developer’s introduction

2009-11-03T07:06:13Z

Introduction

Opera Mobile is our web browser for high-end phones and we have just released a beta of version 10, which can be installed on Nokia smartphones. To find out more about whether your phone will run it and how to download it, visit our Opera Mobile section. As well as being a double digit Opera Mobile release, Opera Mobile 10 beta is also the first Opera browser to use our Presto 2.4 rendering engine, which features enhanced standards support.

Opera Mobile is a complete web browser installed on your mobile phone—all the code rendering and JavaScript interaction happens on your mobile. This is in contrast to Opera Mini, where the rendering happens on the server and a compressed version is then sent to the handset.

Opera Mobile 10 features

Figure 1: Opera Mobile 10 beta UI

Once you’ve installed Opera Mobile 10 and launched the application, the first thing you’ll notice is the new UI. Figure 1 demonstrates the new tabs, icons and also Speed Dial, the popular feature we pioneered in our desktop browser. Speed Dial has now been ported to Opera Mobile and appears when you start the browser, open a new tab or select Start Page from the menu, giving you fast access to your favorite sites.

A lot of work has gone into streamlining the look and feel of our browser products across different devices, so using Opera Mobile 10 will be a familiar experience to anyone who has already used Opera Mini 5 beta, which we released in September.

Like its big brother on the desktop, Opera Mobile 10 also features Opera Turbo. If you are browsing the Web in an area of low or patchy bandwidth, you can turn on Opera Turbo to compress web sites by up to 70%, depending on your circumstances.

If you dive into the Settings, you’ll find many more options, such as Mobile view, which displays content in a single column, as well as advanced privacy management settings and more. And just like its desktop counterpart, you can enter opera:config in the address bar for power user tweaks.

The Opera Mobile 10 beta user agent string

Similar to Opera 10 for desktop, Opera Mobile 10 beta identifies as Opera 9.8, version 10.00. The user agent string is as follows:

Opera/9.80 (S60; SymbOS; Opera Mobi/275; U; en-GB) Presto/2.4.13 Version/10.00

Also note that in general, Opera can be identified by using JavaScript to test for the window.opera object.

Optimizing for mobile

Generally, you shouldn’t sniff for browsers and serve different content to different user agents. Instead, you can make your sites work well across a variety of devices and screen sizes using common HTML and CSS hooks. This section has more details on how to do this.

Viewport meta tag

When loading a Web page in Opera Mobile, the user gets a zoomed out overview of the page and then can pan and zoom into selected content in just a few clicks. While this approach works fine for most websites, it is possible to further enhance the user experience by presenting an already zoomed in view of the page, thereby giving the page a more application-like feel.

By including a viewport meta tag in the head section of the page, content authors can override the default width a page gets on mobile—Opera Mobile assumes this is 850 pixels—and instead set an arbitrary pixel value, such as 320, 480, etc. For cross-device compatibility purposes and easy calculating, we recommend setting the width to the device-width variable, as follows:

<meta name="viewport" content="width=device-width" />

This adjusts the page width to fit in the full width of the screen, or put differently, it makes one CSS pixel equal to one device pixel.

A lot of websites use the viewport meta tag only on a different “mobile” URL, but it is worth pointing out that by combining it with Media Queries, it is possible to just have one page that works well and is optimized for several screen sizes.

Media Queries

Media Queries are a CSS3 feature that allow you to specify under what conditions a style sheet should be applied. They are included using the @media at-rule, a media type, and optional expressions that limit the scope of the style sheet. For instance, to limit a style sheet to only apply to a screen with a viewport of 480 pixels or less, you could use the following Media Query:

@media screen and (max-width: 480px) {  
  background-color: red;
  font-size: 1.5em;
}

Note the relationship to the viewport width here: in case the page is loaded in a desktop browser, the viewport width is the width of the browser window; in case it is loaded in Opera Mobile 10 beta, the viewport width is defined by the viewport meta tag, unless there is none present, in which case it defaults to 850 pixels.

You can try this out for yourself by loading our Media Queries + viewport example in Opera Desktop and Opera Mobile 10 beta: on desktop, we get a three column layout for browser widths wider than 800 pixels—the page gets a different layout when the browser is resized. On Opera Mobile 10 beta, a viewport of width=device-width (in the case of the Nokia 5800 in portrait mode this translates to 360 pixels) triggers the @media screen and (max-width: 400px) {} style rules to be applied, and the three column page turns into a single column one.

Improved remote debugging with Opera Dragonfly

Figure 2: Opera Dragonfly element highlight

As with earlier Opera Mobile releases, Opera Dragonfly allows you to debug your web pages directly on your mobile phone. To debug pages in Opera Mobile 10 beta, open Opera Dragonfly in Opera Desktop (Tools → Advanced → Developer Tools) and follow the instructions in the Dev Opera remote debugging article. As Opera Mobile 10 uses Presto 2.4, Opera Dragonfly will have to download a new compatible version before you can start debugging.

The main new feature in Opera Dragonfly and Opera Mobile 10 beta is the element highlight. This feature highlights the metrics of the currently selected element. When clicking on a element, it is highlighted along with alignment guides. When clicking on the Layout tab in the DOM inspector, you can hover over the different metrics such as the margin or padding to highlight that part of the element. The highlight colors are fully customizable (go to the Settings tab and click on the Spotlight heading.)

New standards support

Opera Mobile 10 beta is the first Opera browser release to feature our new Presto 2.4 rendering engine. The new engine supports everything featured in Presto 2.3, plus some new additions.

For this beta release, we have not enabled Vega accelerated rendering yet, so features such as border-radius, box-shadow, etc. that depend on our Vega graphics backend don’t work for now. Also note that this is an early version of Presto 2.4 and not all standards features have been included in this release. We have more in the pipeline for future Opera Mobile 10 versions, so stay tuned.

That being said, Presto 2.4 brings new support for a couple of interesting CSS properties to Opera Mobile 10 beta. In the sections below, we explore how you can use them in your website.

Background-origin

background-origin and background-repeat (see below) are part of the CSS3 Backgrounds and Borders module and are closely related. Both showcases also use some oh-so-handy Media Queries so the layout is optimized for both mobile and desktop users.

The first showcase demonstrates background-origin. This property specifies the starting point of any background image you apply to an element and the values it can take are as follows:

padding-box: Positions the background image relative to the outer edge of the padding (inner edge of the border). This is the default behavior.
border-box: Positions the background image relative to the outer edge of the border.
content-box: Positions the background image relative to the outer edge of the content (inner edge of the padding).

The example shows three divs with the same background image applied to them and a similar double border. Each one has a different background-origin value set on it. From left to right, these are background-origin: padding-box, background-origin:border-box and background-origin:content-box. Figure 3 shows the different effects these have.

Figure 3: The difference between background-origin:padding-box, background-origin:border-box and background-origin:content-box.

Background-repeat

The second showcase highlights two new values for background-repeat, namely round and space, both introduced to tidy up repeated background images that don’t fit neatly into your container.

round: The background image is resized to fit in the container a whole number of times.
space: Whitespace is inserted between background images to fit in the container a whole number of times.

In the two examples in Figure 4 the background images both have the same width of 100 pixels. In the first example, the dinosaur would normally appear two and a half times horizontally so the effect of round here is to shrink the image so that three instances can fit in the container.

The second example works in a similar way but whitespace is resized instead of images. Again, the dinosaur would normally appear two and a half times horizontally but the use of space has resulted in just two images being displayed with padding between them.

Figure 4: The difference between background-repeat:round and background-repeat:space.

Word-wrap

Live word-wrap showcase

Word-wrap is nice and straightforward taking either of two attributes, normal or break-word. The default setting is normal meaning that lines are only broken at allowed break points such as spaces, for example. Changing this to break-word forces words to be broken if they would otherwise overflow beyond their container, as in Figure 5.

Figure 5: Word-wrap demo

word-wrap should not be confused with text-wrap which sets the mode for text wrapping. Also note that word-wrap is only effective if text-wrap is set to normal (default) or suppress.

Summary

That wraps up our introduction to Opera Mobile 10 beta. We’ve taken you through its main new features and exciting new web standards support. As always, let us know how you like it!

3: インターネットのしくみ

2009-10-20T08:16:52Z

はじめに

舞台の裏側で、歯車やベルトが回るのを見たことがあるでしょうか。今回は皆さんもよく知っている World Wide Web について、その舞台裏をお見せしましょう。

World Wide Web を支えている技術には、次のようなものがあります。

HTML (Hypertext Markup Language)
HTTP (Hypertext Transfer Protocol)
DNS (Domain Name System)
Web サーバーと Web ブラウザー
静的コンテンツと動的コンテンツ

これらはインターネットの基盤技術ですから、この記事で解説することは、よい Web サイトを作るための手助けにはあまりならないでしょう。しかし、クライアントなど他人と Web について話す時に適切な意思疎通を行うための言葉を知る事ができます。サウンド･オブ･ミュージックでマリアが「読み書きを ABC から始めるのとおなじで、歌はドレミの歌から始めるの」と言ったのと同じです。

今回は、コンピューター同士が HTTP や TCP/IP を通じて通信する仕組みを簡単に説明してから、Web ページを構成する技術について見ていきます。目次は次のとおりです。

インターネット上でコンピューターが行う通信
- リクエスト/レスポンスサイクルの詳細
コンテンツの種類
静的な Web サイト vs. 動的な Web サイト
まとめ
練習問題

インターネット上でコンピューターが行う通信

コンピューター関する技術は、幸いな事にシンプルに保たれてきました。World Wide Web について言えば、ほとんどのページが HTML という共通の言語で書かれていますし、これらは共通のプロトコルである HTTP (Hypertext Transfer Protocol) で配信されています。HTTP は共通語 (仕様) ですから、たとえば Windows マシンと最新の Linux マシンが通信することも可能なのです。

そして、Web ブラウザーという HTTP を解釈し HTML を人間に可読可能なかたちに整形してくれるソフトウェアのおかげで、HTML で書かれたページにはコンピューターからだけではなく、電話や PDA、さらには人気のゲーム機からもアクセスすることができるのです。

しかし、同じ言葉を話していたとしても、Web にアクセスするデバイスは多種多様ですから、お互いに通信するための何かしらのルールが必要です。学ぶために授業で手を挙げるようなものですね。インターネットにおいて、このルールが HTTP になるわけです。HTTP のおかげで、クライアントマシン (あなたのコンピューター) は、自身を「サーバーにサイトをリクエストするもの」と認識できるのです。

サーバーとは、Web サイトが存在するコンピューターになります。Web アドレスをブラウザーに打ち込むと、サーバーはそのリクエストを受け取り、要求されたページを見つけ出してあなたのコンピューターに送り返します。送り返されたデータは最終的にブラウザー上で表示されます。

リクエスト/レスポンスサイクルの詳細

さて、コンピューターがインターネット上でどのように通信するのかを説明したので、今度は HTTP のリクエスト/レスポンスの流れについてもうちょっと詳しく説明しましょう。いくつかの概念を効果的に説明したいので、ステップに分けて話しますね。

すべてのリクエスト/レスポンスは、Web ブラウザーのアドレスバーに URL (Univeral Resource Locator) を打ち込むすることから始まります。URL はたとえば http://dev.opera.com のようなものになります。ではここで、ちょっとこの URL を打ち込んでみてください。

さて、ここで一つ、あなたが知らないかもしれないことをお話します。実は、Web ブラウザーはサーバーに Web サイトをリクエストする際、URL を利用していないのです。ブラウザーは代わりに、IP アドレス (Internet Protocol) というものを利用します。IP アドレスは電話番号や郵便番号など、サーバーを識別するものになります。たとえば、先ほどの http://dev.opera.com の IP アドレスは 213.236.208.98 になります。
では、新しいタブかウインドウを開いて、http://www.apple.com と打ち込み Enter を押してください。次に http://17.149.160.10/ と打って Enter を押してみてください。同じページが現れるはずです。では、http://213.236.208.98 とタイプして Enter を押してください。この IP アドレスは先ほど紹介した、http://dev.opera.com と同じサーバーに接続します。ただし、あなたが見るのは 403 “Access Denied” というエラーでしょう。これは、サーバーの実際のルートへのアクセスが許可されていないことによるものです。

http://www.apple.com は基本的に http://17.149.160.10/ のエイリアスとして機能しています。しかし、一体なぜこのような仕組みがあり、またどのように機能しているのでしょうか？

まず、このような仕組みを導入する理由ですが、これは人間が数字の羅列を覚えるよりも、単語のほうが記憶しやすいということに基づいています。そして、これを実現する仕組みがDNS (Domain Name System) と呼ばれるものになります。DNS は言わば、インターネットに接続するマシンを自動的に収集する辞書になります。

あなたがアドレスバーに http://dev.opera.com と入力し Enter を押したとき、このアドレスはネームサーバーに送られ、対応する IP アドレスへの結びつけを行います。インターネットには膨大なマシンがあり、すべての DNS サーバーがオンラインのマシン全てを網羅しているわけではありません。ですから、あなたの要求をかなえるべく、リクエストを適切なサーバーに受け渡す仕組みが備わっています。

DNS システムは www.opera.com という Web サイトを探し、17.149.160.10 という対応するIPアドレスを見つけます。そして、その IP アドレスを Web ブラウザーに返すのです。

あなたのマシンは、指定された IP アドレスにあるマシンにリクエストを送信し、レスポンスが帰ってくるのを待ちます。すべてがうまくいけば、サーバーはページと共に、クライアントに全てが OK という短いメッセージを送信します (図1)。このメッセージは HTTP ヘッダーに格納されています。

図1: この通信には何も問題がないので、サーバーは適切なWebページを返します

もし何か間違いがあったとき、たとえばURLのタイプミスがある場合、Web ブラウザーは HTTP エラーを受け取ります。悪評高い 404 “Page Not Found” エラーはその最たる例です。
今度は http://dev.opera.com/joniscool.html とタイプしてください。実は、このページは存在しません。ですから404エラーが現れます。同じようにほかのサイトでも、存在しないであろうページにアクセスしてください。異なるエラーページが現れることがあると思います。これは、Web 開発者がサーバーが初期状態で持っているエラーページをそのまま利用したか、それともエラーページをカスタマイズしたかの違いです。これらは高度なテクニックですので、このコースでは取り上げませんが、dev.opera.com の他の記事で公開されればよいなと思っています。

さて、ほとんどの場合、Web サイトのトップページの URL にはファイル名がありません (例: http://www.mysite.com/)。トップページ以下のページでも、URL にファイル名があるものと無いものが存在します。しかし、URL にファイル名がなくても、あなたは実ファイルにアクセスしているのです。これは訪れる人が URL を覚えやすいようにと、Web 開発者がサーバーの設定を変更し、ファイル名を隠すようにしているのです。このやり方についてもコースで取り上げることはしませんが、サーバーにファイルをアップロードする方法や、ファイル/ディレクトリ構造の紹介についての記事が dev.opera.com で公開されています。

コンテンツの種類

今度はインターネットで見られるさまざまなコンテンツの種類について説明しようと思います。種類は大きく分けて4つ。プレーンテキスト、Web 標準、動的な Web ページ、そしてプラグインや他のアプリケーションを必要とするフォーマットになります。

プレーンテキスト

インターネットが始まった頃、つまり Web 標準やプラグインなどがまだ存在しなかった頃、インターネット上でやり取りされるデータは、画像と「.txt」といった拡張子を持つプレーンテキストファイルがほとんどでした。プレーンテキストはブラウザーで特に処理も行われず、そのまま表示されるだけです。こういったプレーンテキストファイルは、今でも大学の Web サイトなどで見つけることができます。

Web 標準

World Wide Web は、HTML (または XHTML)、CSS、JavaScript という3つの Web 標準によって組み立てられます (この記事では、HTML と XHTML が意味するものに大きな違いはありません)。

Hypertext Markup Language という名前は、その目的を簡潔に伝えている点でとても優れています。HTML は文書を分割し、構造と内容を記述し、そして各部分に意味を与えるために使われます (あなたが Web サイトで見るテキスト情報は、すべてこの HTML に含まれています)。HTML ではページ内の異なるコンポーネントを、要素を使って識別します。

Cascading Style Sheets によって、HTML 文書内の要素がどのように表示されるかが決定されます。CSS はとても簡単で、スタイル宣言を書くだけで、段落中の行間すべてをダブルスペースに (line-height: 2em;) することや、第2レベルの見出しをすべて緑色に (color: green;) することができます。

構造とその表示を分けることにはたくさんの利点があります。これについては次の記事で詳しく解説しますので、お楽しみに。

HTML と CSS を組み合わせることでどんな変化があるのかを、図2で表してみました。整形情報が全くない plain な HTML が左に、その HTML ファイルに CSS で整形したものが右になります。

Figure 2: プレーンなHTMLと、そのHTMLにCSSを付加した例

そして、JavaScript はあなたの Web サイトに動的な機能を付加します。JavaScript はクライアントのコンピューターで動作し、サーバーに特別なソフトウェアをインストールする必要がありません。しかし、基本的な機能とインタラクティビティは JavaScript によって実現できますが、それにも限界があるため、高度なことをするにはサーバーサイドで動作するプログラミング言語や、動的な Web ページを必要とします。

動的な Web ページ

インターネットをブラウズしているときに、「.html」という拡張子ではないページに出くわすことがあると思います。たぶん、「.php」や「.asp」「.aspx」「.jsp」といった、ふしぎな拡張子がついているものと思われます。これらが、動的 Web 技術を利用したページになります。

動的な Web ページは、ページに渡す値によって異なる結果が表示されます。データは、データベースやフォーム、その他のデータソースから渡されます。静的なページと動的なページの種類については、後で詳しく触れようと思います。

他のアプリケーションやプラグインを必要とするフォーマット

Web ブラウザーは、Web 標準のような特定の技術しか解釈し表示することができません。ですから、複雑なファイル形式やプラグインを必要とする技術を利用した Web ページに出くわすと、ブラウザーはファイルのダウンロードを行うか、インストールされたプラグインを利用してコンテンツを処理しようとします。次のようなコンテンツが例として挙げられます。

Word 文書、Excel ファイル、PDF、圧縮ファイル (ZIP、SITなど)、Photoshop PSD のような複雑な画像ファイル、その他理解できないファイルに出くわすと、Web ブラウザーはそのファイルをダウンロードするか、それとも実行するかをユーザーに尋ねます。どちらも同じような結果になりますが、後者の場合は一度ファイルをダウンロードしたあとで、実行可能なアプリケーションがクライアントにインストールされている場合にファイルを開きます。
Flash ムービー、MP3 に代表される音楽フォーマット、MPEG などのビデオフォーマットの場合、ブラウザーはインストールされているプラグインを利用してファイルを再生します。もしプラグインが用意されていない場合、ブラウザーはプラグインをインストールするページへのリンクを提示するか、ファイルをダウンロードし、実行可能なソフトウェアを探します。

もちろん、この両方に当てはまるようなものもあります。たとえば、SVG (Scalable Vector Graphics) は、Opera などいくつかのブラウザーでネイティブサポートが行われている Web 標準ですが、そうではないブラウザーもあります。たとえば、Internet Explorer は SVG をサポートしていないため、表示にはプラグインのインストールが必要です。しかし、多くのブラウザーはいくつかのプラグインをプリインストールしているため、あなたはそのコンテンツがプラグインで実行されているのか、それともブラウザーがネイティブでサポートしているのかが分からないかもしれません。

静的な Web サイト vs. 動的な Web サイト

「静的な Web サイト」「動的な Web サイト」とは一体なんでしょうか。そして、両者にはどのような違いがあるのでしょうか。

チョコレートのアソートと同じで、すべてはその中身にあります。静的な Web サイトは、HTML や画像などのコンテンツが常に静的であることを表します。つまり、管理者がサーバー上のファイルを変更しない限りは、誰に対しても常に同じコンテンツが提供されます。これはまさしく、私達がこの記事で見てきたことになります。

これに対して動的な Web サイトは、サーバー上のコンテンツは一緒ですが、HTML だけではなく動的なコードも含みます。これにより、利用者が Web サイトに提供するデータにあわせて表示が変わります。

ちょっと試してみましょう。www.amazon.com にアクセスして、違う製品を5つ検索しててください。出てくる結果は異なりますが、Amazon は異なるページを返しているわけではないのです。Amazon はユーザーに同じページを送信するのですが、その際に入力に応じた情報が動的に盛り込まれるのです。情報はデータベースに保存されており、リクエストに応じて適切な情報を取得します。Web サーバーはそのデータを得て、動的なページに挿入するという仕組みです。

もうひとつ付け加えたいのが、動的な Web サイトの構築には特別なソフトウェアをサーバーにインストールする必要があるということです。静的な HTML は「.html」という拡張子で保存されますが、動的な Web サイトのコンテンツには HTML のほかに動的なコードが含まれており、拡張子も特別なものになります。拡張子を変えることで、そのファイルはクライアントに提示される前にサーバー側で特別な処理されなければならないものであることを伝えるわけです。特別な処理とは、たとえばデータベースからデータを取得し、ページに埋め込むといったことが挙げられます。拡張子の例ですが、たとえば PHP ファイルには「.php」という拡張子がつけられています。

世の中にはさまざまな動的言語があります。いま挙げた PHP の他にも Python、Ruby on Rails、ASP.NET、Coldfusion といったものが有名です。これらの言語でできることにあまり違いはありません。どの言語でもデータベースへの接続や、フォーム入力の検証は行えるのです。しかし、言語によってそのやり方はすこしずつ異なっており、それぞれに長所や短所があります。ですから、最終的には何があなたに一番あっているかによるでしょう。

このコースでは動的言語についてこれ以上取り上げることはありませんが、いくつかのリソースを紹介しようと思います。気になった方は読んでみてください。

3番目にある PHP のマニュアルを除き、以下の書籍・Web サイトは英語で書かれています。

Rails: Fernandez, Obie. (2007), The Rails Way. Addison-Wesley Professional Ruby Series.
Rails screencasts
PHP: Powers, David (2006), PHP Solutions: Dynamic web development made easy, friends of ED.
PHP Online documentation
ASP.NET: Lorenz, Patrick. (2003). ASP.NET 2.0 Revealed. Apress.
ASP.NET: online ASP.NET documentation and tutorials.

まとめ

これで、インターネットの仕組みを紹介する舞台裏ツアーはおしまいです。この記事では、多くのトピックをちょっとずつ引っかいた程度ですが、各々の技術や概念がどう組み合わさって動いているのかをひとまとめに知ることができたのではないかと思います。

HTML、CSS、JavaScript の構文などにはまだ触れていませんが、これは次の記事で詳しく解説します。Web ページのコードを見ながら、HTML、CSS、JavaScript という、Web 開発における「標準的な」モデルについて学んでいきましょう。

練習問題

HTML と HTTP の定義と、それら二つの違いを説明しましょう。
Web ブラウザーの役割を説明しましょう。
インターネットを5分から10分程度散策し、記事内で説明したさまざまな種類のコンテンツを見つけましょう。プレーンテキストや画像、HTML、PHP や .NET (.aspx) のページ、PDF、Word 文書、Flash ムービーなどがその例です。コンテンツを見つけたらそれらにアクセスし、コンピューターがどのようにそれらのファイルを表示するかを考えてください。
静的なページと動的なページの違いはなんでしょうか。
HTTP エラーコードのリストを見つけ、その中から5つを選び説明しましょう。

著者紹介

Jonathan Lane はカナダのブリティッシュコロンビア州メーンアイランドにある Web 開発会社 Industry Interactive の President を務めています。彼はレスブリッジ大学の Curriculum Re-Development Center にて長年にわたり、Web プロジェクトの取りまとめを行っていました。

彼のブログは Flyingtroll になります。また、プロジェクト管理アプリケーション Basecamp をEメールから利用可能にするアプリケーション「Mailmanagr」の開発を行っています。

翻訳者について

矢倉眞隆 (Masataka Yakura)

1984年生まれ。株式会社ミツエーリンクスにて、社内の品質改善活動や Web 標準の普及啓蒙を行っている。W3C HTML WG メンバー。

株式会社ミツエーリンクス

1990年創業。大規模な Web サイト開発を得意とするインフォメーション・インテグレータ。自社コンテンツの Web 標準 Blog やアクセシビリティ Blog より、Web フロントエンド技術に関するさまざまな情報を発信中。

2: インターネットと Web の歴史、そして Web 標準の進化

2009-10-20T08:14:58Z

はじめに

どこから始めればよろしいでしょうか、陛下？

最初から始めよ。と、王様は重々しく口を開きます。最後まで続け、そこで止めよ。

―ルイス・キャロル『不思議の国のアリス』

全てのものには「はじまり」があります。ですから、このカリキュラムも歴史を紐解くことから始めましょう。この記事では、インターネットと World Wide Web、そしてこのコースのテーマであるWeb標準のはじまりについて簡単に紹介します。

この記事は、インターネットや Web がどのような出来事を通じ現在に至ったのかを理解するのにとても役立つと思います。文章も長くありませんから、情報に圧倒されることなく詳細にすばやくたどり着けるでしょう。

記事の中には、あなたの良く知らない単語が出てくるかもしれません。でも、そんなに心配しないでください。それが Web 開発を学ぶにあたって重要な概念であれば、後々の記事でその詳細を含めちゃんと説明してくれるはずです。もちろん、検索することだってできますし。

ただ、すでにインターネットや World Wide Web の歴史を知っているのであれば、どうぞ Web 標準のセクションから始めてください。記事は次のような構成になっています。

インターネットのはじまり
World Wide Web の創成
- ブラウザー戦争の勃発
Web 標準の到来
まとめ
関連資料
練習問題

インターネットのはじまり

1957年10月4日。この日、世界を変える出来事が起こりました。ソビエト連邦が史上初めて、地球軌道上に人工衛星を発射することに成功したのです。スプートニク1号と呼ばれたこの人工衛星は、世界中に衝撃を与えました。中でも、人工衛星の発射計画を進めていたアメリカ合衆国にとって、そのショックはとても大きなものでした。

この出来事は、アメリカ国防総省に高等研究計画局 (Advanced Research Projects Agency, ARPA) の設立をもたらしました。その時点での需要を越えた、より高等な概念や技術を研究・開発する機関の必要性が認められたからです。そして、ARPAで進められたプロジェクトのうち、おそらくもっとも有名なもの (そして、もっとも使われているであろうもの) が、インターネットなのです。

1960年に、心理学者でありコンピューターサイエンティストである Joseph Licklider は、人とコンピューターの共生 (Man-Computer Symbiosis)という論文を発表しました。この論文は、コンピューターネットワークによる先進的な情報の保管・検索を提供する概念を提唱したものでした。

ARPA で情報処理オフィスを率いる傍ら、Licklider は1962年にコンピューター研究を進めるグループを組織しました。しかし、実際に研究に取り掛かる前に、彼はグループを抜けてしまいました。

後に ARPANET と呼ばれるこのコンピューターネットワークの計画は、1967年の10月に提出されました。そして2年後の1969年12月に、最初のコンピューターネットワークが稼動しました。

ネットワークの構築にあたりもっとも大きな課題は、物理的に離れたネットワーク間で、リソースを圧迫することなく常時通信を行う仕組みを考え出すことでした。この問題を解決したのが、パケット交換と呼ばれる技術でした。パケット交換は、データリクエストをパケット (packets)と呼ばれる細かい単位に分割し、他のパーティとの通信を遮断することなくデータを高速に処理できる仕組みです。このパケット交換は、今日のインターネットでも利用されている概念です。

この考え方は広く採用され、結果として同じパケット交換技術を利用した異なるネットワークが出現することになりました。たとえば、国際電気通信連合 (ITU) によって開発されたX.25は、最初のイギリスの大学ネットワークである JANET を組織し、大学同士のファイルやEメールのやり取りを可能としました。また、アメリカの公共ネットワークである CompuServe も、X.25によって構築されました (CompuServe は営利企業ですが、小企業や個人を時分割制御のコンピューターリソースにアクセスすることを許可し、後にインターネットへのアクセスも許可していました)。これらのネットワークには多くの人が集いましたが、現在のインターネットと比べるとずっと閉じたものでした。

異なるネットワークプロトコルの激増はすぐに問題となりました。なぜなら、異なるネットワーク間で相互通信を行う際に、プロトコルの違いを乗り越える必要があったからです。しかし幸いにも、すぐにその解決策が生み出されました。ARPA で人工衛星のパケットネットワークプロジェクトに従事していた Robert Kahn が、当時の ARPANET で使われていたプロトコルを置き換える、より開かれたネットワークアーキテクチャの定義に乗り出していたのです。

後にスタンフォード大学の Vinton Cerf が加わり、ふたりはネットワークプロトコルの違いを覆い隠すシステムを新しい標準とともに開発しました。1974年12月に公開されたその仕様の草案には、Internet Transmission Control Program という名前がつけられていました。

この仕様は、ネットワークの役割を削減し、伝送品位の管理責任をホストコンピューターに移管するものでした。すなわち、ほぼ全てのネットワークを簡単に相互接続可能としたのです。ARPA はこのソフトウェア開発に投資し、1977年には3つの異なるネットワーク間での通信実験が成功しました。仕様はその後公開され、1981年の時点ではすでに幅広く利用されるようになっていました。

1982年には、アメリカ以外からの ARPANET 接続は、すべてこの新しい TCP/IP プロトコルに変換されるようになりました。私達の知るインターネットが、ついに到来したのです。

World Wide Web の創成

インターネット上の情報検索システムとして、Gopher というものが1990年代初頭に使われていました。Gopher は、ファイルへのリンクを含むメニューを提供する仕組みで、リンク先のファイルにはコンピューター上のリソースはもちろん、別のメニューを含むことができました。このメニューという概念により、コンピューターとインターネットの境界を越えて、他のシステム内のメニューを取得することができたのです。Gopher は、学内の情報を提供する手段を探していた大学や、文書の保管や管理を中央集権的に行いたいという大きな組織にとても人気でした。

さて、Gopher はミネソタ大学により作られたのですが、1993年2月に、彼らは Gopher サーバーの実装に対してライセンス料を取ると発表しました。その結果、多くの組織が Gopher の代替となる仕組みを探し始めることになりました。

そんな Gopher を代替しうる技術は、スイスの欧州原子核研究機構 (CERN) にありました。当時 CERN の研究員であった Tim Berners-Lee が、テキスト内のリンクを通じ文書から文書を渡ることのできる情報管理システムについて研究していたのです。彼は、この文書（ハイパーテキストと呼ばれていました）を公開するサーバーと、文書を読むためのソフトウェアを開発しました。そして、WorldWideWeb と名づけられたそのソフトウェアは、1991年に公開されました。しかし、その爆発的な普及と Gopher の置き換えが起こるまでには、まだ2つほど語らなければいけない出来事があります。

1993年4月13日、CERN は WorldWideWeb のソースコードをパブリックドメインとして公開しました。どういうことかというと、誰も料金を払う必要なくこのソフトウェアを利用でき、また開発できるようになったのです。

また同年、米国立スーパーコンピュータ応用研究所 (NCSA) が、Gopher クライアントと Web ブラウザーを合体させたプログラム、Mosaic をリリースしました。Mosaic は当初 Unix 端末のみの対応で、配布もソースコードのみでしたが、1993年12月に Apple Macintosh や Microsoft Windows でも動作する Mosaic がインストーラー付きでリリースされました。Mosaic はたちまち人気となり、それに連なり Web の人気も高まりました。

以降、Web ブラウザーの数は飛躍的に増加しました。ブラウザーの多くは、大学や企業による研究プロジェクトの成果として公開されたものでした。Opera もそのひとつで、ノルウェーの通信会社 Telenor が1994年に公開したものがはじまりです。

ブラウザー戦争の勃発

Web の認知は、商業的な関心ももたらしました。Mark Andreessen は NCSA を離れ、Jim Clark と共同で Mosaic Communications を設立 (後に Netscape Communications Corporation へと改称) し、後に Netscape Navigator と呼ばれる Web ブラウザーの開発に乗り出しました。Netscape Navigator のバージョン1.0は、1994年12月にリリースされました。

一方で、NCSA の営利部門である Spyglass Inc.は、Mosaic の技術を Microsoft にライセンス供与し、Micorsoft はそれを基に Internet Explorer を開発しました。Internet Explorer 1.0は、1995年8月にリリースされました。

すぐに、市場で優位に立つための競争が始まりました。Netscape と Microsoft は開発者を惹きつけるために、機能の拡張を行ったのです。これはブラウザー戦争と呼ばれました。一方 Opera はこの競争のなか、小さいながらも着実にその存在を維持し、Web 標準への対応や、Web 標準の発明を可能な限り行っていました。

Web 標準の到来

ブラウザー戦争のさなか、Microsoft と Netscape は新しい機能の実装に躍起になっており、既にサポートしている機能のバグを修正することを疎かにしていました。彼らはまた、プロプライエタリな機能の追加もたくさん行われました。さらには競争のために、他のブラウザーで実装されている機能を互換性のないやり方で実装することも行っていたのです。

当時の開発者は Web サイトを構築する際に、こんな混乱した状況に対処しなければいけなかったのです。二大ブラウザーに対応させるために、同じ内容の Web サイトを2つ構築することもありました。または、どちらかのブラウザーにだけ対応させ、もう一方のユーザーを蚊帳の外に置くといったことも起こりました。こんなひどい状況でしたから、開発者のうっぷんは堪りにたまっていました。

W3C の設立

1994年に、Tim Berners-Lee は CERN、DARPA (ARPA より改称)、欧州委員会の支援を受け、マサチューセッツ工科大学に World Wide Web Consortium (W3C) を設立しました。W3Cのミッションは、Web を構築する技術やプロトコルの標準化を行い、世界中の人に可能な限りWeb上の情報を提供することです。

設立してから数年で、W3C はいくつもの勧告と呼ばれる仕様を公開しました。HTML 4.0、PNG 画像フォーマット、CSS level 1、CSS level 2などが挙げられます。

しかし、W3C は勧告を強制するといったことを行う団体ではありません。なので、製造側は自分の製品をW3Cの仕様に準拠させたいときにだけ利用すればいいわけです。しかしながら、W3C の仕様に準拠することに、実質的な価値はありません。ほとんどのユーザーがW3Cを知りませんし、気にもしないからです。

ですから、このブラウザー戦争が落ち着くことはありませんでした。

Web Standards Project

1998年には、ブラウザー市場がすでに Internet Explorer 4と Netscape Navigator 4に支配されていました。そんな中、プロプライエタリな機能であるダイナミック HTML を実装した、Internet Explorer 5のベータ版が公開されたのです。これにより、Web 開発者は異なる JavaScript の書き方を、5つも学ばなければならなくなったのです。

このことが、数人の Web 開発者・デザイナーを立ち上がらせました。彼らは Web Standards Project (WaSP) と名乗り、W3C の仕様を「勧告」ではなく「標準」と呼びはじめたのです。そうすることで Microsoft や Netscape を説得し、仕様をサポートさせられるだろうと彼らは考えたのです。

活動への呼びかけは、roadblock と呼ばれる古くからある広告手法が使われました。Roadblock は、企業が広告を同じ時間にすべてのチャンネルで宣伝するもので、視聴者がチャンネルを変えても同じ広告を見てしまうというものでした。WaSP もこれに倣い、builder.com、Wired online など、Web 開発を対象としたサイトや多くの参加者がいるメーリングリストに向け、記事を同時に投稿したのです。

他にも、W3C (または他の標準化団体) に参加を考えている企業のうち、加入の目的であったはずの基本の理解ではなく、新しい機能の開発ばかりに目を取られてしまったものをひやかす事も行っていました。基本をおろそかにすることは、正しいスタートではないと考えていたからです。

あまり良い印象を持たないかもしれませんが、WaSP は何も批判だけしていたわけではありません。助けてもいたのです。たとえば、7人のメンバーは CSS Samurai を組織し、Opera や Internet Explorer の CSS サポートにおける、10の大きな問題を指摘しました（Opera はその後問題を修正しましたが、Internet Explorer が修正を行うことはありませんでした。）

Web 標準の高まり

2000年に、Microsoft は Macintosh 版の Internet Explorer 5をリリースしました。これは活気的な出来事でした。なぜなら、このバージョンはW3C勧告を充分な水準でサポートしており、また Mac OS のデフォルトブラウザーだったからです。Macintosh 版の Internet Explorer の Web 標準サポートは、Opera の優れた CSS、HTML サポートとともに、とても肯定的に受け入れられました。Web 開発者やデザイナーが、Web 標準によるデザインをはじめて心地よいと感じた瞬間だったのです。

そこで、WaSP は Netscape に、Netscape Navigator 5.0が Web 標準を充分にサポートするまでリリースを延期しようと Netscape を説得しました（そしてこの行動は、後に Firefox となる人気ブラウザーの誕生につながりました）。WaSP はまた、Dreamweaver Task Force という、Macromedia の Dreamweaver を Web 標準に準拠させるタスクフォースも設立しました。

2001年のはじめに、人気の Web 開発サイト A List Apart がリデザインされました。このリデザインについて、手法や理由を説明した記事が公開されているのですが、その中にこんな一節があります。

In six months, a year, or two years at most, all sites will be designed with these standards. […] We can watch our skills grow obsolete, or start learning standards-based techniques now.

訳: 半年か一年、いや二年後には全てのサイトが、これらの Web 標準を利用してデザインされるだろう。[…] いま私達にできることは、今までのやり方が古くなるのをただ見ているか、新しい Web 標準ベースな技術を学び始めるかのどちらかだ。

この予想はすこし前向きすぎました。2008年になっても、全てのサイトがWeb標準で作られている訳ではないからです。しかし、この言葉には多くの人が耳を傾けていました。古いブラウザーはシェアを落とし、そして Wired magazine と ESPN という二つの大きなサイトが、それぞれ2002年と2003年に、Web 標準によってリデザインされたのです。彼らは Web 標準や新しい技術を支持する第一人者となりました。

さらに、2003年に Dave Shea が CSS Zen Garden というサイトを公開しました。何よりも Web プロフェッショナルに大きな影響を与えたのが、このサイトでした。なぜなら、CSS Zen Garden は、中身が全く同じページでも、CSS ひとつでデザイン全て変更できることを端的に表現したからです。

それ以来、Web 標準は Web 開発コミュニティで当たり前の存在になりました。そしてこのコースは、Web 標準によるデザイン手法の基礎を知ることのできる、素晴らしい資料になっています。このコースを進めていけば大手サイトのように、きれいで、意味的で、アクセシブルで、そして Web 標準に準拠するWebサイトを作れるようになるのです。

まとめ

この記事では、宇宙開発競争が現在のインターネットを生み出したこと、Tim Berners-Lee が世代を超えたハイパーテキストを定義したこと、二つの企業が商業的な関心から、歴史に残る開発者の反発を生んだことを説明しました。Web 標準という言葉は Web プロフェッショナルの間で広く使われていますが、W3C の中でも使われています（彼らのページにもこの単語が出ていますね）。ですので、これが私達が教えること、つまり Web サイトを構築する標準的なやり方になります。

練習問題

もっと調べたいと思った方は、次の問題に答えてみましょう。

Windows、Mac OS X、Linux には、どんなブラウザーがありますか？
各ブラウザー利用者の割合はどのようになっていますか？
モバイル端末がWebにアクセスする際、どんなブラウザーを利用しますか？
W3C が公開した Web 標準の数はどれくらいになりますか？そして、ブラウザーベンダーによって広く実装されているものはどれですか？

著者紹介

Photo credit: Andy Budd.

Mark Norman Francis は Web の発明以前より、インターネットを利用していました。彼は Yahoo! で Front End Architect として、Web 開発におけるベストプラクティス、コーディング標準、そして品質の定義を世界的な規模で行った経験があります。

Yahoo! 以前の彼は、Formula One Management、Purple Interactive、City University にて Web 開発、バックエンド CGI プログラミング、システムアーキテクチャなど、さまざまな仕事を行っています。彼は http://marknormanfrancis.com/ にて、ブログのようなものを書いています。

翻訳者について

矢倉眞隆 (Masataka Yakura)

1984年生まれ。株式会社ミツエーリンクスにて、社内の品質改善活動や Web 標準の普及啓蒙を行っている。W3C HTML WG メンバー。

株式会社ミツエーリンクス

1: Web 標準カリキュラムの紹介

2009-10-20T03:06:07Z

はじめに

私には、ある夢がありました。

過去8、 9年にわたり、私は教育に関する仕事に力を注いでいました。あるときは技術書を執筆し、人がその技術で何かかっこいいものを作る手助けをしました。勤務先に新しく入ってきた人の訓練を行うこともありました。また、利用者の助けになるよう、Opera のソフトウェアについてチュートリアルの執筆・編集も行いました。

私は Web についても熱意をもっています。その中でも、オープン Web 標準というものをとても信じています。そして、Web をより良いものとするために私に何ができるのだろうと考えたとき、はじめに言った教育というトピックに立ち返るのです。

「教育」といっても、いろいろあるでしょう。他人を尊敬し、お互いが協力しあう方法を教えることかもしれません。あるいは、デバイスやプラットフォームを越えて機能し、また障害を持つ人に対してアクセシブルな Web サイトを作る方法を教えることかもしれません。このうち、Web 標準について当てはまるのは後者です。というわけで私は、今日そして将来の Web のために、Web標準を採用するサイトを増やす手助けに注力しようと決意しました。

決意してからしばらくの間は、思いが私の頭の中だけに留まっていましたが、Opera で働く機会を得ることで実現することができました。仕事として価値を見いだしてくれた Opera に、とても感謝しています！ついに、夢のひとつがかなったのです。

というわけで、この記事では過去数か月にわたる努力の結晶である Web 標準カリキュラムについて紹介したいと思います。このカリキュラムは、私を含めたくさんの方が執筆した、Web デザイン・Web 開発の土台となる知識を提供するコース資料です。カリキュラムはほぼすべての方を対象としています。お金は必要ありませんし、資料はアクセシブルです。また、事前知識も必要としません。

私はこのカリキュラムを大学で利用してほしいと考えています。なぜなら、Web標準に関する教育資料や指標は、多くの大学で不足しているからです。私は多くの学生から、彼らが Web 標準で作成した課題が減点されるという話を聞きました。これはなぜかというと、とても古い知識を基に採点が行われているからです。一方で、Web 関連の職種で募集をかける雇用者からは、面接を受けに来た学生が Web 開発の実情をまったく知らないといった嘆きも聞いています。

もしあなたが、望ましい方法でWeb標準を教える先進的な大学に居たら、ぜひ連絡してください。

さて、この記事は次のような構成になっています。

なぜ、Web 標準なのか？ — Web 標準を利用することの利点はもちろんのこと、一部で受け入れられていない現状とその理由、そして、このコースがどのように対処しようとしているのかを簡単に述べようと思います。
コースの構成 — 名前のとおり、コースがどのように構成されているのか、また教育担当者がどのように資料を利用すると効果的かを説明します。
このコースを利用すべき人は誰？ — 「誰もが (anyone)」と書くことがあるのですが、それが具体的にどういった意味なのかを説明します。
カリキュラムの目次 — 「おしゃべりはもう勘弁。早く学びたい。」という方はこちらをクリックしましょう。目次にスキップできます。
謝辞
連絡先

なぜ、Web 標準なのか？

Web 標準を Web デザイン / Web 開発に取り入れることは、どう素晴らしいのでしょうか。4番の記事に詳しく書かれていますが、ここでも簡単に説明しておくことにしましょう。

Web 標準を利用することで、次のような恩典が与えられます。

コーディングの効率化: このコースを進めていくと、Web標準に関するベストプラクティスの多くが、コードの再利用に関係していることに気づくと思います。ページの内容 (HTML) 、スタイル情報 (CSS) 、挙動に関する情報 (JavaScript) をそれぞれ分けることで、ファイルサイズを抑えることができ、また情報の再利用が同じコードを書くことなく実現できます。
管理の容易さ: 効率に関連するのですが、HTML をまず書き、あとで必要な部分にだけスタイルと挙動を class や関数を利用し与えるというやり方は、サイトの管理を容易にします。もしあとでスタイルや挙動を変更する必要が生じても、該当する一部分を編集するだけでWebサイト全体に反映されるからです。すべての HTML 文書をいちいち変更する必要はありません。
アクセシビリティ: Web における重要課題のひとつに、置かれている環境を問わず、すべての人に対し Web サイトをアクセシブルにするというものがあります。たとえば、視覚障害や運動障害 (手を自由に動かせないなど、運動機能に制限のある状態) を持つ方が、不自由なく Web サイトを利用できるようにすることが挙げられます。大変そうに感じるかもしれませんが、Web 標準とベストプラクティスに従うことで、余計な労力を割くことなく、多くの方に対してアクセシブルな Web サイトにすることが可能です。
デバイスの互換性: これは、Windows、Mac、Linux といったプラットフォームだけではなく、携帯電話やテレビ、ゲーム機など、別のブラウジングデバイスにおいてもWebサイトを機能させることを意図しています。これらのデバイスには、画面の大きさやプロセッサーの性能、操作手法に制限がありますが、これもアクセシビリティと同様に、Web 標準とベストプラクティスを利用することで多くのデバイスで機能する Web サイトにできるのです。いまや、携帯電話は PC よりも急速に普及しており、またそれらの多くがインターネットに接続できます。それなのに、このマーケットを見過ごすことを、あなたやあなたのクライアントが許すでしょうか？(モバイル Web 開発については、dev.opera.comに掲載されているモバイル関連の記事もご覧ください。)
Web クローラー/検索エンジン: いわゆる検索エンジン最適化 (SEO)と呼ばれるものです。ちょっと詳しく説明すると、Web を巡回しサイトをインデックスに登録する Web クローラーというものに対して、Web サイトを可能な限り可視化することで、Google や他の検索ランキングで上位になる方法を表します。SEO にはいろいろな術があるのですが (詳しくは Intelligent site structure for better SEO! や Semantic HTML and Search Engine Optimization などの SEO 関連記事をご覧ください)、これについても Web 標準を利用することで、Google や Yahoo! に対し Web サイトをより可視化することができ、ビジネスに良い影響をもたらすのです。

Web 標準にはこのような利点があります。しかし一方で、Web にあるサイトのほとんどが未だWeb標準に従ったものではありません。さらに、Web 開発者の多くもまた、時代遅れでかつ良くない手法を利用し続けているのです。

「どうして？」と思った方がいるかもしれません。でも、これにはいくつかの理由があるのです。不十分な教育、会社のポリシー、学ばなくても稼げることによる学習意欲の低下、Web 標準の難しさ、Web ブラウザーの Web 標準対応状況といったことを理由に、言い訳をする人がいるのです。

では、一つずつ詳しくその理由を考え、さらに反論してみましょう。Web 標準を学ばない/取り入れないことに言い訳ができないようにするのです。

不十分な教育: これがこのコースの存在理由でもありますね。多くの大学が、Web 関連のコースで Web 標準を教えることはありませんし、また多くのカリキュラムが、時代遅れな手法を今でも解説しています。変えようとしても、お役所的な手続きがありますからとても難しいのです。書籍やトレーニングなどもありますが、高くつきます。しかし、ちょっと待ってください。そのための Web 標準カリキュラムです。このコースは無料ですし、Web 標準の教育について大学などにプッシュも行っています。言い訳はできませんよ。
会社のポリシー: いくつかの企業や研究所のWebサイトが時代遅れなことについて、疑いの余地はありません。そういったところでは、職員に時代遅れのブラウザーの仕様を義務付けるポリシーがあるかもしれません。しかし、状況は改善されています。どのように Web サイトを作り変えていけばいいのかを説明するコースも無料で存在していますし、今こそ悪い習慣を改めるべきなのです。Web サイトを Web 標準というモダンなつくりにすることにより、古いブラウザーでは見栄えが悪くなることがあります。そうなると、内部で利用するブラウザーもアップグレードしようという動きがでてくるでしょう (もちろん、古いブラウザーでも新しい Web サイトは最低限機能しなければなりませんが)。また、企業は顧客に対してもブラウザーのアップグレードを進めるべきです。Web 標準なサイトにすることにより、検索結果のランク向上やアクセシビリティの確保、多様なデバイスに対応できるなど、ビジネスメリットもあります。それを無視するつもりでしょうか？
「勉強する必要なんてないから」: 「時代遅れなやり方でも給料はもらえているし、なんで新しいやり方に悩まされる必要があるんだい？」なんて言う人がいることを私は知っています。でも、先ほど説明したとおり、Web 標準によるやり方は効率がよく、また書くことも管理することも容易なのです。また、モダンなコードはアクセシブルですし、デバイスを限定することもありません。なんだか、わくわくしてきませんか？さらに、新しいことを学べば、自分のスキルセットをこれからのキャリアにも生かせるでしょうし、もっとお金を稼げるようになるかもしれません。それに今日の企業は、Web 標準のスキルがある人を要求しているんですよ。
「難しいんだよ」: まったくもう。ちょっとでいいので、コースを進めてみてください。Web 標準の基礎を習得することが難しくないことを理解できると思いますから。これは特定の人に限ったことではありません。Web デザイン / Web 開発の初心者であっても、またはスキルを磨くため新しく Web 標準を学ぼうとしている Web 開発者であっても、同じように感じるはずです。Web 標準は時代遅れなやり方と同じくらいの難易度ですし、そこまで難しいわけではありません。しかし、そのような古いやり方に比べて、多くの利点があるんです。
ブラウザーの Web 標準サポート: ブラウザーの Web 標準に関するサポートは、昔は本当にバラバラでした。ですから、Web サイトのクロスブラウザー対応は悪夢のようなものでした。しかし最近はそうでもありません。新しいブラウザーは充分に Web 標準をサポートしています。対応度合いの低い古いブラウザーに対してはまだ配慮が必要ですが、現在のベストプラクティスを使えば、古いブラウザーの利用者に対しても理にかなったユーザー体験を提供できるのです。

いかがでしょう。ご覧のとおり、Web 標準を取り入れないことへの言い訳はもう通じません。もしあなたが初心者であれば古いやり方を忘れる必要もないので、ペストプラクティスを最初から学べます。

「古いやり方」などとぼやかし、具体的な説明をしていませんね。私達は、このコースでそれらを説明することは考えていません。むしろ、そのようなことを知ることなく、ただ正しい道を歩めばいいと思っています。

しかしながら、一体全体なんのことを言っているのか、気になって仕方がない人もいるでしょう。というわけで、ここでざっくりと説明しましょう。

その昔、Web サイトは表 (table) を利用してページのレイアウトを行っていました。画像やテキストを別々のセルにあてがうという使い方ですが、これは表の適切な使い方ではありません。また、マークアップが過剰なものになってしまいます。レイアウト関連の手法にはスペーサー GIF と呼ばれる、透明な画像でページ内の要素を厳密に調整するものがありした。しかしこちらも表と同様に、画像の適切な使い方ではありませんし、画像を過剰に使うことになります。

JavaScript で動的なメニューを実現するページもありました。しかしこれは、JavaScript を無効にした環境では動作しませんし、スクリーンリーダーを利用する視覚障害者を混乱させてしまいます。また、特定のブラウザーでしか動かないといったことも起こります。

他にも、<font> タグを利用し、スタイル情報を HTML 文書内に直接埋め込むものもありました。管理性は最悪で、マークアップも過剰になります。

これはほんの一部で、他にも Web 開発にとって良くない手法がいっぱいあります。そして、何より残念なのが「その昔」と書いている一方で、これらの手法が未だ多くの人に使われていることなのです。

Web 開発というものは、どんなに良くても面倒なものです。しかし、これらの悪いやり方を使い続けても、事態は悪くなる一方です。ですから、このコースでも説明するとおり、Web 標準とベストプラクティスを利用することが、一番良い方法なのです。

コースの構成

このコースは、数多くの記事から構成されています。基本コースで50本以上の記事があり、各記事は数千ワードほどの長さになります。個々の記事は特定の内容について取り上げており、必要に応じて、その背景や重要な理論、実践的な例やチュートリアル、例題などが提供されます。

コースを教えるもっとも論理的な方法は、あなたの受け持つ講義の回数にあわせて、記事を割り振ることです。講義でカバーする内容は、事前に生徒に関連する記事を読ませ予習させます。そして講義では、記事中の実践的な例をひとつずつ見ていきます。講義の後は、復習として生徒に例題を解かせます。

事前に記事を読ませてさえいれば、ひとつの講義にかける時間は1時間程度で充分カバーできると考えています。ですから、コース全体にかかる講義の時間は50時間ほど、そして予習にかける時間も50時間ほどになるでしょう。

もちろん、講義にかけられる時間や何をカバーするのかなど、考えなければいけないこともあります。しかし、実践することが重要です。

このコースを利用すべき人は誰？

このカリキュラムは、数多くの記事から構成されるWeb標準に関するコース資料で、Web 標準なデザイン手法を一から学びたいという人を対象としています。

Web サイトをただ閲覧するくらいの人でも、資料を読めば CSS や HTML の知識を充分に持ち、加えて基本的な JavaScript を理解できることを目的に、このコースは作られています。それだけの知識があれば、就職や転職に自信をもって挑むことができるでしょうから (もっとも、経験について教えることはできませんが)。

で、具体的にどんな人なのでしょう？私はこのカリキュラムが、Web デザインの「よいやり方」を学びたいという人に役立ってほしいと思っています。たとえば、次のような人たちです。

大学やカレッジの生徒/教員: すでに書きましたが、このカリキュラムは独自のコース資料をつくるにも、コースの資料として一部を利用するにも理想的なものになっています。もしあなたが Web 関連のコースを受講している学生であれば、このカリキュラムを補足資料として使うべきです。そして、先生にもこの資料を使うよう働きかけてください！あなたが先生や講師である場合、講義で利用するテクニックがベストプラクティスであるかどうかを確かめる資料として、このカリキュラムを利用することをおすすめします。
高校生やもっと若い学生: このコースは大人の人を主な対象として書いていますが、それは別に、若い学生さんに恩恵がないというわけではありません。カリキュラムに目を通して、どのように進められるかを確かめてみてください。
Web デザイナーや開発者: Web 標準やベストプラクティスを利用していない人、手ごろなリファレンスを利用して知識を磨く人など、世の中にはさまざまなタイプの Web 開発者やデザイナーがいます。前者の方に対して私は、このカリキュラムをWeb標準が簡単で価値のあることを理解するチャンスとして授けたいと思います。後者の方には、このカリキュラムをさまざまなことに役立ててほしいと思っています。たとえば、人を助けたり、スキルを磨いたり、難しいことを思い出すためのリファレンスとして使うことができるでしょう。また、上司やクライアントに対して、アクセシビリティには価値があることを説得するための材料としても利用できるでしょう。
企業内の教育担当者: このカリキュラムは無料ですから、安価なトレーニング資料としてとても理想的です。
そのほかの方: もしあなたがちょっと Web デザインや Web 開発に興味を持っているのであれば、知見を広げるための資料として使ってくれたらと思っています。なんたって、このカリキュラムは無料ですし。

このコースにお金を払うことを、私は期待していません。このコースはクリエイティブ・コモンズ・ライセンスのもとで提供されており、適切な表示 (Attribution) さえあれば、だれもが自由に利用することができるようになっています。

Web標準カリキュラム：目次

はじめに

Web 標準カリキュラムの紹介 (Chris Mills 著) — 今あなたが読んでいる記事です。

翻訳のお知らせ: Web 標準カリキュラムの翻訳も行われています。

訳注: カリキュラムの原典は英語版になります。これはその日本語訳です。

Web 標準の世界へのいざない

インターネットと Web の歴史、そして Web 標準の進化 (Mark Norman Francis 著)
インターネットのしくみ (Jonathan Lane 著)
The Web standards model—HTML, CSS and JavaScript, by Jonathan Lane.
Beautiful dream, but what’s the reality?, by Jonathan Lane.

訳注: 以降の記事については、現在翻訳を行っている最中です。

Web デザインの基本理念

このセクションでは、コードやマークアップの詳細は扱いません。ここでは、画像の作成やコーディングの前に行うWebデザインプロセスについて、また、IA やナビゲーション、ユーザビリティなどの概念について紹介します。

Information Architecture—planning out a web site, by Jonathan Lane.
What does a good web page need?, by Mark Norman Francis.
Colour Theory, by Linda Goin.
Building up a site wireframe, by Linda Goin.
Colour schemes and design mockups, by Linda Goin.
Typography on the web, by Paul Haine.

HTML の基礎

The basics of HTML, by Mark Norman Francis.
The HTML <head> element, by Christian Heilmann.
Choosing the right doctype for your HTML documents, by Roger Johansson.

HTML の中身

Marking up textual content in HTML, by Mark Norman Francis.
HTML Lists, by Ben Buchanan.
Images in HTML, by Christian Heilmann.
HTML links—let’s build a web! by Christian Heilmann.
HTML Tables, by Jen Hanen.
HTML Forms—the basics, by Jen Hanen.
Lesser–known semantic elements, by Mark Norman Francis.
Generic containers—the div and span elements, by Mark Norman Francis.
Creating multiple pages with navigation menus, by Christian Heilmann.
Validating your HTML, by Mark Norman Francis.

アクセシビリティ

Accessibility basics, by Tom Hughes-Croucher.
Accessibility testing, by Benjamin Hawkes-Lewis.

補足記事

マイクロフォーマット

Introduction to hCard, by Christopher Schmitt
Introduction to hCard, Part two: Styling hCards, by Christopher Schmitt
XFN encoding, extraction, and visualizations, by Brian Suda
Styling XFN and rel-license links, by Christopher Schmitt
Styling hReview Microformats, by Christopher Schmitt
Microformat Encoding and Visualization, by Brian Suda

アクセシビリティに関する補足記事

Introduction to WAI-ARIA, by Gez Lemon
Creating accessible data tables, by Frank Palinkas
Building Accessible Static Navigation with CSS, by Frank Palinkas

そのほか

Getting your content online, by Craig Grannell.
More about the document <head>, by Chris Heilmann.
Supplementary: Common HTML entities used for typography, by Ben Henick.
The Opera Web Standards Curriculum glossary, by various authors. This is incomplete, and will be added to as time goes by.

謝辞

このコースの作成には、本当に多くの方の協力がありました。ここで紹介する方は、皆とても素晴らしい人達ですので、みなさん是非、彼らの講演を聞きに出かけたり、本を買ったり、ブログを読んだりなど、できる限りの応援をしていただけたらと思います。

彼らに、感謝と敬意をこめて。

著者: 記事の著者である Ben BuchananTom Hughes–Croucher, Mark Norman “Norm” Francis, Linda Goin, Paul Haine, Jen Hanen, Benjamin Hawkes–Lewis, Ben Henick, Christian Heilmann, Roger Johansson, Peter–Paul Koch, Jonathan Lane, Stuart Langridge, Robert Nyman, Tommy Olsson, Greg Schechter, Nicole Sullivan, Mike West, 本当にありがとうございます。あなた達がいなければ、このコースは存在していなかったでしょう。
Opera: Jan Standal, David Storey, 私のチームのみんな、そしてこの考えに賛同し、企画を進めてくれた Opera の従業員、どうもありがとうございます。
企業や組織: Yahoo (著者の方と、構成やプロモーションに多大な貢献をしてくれた Sophie Major), WaSP (特に Gareth Rushgrove, Stephanie Troeth と Aarron Walter), Britpack, Geekup のみなさん、そしてこのコースに興味をもち、また後押しをしてくれた大学など、多くの企業や組織の強力がありました。とても感謝しています。
貢献者: Craig Saila, Sara Dodd, John Allsopp, Roan Lavery, Bruce Lawson, Alan White といった素晴らしい人々に感謝しています。忘れている人がいたら、ごめんなさい。
読者のみなさん: よい Web サイトの作り方に興味を持ち、このコースを読んでくれた皆さんにも、もちろん感謝しています。

連絡先

より多くの人に対して有益なものとなるよう、私は常にこのコースを見直すようにしています。もしコースへの提案やコメント、どこかで使いたいという要望などあれば、ぜひ連絡してください。Eメールアドレスは cmills [at] opera [dot] com になります。また、全ての記事の下のほうには「この記事についてディスカッションする」というリンクがあり、そこからコメントを投稿することができます。なお、コメントには my.opera アカウントの取得が必要になります。

著者について

Chris Mills は Opera の Developer Relations Manager です。dev.opera.com や labs.opera.com で記事を編集・公開する傍ら、コミュニティに Opera の紹介やフィードバックの収集を行い、また Opera のソフトウェアの伝道師としても活躍しています。そして、このWeb標準カリキュラムの編集者兼オーガナイザーでもあります。

プライベートでは、彼はとても熱心な音楽ファンです。メタルやフォーク、パンク、エレクトロニカ、プログレをはじめさまざまな音楽を聴き、また演奏しています。彼のバンド Conquest of Steel もよろしくお願いします。

翻訳者について

矢倉眞隆 (Masataka Yakura)

1984年生まれ。株式会社ミツエーリンクスにて、社内の品質改善活動や Web 標準の普及啓蒙を行っている。W3C HTML WG メンバー。

株式会社ミツエーリンクス

Opera Desktop Widgets evolved

2009-10-15T12:30:53Z

Opera Unite developer’s primer — revisited

2009-10-14T06:01:41Z

Content contributions by Arve, Chris, Zi Bin and Lissy.

Introduction

Opera Unite features a Web server running inside the Opera browser, which allows you to do some amazing things. At the touch of a button, you can share images, documents, video, music, games, collaborative applications and all manner of other things with your friends and colleagues. We released an Opera Labs build containing an early version of the Opera Unite server a few months ago, and now we’ve released a beta version of Opera 10.10, featuring a much-improved Opera Unite.

This article gets you started on the road to Opera Unite application development — it describes how the Opera Unite server in Opera works and how it can be used. Below I will briefly recap some of the basic concepts related to Opera Unite, show how you can enable the Web server in your browser, and give an example of how to write a simple Opera Unite blog application.

The contents of this article are as follows:

Basic concepts
Enabling your Web server
Creating an Opera Unite Application: A simple blog
Using your Opera Unite application
Viewing your Opera Unite application
Uploading your Opera Unite application to unite.opera.com
Further reading

Basic concepts

In this section we’ll run through the basics of how Opera Unite works, and how Opera Unite applications are constructed.

What is Opera Unite?

Opera Unite is a Web server running inside the Opera Web browser, allowing the user to install applications and share these applications with their friends and colleagues (or everyone, if they wish). The Opera Unite server provides a proxy between the server and its clients (found at operaunite.com) to avoid the need for any special firewall configuration.

Opera Unite proxy

Traditionally when a user runs a Web server in a home network the network has a device that acts as a firewall, which needs to be configured separately, as illustrated in Figure 1.

Figure 1: A traditional Web server setup

Typically, the user will need to open ports and enable port forwarding to a local computer in order for people outside the firewall to be able to access the server.

However, when the user is using Opera Unite, no configuration is needed, as seen in Figure 2.

Figure 2: The set up when using the Opera Unite server in your browser

The Web server initiates a connection to the proxy, which uses this to pass information back about incoming requests.

Note that the proxy is really only a fallback mechanism to ensure that data can be delivered in case NAT traversal fails. Opera Unite has support for UPnP, which allows you to share your data using direct connections to your computer, if available. This can make loading speeds for your applications faster as they will bypass the proxy server. However, as it is up to each application to load content using the direct connection, it may not always run applications faster. UPnP has no authentication mechanism, and assumes that local systems and their users are completely trustworthy.

Opera Unite applications

Opera Unite applications have a config.xml file containing fundamental information about the application, and a fairly standard web site directory structure. In these respects they are very similar to Opera Widgets, although the way Opera Unite applications are run/used is very different to Opera Widgets. They also differ in other ways — unlike in Opera Widgets, Opera Unite config.xml files must also contain a feature element like this:

<feature name="http://xmlns.opera.com/webserver">
  <param name="type" value="service"/>
  <param name="servicepath" value="blog"/>
</feature>

In this case, a special JavaScript object — opera.io.webserver — becomes available to the application. See the Opera Unite Web Server JavaScript API for more information.

As the Opera Widgets technology is used, the Opera Unite application can provide the person running the Opera Unite server with a simple way of controlling and configuring it, all using standard HTML, CSS and JavaScript. Opera Unite applications do, however, get access to functionality normally not present in widgets or Web pages, for example a sandboxed file system.

For those of you who are interested in learning more about Opera Widgets, you can find more Widgets articles on dev.opera.

Let’s move on, get Opera Unite enabled, and start building up a simple Opera Unite application.

Enabling your Web server

For security and performance reasons, the Web server does not run by default when Opera is started. You enable the server by selecting Tools > Opera Unite Server > Enable Opera Unite, or by opening an Opera Unite application. When you do so, a dialog pops up asking you to specify a username and password. This is your My Opera username and password.

Note that only My Opera usernames containing valid URL characters will work with Opera Unite. Invalid characters include “/”, “.”, “_” and space.

In the next wizard screen, you need to define a device. You may select a device name from the drop-down list, or specify your own. The device name is used to identify your server via the proxy. It will be available via a URL like the following:

http://devicename.username.proxyaddress/applicationname

So, to visit the application test on the server your_device on operaunite.com, the URL becomes:

http://your_device.your_username.operaunite.com/test

Creating the Opera Unite application: A simple blog

Here is a short walk-through for creating a simple blogging application that allows the user to write blog entries. Once stored, the entries are immediately available to the world through the Opera Unite server.

The application has two parts: One is a configuration view for the application, where the owner can configure and control it. The other part is a series of Web pages generated or served by the application, which are visible to the user.

For those who just can’t wait, you can download the Opera Unite blog source code and start playing with it already. It is packaged with a .ua extension, the default extension for Opera Unite applications. You can unzip the package to look at the source code or drag the package into the Opera browser to fire up the Opera Unite blog example.

Files and folders in the application

The blog application will contain the files and folders shown in Figure 3:

Figure 3: The directory structure of the application

config.xml: Configuration file for the application.
index.html: Starting logic for the application, including scripts.
script/script.js: The actual Web server code.

Of these, only config.xml and index.html are required.

You may include a public_html folder, which is a magic folder in Opera Unite applications. Normally, files and folders inside your application are not available to users requesting your application, so if you want to distribute a separate stylesheet, static images and similar, those files go inside here. These files are mapped to the relative root of your application, so a file named cats.png inside the public_html folder of the helloOperaUnite application will be available at

http://your_device.your_username.operaunite.com/helloOperaUnite/cats.png

Configuring the application: config.xml

This application will be packaged in the same way as an Opera Widget, so we’ll need to define a config.xml file. The file is just like a normal Opera Widgets’ config.xml file, with a few extra details. In order to identify your application as an Opera Unite application, you need to add a feature element to the widget element in your config.xml file.

Please note that Opera Widgets are packaged as regular zip files and renamed to use the extension .wgt, whereas Opera Unite applications are packaged and renamed to use the extension .ua to denote “Unite Application”.

<widget>
  <widgetname>My blogging application</widgetname>
  <description>Blogging application example from the Opera Unite applications primer.</description>
  <author>
    <name>Hans S. Toemmerholt</name>
    <organisation>Opera Software ASA</organisation>
  </author>
  <feature name="http://xmlns.opera.com/webserver">
    <param name="type" value="service"/>
    <param name="servicepath" value="blog"/>
  </feature>
</widget>

The widgetname element of the application also acts as its application name. This is the name which will be shown to the user when installing and using the application.

You may also add a servicepath element to the config.xml file. The content of this element must be a valid part of a URI and defines what the name of your application will be in the URI of the application. If this element is not present, Opera will attempt to use the content of the widgetname element as the URI component. If this name is not valid as a URI component, the installation of the application will fail with an error message.

When the application is packaged and run, the above config.xml will make it respond to

http://your_device.your_username.operaunite.com/blog/

Tying it together: index.html

An application has no UI beyond the Web pages it produces. index.html is the starting point for the application, so that is the UI. In our example, we’ll use a minimal HTML 5 file with a reference to the script we’re using:

<!DOCTYPE html>
<script src="script/script.js"></script>

Creating the script: script.js

Note the link to the script file script.js in the above code snippet. The Web server listens to requests made from clients (users browsing the URL of the application) and creates responses that are sent back. The response is typically a generated Web page containing information.

The functionality in Opera Unite is exposed to developers through a set of JavaScript APIs, including objects representing the Web server, connections, incoming requests and outgoing responses.

What follows is a walk-through of the script.

The request event listeners

A Web server handles requests from clients and sends responses back to them. The Opera Unite Web server is event-based and will raise a DOM event in the application every time a Web browser makes a connection to the server asking for files related to the Opera Unite application. In order to respond to such events, we need to set up event listeners. This is done in window.onload:

var webserver;
var entries = [];

window.onload = function () {

    webserver = opera.io.webserver

    if (webserver)
    {
        //Handle requests for various URLs
        webserver.addEventListener('_index', showEntryList, false);
        webserver.addEventListener('entry', showEntry, false);
        webserver.addEventListener('form', showForm, false);
        webserver.addEventListener('save', saveEntry, false);
    }
}

What is going on here?

We are checking if the application is actually a web application, by checking for the webserver object. If it is present, we add four event listeners — _index, entry, form and save.

When these listeners are set up, the application will now call one of the functions each time a user visits one of the following URLs:

The _index request is special, and means a request to the root path of the application. Also note that, as we shall see, the user will not visit “save” directly — only through the form.

Showing a list of blog entries

The code for the _index request, the showEntryList function, is quite simple. When receiving a request, it writes back a HTML page with a list of the saved entries.

function showEntryList(e)
{
    var response = e.connection.response;
    response.write( '<!DOCTYPE html>'
        + '<html><head><title>Entries</title></head>'
        + '<body><ul>'
    );

    for ( var i = 0, entry; entry = entries; i++ )
    {
        response.write('<li>'+entry.date+': <a href="entry?id='+i+'">'+entry.title+'</a></li>');
    }

    response.write('</ul>'
      + '<p><a href="form">Add en entry</a></p>'
      + '</body></html>'
    );
    response.close();
}

Line-by-line, the script does the following:

It first gets a reference to the response object. This is the object that holds the methods necessary to send output back to the client:

var response = e.connection.response;

The write method then writes the content to the web browser that requested the page. First, we write a simple HTML shell:

response.write( '<!DOCTYPE html>'
    + '<html><head><title>Entries</title></head>'
    + '<body><ul>'
);

The existing blog entries are marked up as a list with links to the individual entries:

for ( var i = 0, entry; entry = entries; i++ )
{
    response.write('<li>'+entry.date+': <a href="entry?id='+i+'">'+entry.title+'</a></li>');
}

Finally, we close the connection.

response.close();

Showing a single entry

Next, we need to output something when the user clicks a link to an entry:

function showEntry(e)
{
    var index = e.connection.request.queryItems['id'][0];
    var entry = entries[index];
    //ToDo Should have error handling here
    var response = e.connection.response;
    response.write('<!DOCTYPE html>'
        + '<html><head><title>'+entry.title+'</title></head>'
        + '<body><h1>'+entry.title+'</h1>'
        + '<p>'+entry.date+'</p>'
        + '<div>'+entry.text+'</div>'
        + '</body></html>'
    );
    response.close();
}

Line-by-line, the script does the following:

It first gets a reference to the request object, which contains information about the incoming request:

var request = e.connection.request;

CGI GET arguments are stored in the queryItems property of the request. We get the id of the entry to display. Note that the the same CGI argument may have multiple values:

var index = request.queryItems['id'][0];

Next we get the corresponding blog entry:

var entry = entries[index];

The write method then writes the content to the web browser that requested the page. The title, date and text of the blog entry are wrapped in suitable markup:

response.write('<!DOCTYPE html>'
    + '<html><head><title>'+entry.title+'</title></head>'
    + '<body><h1>'+entry.title+'</h1>'
    + '<p>'+entry.date+'</p>'
    + '<div>'+entry.text+'</div>'
    + '</body></html>'
);

Showing the form for adding an entry

When you click the “Add an entry” link, a classic Web form is displayed:

function showForm(e)
{
    var response = e.connection.response;
    response.write('<!DOCTYPE html>'
        + '<html><head><title>Add entry</title></head>'
        + '<body><h1>Add entry</h1>'
        + '<form method="post" action="save">'
        + '<p><label for="namefield">Title</label> <input id="nameField" type="text" name="title"></p>'
        + '<p><label for="textArea">Text</label> <textarea id="textArea" name="text"></textarea></p>'
        + '<p><input type="submit" name="Add entry"></p>'
        + '</form>'
        + '</body></html>'
    );
    response.close();
}

This could be a lot more complicated, eg handling error messages, adding pre-populated values, input validation and so on. Ideally you should also offer some authentication scheme to guard against potentially destructive data operations, but we’ve kept it simple to highlight the Opera Unite knowledge.

Saving an entry

Finally, when you submit the form, a new entry should be saved. For now, entries are stored in a simple array so will be lost when the application is restarted, but it wouldn’t be so hard to extend the example to provide a means of retaining the blog entries.

function saveEntry(e)
{
    var request = e.connection.request
    var response = e.connection.response;

    //Get POST data
    var title = request.bodyItems['title'][0];
    var text = request.bodyItems['text'][0];

    entries.push({
        'title' : title, 
        'text'  : text,
        'date'  : new Date()
    });


    //Redirect back to the index of the application
    response.setStatusCode(302);
    response.setResponseHeader( 'Location', webserver.currentServicePath );
    response.close();
}

Instead of request.queryItems, we use the bodyItems property to access data sent by POST, in this case the title and the content of the new entry.

var title = request.bodyItems['title'][0];
var text = request.bodyItems['text'][0];

Submitting the form saves the entry, storing it in an array:

entries.push({
      'title' : title,
      'text'  : text,
      'date'  : new Date()
  });

Finally, when the entry is saved, we redirect back to the list of entries:

response.setStatusCode(302);
response.setResponseHeader( 'Location', webserver.currentServicePath );
response.close();

Here we create a standard HTTP temporary redirect back to the root of the application, represented by the webserver.currentServicePath property. This will fire an _index request, and the list of entries will then be shown.

Again, in a production-level you should add error handling and status messages to this.

Using your Opera Unite application

In order to get your Opera Unite application running, you simply need to load the application. Click and drag its config.xml file or a zipped version of the whole application into your browser window. Alternatively, open config.xml from a file dialog. If you have not previously started any Opera Unite applications, the Opera Unite configuration dialog will now appear.

Double click My blogging application in the Opera Unite applications pane and you should get a page appearing in the browser window, as seen in Figure 4:

Figure 4: The blog application main screen.

Clicking the Add an entry link will take you to a form that allows you to add a blog entry, as seen in Figure 5.

Figure 5: The form for entering a new blog post.

When you enter some text and press submit, you are taken back to the blog main screen and your blog entry is available to view. You can click on the blog entry title to view the post. Add a few blog entries, have a play around, and you should end up with something like Figure 6.

Figure 6: Our blog is now nicely populated.

Viewing your Opera Unite application

If you followed this guide and started the application in Opera, you should now have a functioning web application. Anyone can visit it by going to the URL

http://devicename.username.proxyaddress/applicationname

In this case, if the device is called your_device and it’s running the blog application, the URL becomes:

http://your_device.username.operaunite.com/blog

As you saw when running the example above, you can visit the root address of the device to see the installed applications on a system, for example:

http://your_device.username.operaunite.com/

This page will contain information on which applications are installed on the system, and if the information is found in config.xml, it will also list information on each application, including author, description, etc.

Uploading your Opera Unite application onto unite.opera.com

So now you’ve put together a cool Opera Unite application you not only want to let people use it via your Opera Unite server, you also want to make it available for others to download and install on their Opera Unite servers, right? So how do we do this? The answer is to upload them to unite.opera.com — this is the site where Opera Unite applications are distributed. This section will show you how.

Before publishing

Before publishing you should test your application to find bugs. Test on different platforms, devices and Opera browser versions if you can. Also remember that people using your applications can do so from any browser, not just Opera, so test your application’s pages in other browsers (Firefox, Safari, etc.).

If you are having trouble getting your application to work and you are convinced that the actual code of the application is right, check your config.xml file for errors. It needs to work for the application to be accepted. Opening the file in a different browser will check it for well-formedness. Check also that your config.xml file contains enough information. We will use this file to supply information about your application to unite.opera.com and to the Opera Unite application page on computers where the application is installed.

Also consider translating the application, if this is appropriate and you can do so.

Finally, take a screenshot of the application in action, as described below.

Publishing your application

To do this, you need to visit Opera’s Upload page. Select your application archive file in the archive file chooser dialog and upload it. Read through and verify the information taken from your config.xml file. Feel free to add more text if you wish.

Next up, select your screenshot in the screenshot file dialog box so that others will be able to see what your application looks like before they try it out.

You also need to select the target devices that your application is designed to be used with. Make sure you have tested it on those devices. Select a relevant group for your application. The last step is to select the target languages for your application. Make sure you have supplied translations for all the languages you select.

How can I get people to try my application?

When you have spent a lot of time making an application, you’ll naturally want people to try it out. To increase the number of views, use the application descriptions to tell potential users what to expect when running the application. Each application has a short description, automatically copied from your config.xml file, and a long description where you can provide more details and tips for use.

Use the short description to catch the user’s eye, stating what your application does and what value users can get out of it. It may be a tagline, but it should be informative. You should avoid phrases like “Download me” or “This is a super cool app” which are likely to turn users away. Use the long description to tell people what features your application has, how it was implemented, about changes in different versions, rules for games, and so on.

Finally, don’t forget to take a screenshot of your application in action. For inspiration, the Opera Unite team’s applications are a good place to start.

Note that you should ideally make your screenshots 445 x 230 pixels — this is the size we have been using on the Opera Unite web site. If you use different-sized screenshots they will be resized, which may lead to undesirable results.

Approval of Opera Unite applications

All applications need to be approved by Opera Software staff. We check for errors to ensure that our users have a good online experience, but we do not take responsibility for the content of the applications or make any guarantees about the functionality. See our disclaimer.

What are the guidelines for approval of an Opera Unite application?

These are some of the guidelines that apply to applications:

The application must have a sensible name and description.
The application must not have obvious bugs, so ensure that you test it before uploading.
The application must not contain malicious or destructive code.
The application must not contain or use copyrighted information for which you do not hold the rights.
The application must not contain or point to adult or hateful content.
The application should serve standards-compliant HTML pages that are viewable in all modern browsers on a variety of devices.

Yusef: the Unite Server Framework

2009-10-14T06:00:59Z

Content contributions by Mathieu Henri, Hans S. Tømmerholt and Gautam Chandna.

Introduction

This article gets you started with Opera Unite’s Server Framework: Yusef. After reading this article, you will be able to start harnessing the strength of Yusef. Included is a simple example to get things going.

If you have not read the Opera Unite developer primer, we encourage you to do so before starting with Yusef.

The article structure is as follows:

Basic Concepts
Yusef Core

Section
Action
Plugin

Example
Summary
Reference Materials

Basic Concepts

The Unite Server Framework — or Yusef — was started as a way to manage different functional requirements of Opera Unite applications. It was initially created by Opera’s Web Apps team to ease the development of Opera Unite applications. It soon evolved into a large framework covering multiple aspects of making an application.

For a developer, Yusef helps you take care of things such as providing a UI template, form POST validation and access control (amongst others). It evolved out of a need to modularize work in Opera Unite and is here to ease your work.

Figure 1: Yusef and an Opera Unite application page.

Think of Yusef as a daemon service that runs in the background, and your script as server-side JavaScript. After all that is processed, an HTML page is dumped, which is the Opera Unite application.

Yusef Core

Yusef Core provides the backbone of an Opera Unite application and deals with mount points, the sharing of static files, section listeners (the root or subpaths of the application), form actions (validated by means of a cryptographic nonce — a secure one-time random number used for authentication) and features some hooks to extend these basic functions and add plugins.

There are three main parts in the Yusef Core. Section and Actions are ways Yusef listens to events triggered by users in an Opera Unite application page, while Plugins introduce extra features such as access control.

Figure 2: The three fundamentals of the Yusef Core.

Section

Sections are the topmost subpath in which a request is made (ie http://device.user.opeaunite.com/application/section). Developers can add a section listener method to respond to requests made into a given top most subpath, or at the top _index level of the service. For example, a section listener might listen to the URL subpath and fire an event called showFileList when users view the page with a subpath showFileList — http://device.user.operaunite.com/application/showFileList. The event can then perform an action, such as showing a list of files.

addSectionListener is a Yusef method that listens to HTTP requests and registers them to a function. It allows Yusef to listen and perform actions when a page is loaded. The event is tied to a path (section), for example http://device.user.operaunite.com/application/sectionevent1/ can be tied to addSectionListener('sectionevent1', function(),args);

Yusef Core itself creates a section called static which serves all content located in the application’s public_html folder. This is used to serve static resources such as the icon, style sheets, scripts and graphics of the application.

Action

Unite actions are the way Yusef deals with a form POST. Developers can register an action listener to process the data posted by a form. The function registerUniteActionListener listens to POST requests and registers each of them to a specific function. Each POST request corresponds to a unique function.

For example, a form may submit data to the root of the application - http://device.user.operaunite.com/application/


 <input type="hidden" name="unite-action" value="<action name>">
 <input type="hidden" name="unite-nonce" value="<session.nonce>">

The form POST must include these two arguments which is needed by Yusef to validate and forward the entire request to your assigned actionListener. The cryptographic nonce is used for authentication.

Plugin

Yusef provides several plugins, amongst them are ACL and UI plugins. Developers who want to extend Yusef functionality can either create a new plugin or extend the public method of Yusef plugins.

We will be looking more closely at plugins in future articles.

Example

Before we dive into the code, let’s revisit a few ideas. Yusef is a server-side framework. Code written will be processed on the backend. The entry point of an Opera Unite application is a special index.html page, used to invoke Yusef and other server side functions and libraries. This index.html is not used to display a page but just to invoke scripts. You can think of the whole process as a daemon.

In this example, we want to start an Opera Unite application with Yusef as the framework. Download a Yusef Core example. The basic file structure is

index.html
config.xml
libraries/yusef
libraries/Markuper
libraries/PSO
serverScripts/helloYusef.js
templates/helloYusef.html
public_html/style.css

config.xml

config.xml is the descriptor of an Opera Unite application. It is where we tell users the application name and what this application is about. Opera Unite's config.xml structure is identical to the Opera Widgets config.xml specification.


<?xml version="1.0" encoding="utf-8"?>
<widget network="public" version="1.0" id="Unite/helloYusef/" >
<widgetname>Hello Yusef</widgetname>
<description>An example application that uses Yusef, access control and Markuper.</description>
        <feature name="http://xmlns.opera.com/webserver">
        
        
        </feature>
        <feature name="http://xmlns.opera.com/fileio">
        </feature>
<icon width='64' height='64' >public_html/favicon.64x64.png</icon>
        <icon width='48' height='48' >public_html/favicon.48x48.png</icon>
        <icon width='32' height='32' >public_html/favicon.32x32.png</icon>
<icon width='16' height='16' >public_html/favicon.16x16.png</icon>
<author>
<name>Gautam Chandna, Opera Software ASA</name>
</author>
</widget>

We are calling our application "Hello Yusef". It is mandatory to specify the Web server and File I/O needed in our Opera Unite application.

Including File I/O in the application descriptor might be counter intuitive for applications that don’t need File I/O. However, File I/O is required for access to a sandbox for application data.

index.html

The entry point of an Opera Unite application is index.html. Remember that this index.html is used to invoke libraries and Yusef, not to display content.


<script src="libraries/PSO/pso.js"></script>
<script src="libraries/Markuper/template.js"></script>
<script src="libraries/yusef/common.js"></script>
<script src="libraries/yusef/core.js"></script>

Core.js and common.js are both Yusef files. We are using Markuper as our UI template.

ServerScripts/HelloYusef.js

Opera Unite applications that use Yusef as the framework have a magic folder called serverScripts. Scripts in this folder are automatically invoked and all scripts related to the server side of your application can be placed in this folder.


    Yusef.addSectionListener
    (
        '_index',
        function( connection )
        {
          ...
        }
    );

Inside HelloYusef.js, Yusef functions are invoked. Member functions of Yusef are invoked through a Yusef singleton — a class/object that is instantiated once, hence Yusef is always the object name. For example addSectionListener function is invoked via Yusef.addSectionListener.

The addSectionListener listens to subpaths in a URI. For example, when accessing device.user.operaunite.com/addfile, the listener for addfile is fired. Here we have a listener listening to _index — which is fired when the top level URI of an Opera Unite application is accessed.


 function( connection )
        {
   var tmpl = new Markuper( 'templates/helloYusef.html' );
            var data = {
                title       : connection.request.path,
                servicePath : opera.io.webserver.currentServicePath,
                content     : "Hello Yusef",
                stylesheet  : 'style.css'
            }
            tmpl.parse( data );
            return tmpl.html();
}

Let’s look at the function that is invoked. The Markuper template library is called with the location of the template as an argument. An object notation variable data is instantiated with values. Among them is the servicePath identified using the opera.io.webserver object. For more information about opera.io.webserver, you can take a look at the Opera Unite API.

Finally, we explicitly parse the template in order to proceed with the data binding before returning the template.

templates/helloYusef.html

This is the final piece of the puzzle.


<!doctype html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    {{data.title}}
    <link
      rel="stylesheet"
      type="text/css"
      href="{{data.servicePath}}static/{{data.stylesheet}}">
  </head>
  <body>
    <div>
        {{data.content}}
    </div>
  </body>
</html>

The Markuper template library outputs the page templates/helloYusef.html, which is the page presented to your users.

A special syntax is used to retrieve the JavaScript value bound to the template. For example {{data.servicePath}} references the servicePath value previously specified in helloYusef.js.

Figure 3: Hello Yusef example.

There you have it. An Opera Unite application using the Yusef framework is created. You can download the source code of our helloYusef example.

Summary

In this article, we have introduced Yusef, Opera Unite’s Server Framework. There are three parts to Yusef, section (which listens to a URL subpath), action (which deals with form POST) and plugin.

You can slowly increase the complexity by adding more plugins. One such interesting plugin is the Yusef UI plugin that ties together Opera Unite’s UI templating engine called Markuper.

We will have a closer look at Yusef plugins in a future article.

Reference Materials

You might want to take a look at these other Opera Unite articles or libraries.

Adding meaning to your HTTP error pages!

2009-09-23T10:56:18Z

Introduction

When searching for something on the web we’ve all had the experience of clicking on a link in a search engine’s results page only to find that the page no longer exists. If there’s no information on that page other than a default error message, the most likely course of action on the user’s part is to press the back button and try the next search result.

As site authors we can make our error pages more meaningful to our users, so that an error becomes an opportunity to bring the user back into a site and show them content that’s relevant to what they’re looking for. In this article I’ll show you how to do just that.

The contents of this article are as follows:

Typical HTTP error codes
Creating a custom error page
Making a smarter error page
Advanced warning of problems
Pitfalls to avoid
Summary

Typical HTTP error codes

For the purpose of this article we’re going to focus on creating pages for handling the following HTTP status codes:

404: When a page is not found by your webserver it will serve a 404 NOT FOUND status in its response headers. Along with the status code, most webservers are configured by default to display a basic page providing limited details of the error. The language used in these pages is often not particularly informative and tends to be overly technical.
410: A 410 GONE status is similar to the 404 page, except that it’s saying that the content has been deliberately removed. For example, you should return this status if a news article had to be removed for legal reasons.
500: A 500 Server Error page is shown when the server has a serious problem. Typical causes of 500 errors would be misconfiguration of the web server or a fatal error in server-side code. This page should always be static, because — depending on the cause of the error — you cannot guarantee that execution of server-side scripting (such as calling separate include files or a redirection to another page) will be possible.

Creating a custom error page

On any site it’s a good idea to create a design for your error pages so that the error pages fit into the overall design. If you don’t configure custom error pages, users will only see the default error page for the particular web server or framework you are using.

Another good reason to override Apache’s default error pages is the fact that Internet Explorer displays its own internal error pages if the error page served is smaller than 512 bytes — and all of the default error messages are below this arbitrary threshold.

All that’s needed for a custom page is to create an HTML document for each error that you want to handle and then configure your webserver or framework to use them in place of their defaults.

For starters, any useful error page needs to provide a clear indication of what has happened, so that the user understands what went wrong. It’s best to avoid any technical jargon, as we want to avoid scaring users into reaching for the back button.

The default apache error document reads as follows:

Not Found

The requested URL /blah was not found on this server.

We as developers all know what a URL is, but would your granny? You should tailor the language of your error message to be understandable by your site’s audience, whether it is likely to be web geeks, or normal people.

An alternative version to this would be to use something a little more human, like this example used on google.com:

The page - www.google.com/dkjfhsd - does not exist.

Suggestions:

* Check the spelling of the address you typed
* If you are still having problems, please visit the Help Center

To get you started, here’s a simple example using Apache — don’t forget to make it look pretty. (If you’re lacking creative inspiration, Flickr can provide some ideas):

Create your markup (feel free to reuse my example)

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"   
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
  <title>Page Not Found</title>
</head>
<body>
  <h1>Page not found</h1>

  <p>The page you were trying to reach doesn’t exist. To continue on your journey please try one of the following:</p>

  <ol>                
    <li>
      <!-- You could display the request url here but as always be sure to escape it correctly -->
      <p>Please check the url (web address) is correct; does it contain any spelling errors or typos?</p>
      <p>If it does - please correct it in the address bar of your browser and hit enter</p>
    </li>
    <li>
      <!-- Provide a standard search box for your site -->
      <p>Try searching for the content you were looking for</p>
      <form  method="GET" action="/search/">
        <div><!-- Using a div here as we don’t want a fieldset and legend for a search box -->
          <input name="q" value="">
          <input type="submit" name="submit" value="Search">
        </div>
      </form>
    </li>
    <!-- if referrer is set you could set up a link to send them back to that  —  just be sure 
to not trust that data and make sure you’re not setting up a security hole in your site -->
    <li>Press the back button on your browser to return to the page you were previously on</li>
  </ol>
</body>
</html>

Save this page in the htdocs folder of your Apache server installation
Configure Apache to serve this page for 404 errors

The main configuration file is usually called httpd.conf or apache2.conf, depending on the version of Apache you’re using.
```
ErrorDocument 404 /srv/awesome.com/htdocs/404.html
```
If you place the error document inside the main configuration folder as instructed above, then it will be the error page for every site and virtualhost on your server. If you’d prefer to set up separate error pages for each virtualhost, you will need to place them inside the root folder of each virtualhost and specifically configure their individual ErrorDocument directives. For detailed information on virtualhosts setup, see the Apache vhosts Documentation.
Restart Apache.
- On most Linux systems — sudo /etc/init.d/apache2 restart
- On Mac OS X — sudo apachectl restart

There are a few caveats when configuring the ErrorDocument directive in Apache. If you specify a full URL for an error document, Apache will redirect the client to that location and the client will see the redirect status code rather than the original error page status code. This is something to be avoided as it’s extremely important to make sure error pages are served with the correct status code — not doing so can confuse search engine robots.

Making a smarter error page

So, if you follow the example above for all your different error codes, you’ll end up with a beautiful set of custom error pages that look a lot nicer than the defaults and that describe what the error really means to the user in a friendly way. Having done this, how can we make our error pages even better?

First let’s look at making our error pages smarter for our users. Say a site visitor has come to our site looking for a particular piece of information and has hit the 404 page - what can we do to retain them?

Search engine referrers

A referrer is a header sent by the browser which tells a server the previous site the user was visiting. Like any data sent by the browser, we can’t trust it completely - but it can still be used to attempt to deduce some information about where a user has come from.

Here’s an example of how to extract the keywords from a Google referral. An example google search URL looks like so:

http://www.google.co.uk/search?hl=en&q=barista+champion&btnG=Google+Search&meta=

Using an appropriate server-side function such as Python’s urlparse module we can extract the relevant parts of the the query string:

>>> import urlparse
>>> url = "http://www.google.co.uk/search?hl=en&q=barista+champion&btnG=
Google+Search&meta="
>>> url_parts = urlparse.urlparse(url)
>>> url_parts
('http', 'www.google.co.uk', '/search', '',
'hl=en&q=barista+champion&btnG=Google+Search&meta=', '')

Note that in Python 2.5 parse_qs is found in the cgi module, eg:

>>> from cgi import parse_qs
>>> query_parts = parse_qs(url_parts[5])
>>> query_parts
{'q': ['barista champion'], 'btnG': ['Google Search'], 'hl': ['en']}
>>> terms = query_parts.get('q', None) and query_parts['q'][0].split()
>>> terms
['barista', 'champion']

Also note that in Python 2.6 parse_qs is found in the urlparse module, eg:

>>> query_parts = urlparse.parse_qs(url_parts[4])
>>> query_parts
{'q': ['barista champion'], 'btnG': ['Google Search'], 'hl': ['en']}
>>> terms = query_parts.get('q', None) and query_parts['q'][0].split()
>>> terms
['barista', 'champion']

Last, note that in Python 3.0 The entire urlparse module is moving to urllib.parse; the 2to3.py script can update your code for you when you’re ready to move to Python 3.

If a user has come to our site from the results page of a search engine, we can look at the referrer and work out what search terms they had entered. We can then use those terms to search our site and provide a set of alternative content that matches those results. For instance, you could feed those terms into your own search function and surface some relevant pages that might be of interest.

A word on security

As with any other external source, it’s important to take care when making use of any data sent in a referrer, as you cannot trust this data — a referrer header can easily be forged. If you are displaying anything on your site based on the referrer, it’s important to ensure that it’s correctly escaped to avoid XSS vectors. If you are using referrer data to run queries against a database, you should also ensure that you correctly filter the data to avoid the possibility of an SQL injection attack.

Providing useful routes back into your site

If a visitor didn’t land on your error page from a search engine’s results page, you have less to go on in terms of knowing what the the user was looking for. But never fear — there’s still plenty of approaches that can be used to engage the user.

One possibility is to surface your site’s most popular content. For example, if you’re running an online shop then an obvious choice would be to provide links to the 10 most popular products on your site.

Another approach is to provide a search box for users to use to find something relevant. It’s still worth looking at the referrer header, as you may be able to use a similar approach to that of the search engine referrer, which is to break apart the referring URL to feed a search. This will probably only work if your site is designed with nice URLs, eg:

http://caffeineftw.com/news/2009-world-barista-championships

In this example, we can take the last part of the URL and split on the hyphen to get a nice set of search terms. We could also process out the stop words such as and and to, but this may not be necessary if our site’s search capability already takes care of that.

Here’s a very basic example of how we can break this down (again, in Python):

>>> url = 
'http://caffeineftw.com/news/2009-world-barista-championships'
>>> [ item for item in url.split('/') if item !="" ][-1].split('-')
['2009', 'world', 'barista', 'championships']

So in this case we could feed our search with the following keywords:

2009 world barista championships

and present links to some likely matches on our 404 page, so that the user will almost certainly be brought back into looking around the site.

Handling content removal

As briefly mentioned above, sometimes it’s necessary to explicitly remove content from a site, and a 410 GONE status should be served.

Ideally your content management system will not actually delete content when it’s removed, but retain it in its data store and only make it unreachable for outside users, Assuming that you can still access the original content behind the scenes, you can use that data and associated metadata in the 410 error page to once again feed a search or automatically find related content.

As an example, you might have published an article about a celebrity wedding, which has then had to be removed due to legal reasons. The URL has now become a 410 GONE error page, but your server-side code can still use its knowledge of what used to be displayed on that addess and feed a search with any stored tags or other metadata, so that you can at least provide a list of related content for the uses.

Bending the rules for SEO

Sometime it’s necessary to bend the rules and make what should be a 404/410 page a 200 OK. This is a technique used for SEO purposes when there’s lots of inbound links pointing a page that has been removed. In those special cases it can be useful to retain inbound traffic by essentially promoting a specialised error page in place of the previous content.

Pitfalls to avoid

Here’s a number of potential pitfalls to avoid when building smarter error pages.

Monitor error page resources carefully

If you’re adding searches fed by keywords extracted from referrers and historical metadata you want to keep a close eye on those pages, as delivering a smart error page will obviously use more resources than serving up a static page. To limit the resource hit, it’s worth thinking about caching search results for a limited time - that way, if you get a lot of errors in a short time due to a bad internal link, the load on the server is controlled.

Ensure the correct HTTP status code is served

A common mistake is to set up a custom error page, but to end up serving it with a 200 OK status code. This can be an issue if a search engine indexes your site, sees the 200 OK responses for what should be 404 or 410 error codes, and ends up indexing your actual error page. This will lead to listings for your company appearing with the error page content in the search results pages, instead of more meaningful content.

Another thing to avoid is redirecting to an error page. If something is wrong you really should be serving the correct status code at the exact URL that was requested, not changing the URL.

Set up redirects for URLs that have changed

In an ideal world all URLs would be permanent. However, in the real world there will always come a time where a URL has to be moved for some reason or another.

If a 404 error is occurring because you’ve moved a page to a different URL then the correct way to handle that is to issue a 301 Moved Permanently, which instructs the browser to seamlessly take the user to the content’s new location. This header also helps to get the new location indexed by search engines, and the outdate URL to be replaced in their database with the new one (maintaining any keyword and search ranking you may already have had for the old address).

Ideally, your content management tool should be automatically keeping track of pages you move and set up relevant 301 Moved Permanently redirect locations accordingly.

Avoid mystery timed redirects

At the time of writing the yahoo.com 404 page uses a meta-refresh to send users to their homepage after 10 seconds, but they also provide a search box on their 404! This means that you could be in the middle of typing a new search when you are redirected to the homepage without any prior warning — an annoying "feature" to avoid.

Summary

In this article we’ve covered ways to build smart error pages that are designed to guide the user back into the site by showing them relevant content when something goes wrong. Doing this attempts to engage your audience and maximises the time they spend on your site without having them navigate back to a search results page.

A developer’s look at Opera Mini 5 beta

2009-09-16T06:00:05Z

Introduction

This article introduces Opera Mini 5 Beta, our cutting-edge mobile Web browser. Like previous versions, Opera Mini 5 beta works on most modern phones — from top of the range smart phones to feature phones. In fact, it will run on almost any phone with a JVM, showing regular web pages designed for desktop browsers without any problem, and reducing file sizes to save you time and money. Opera Mini is incredibly popular, being used worldwide by over 30 million users. Read our State of the Mobile Web Report for more detailed coverage of the mobile web industry, including a breakdown of Opera usage on mobile in different countries, what sites are popular on mobile, and other analyses.

This article will briefly outline how Opera Mini 5 works and look at the new UI and features. Then we’ll have a look at the user agent string and Opera Mini 5’s standards support, and we’ll touch on the optimizations you can make to improve web page compatibility with Opera Mini 5 and mobile web browsers in general.

The table of contents is as follows:

Server-side rendering
Opera Mini 5 new features
Opera Mini 5 standards support
Identifying Opera Mini 5: The user agent string
Optimizing for mobile
Summary

Pick up your mobile phone and install the new Opera Mini 5 Beta, so you can play with it as you read through this article.

Server-side rendering

Opera Mini 5 is a thin-client application: when you use it to request a web page (1), that request is sent off to a server-farm (2); a proxy server receives the requested web page (3), renders and reformats it, and then converts it to a light and efficient format developed by Opera called OBML (4). This is then sent to the Opera Mini client (5), which displays it on the phone screen (6).

Figure 1: The Opera Mini request–response workflow.

As most of the complex processing is done on the server, Opera Mini 5 can run on relatively low-spec phones. In addition, the conversion to OBML can reduce the file size by up to 90%, meaning that, where bandwidth is at a premium, you can save a lot of time and money.

Note that, as all the processing is done on the server and what is to the client is a snapshot of the web page, some sites that feature heavy Ajax functionality or background scripting may not behave quite like you’d expect. However, most sites will function without a problem — you can find out more about Opera Mini 5’s standards support later on in the article.

Opera Mini 5 new features

Opera Mini 5 has a bold new look and many exciting features, and comes with support for both touch and non-touch screen phones. The new UI was designed by Opera’s fabulous designers — see Figure 2.

Figure 2: The Opera Mini 5 UI with Speed Dial and tabs.

As you can see, Opera Mini now features tabs as well as Speed Dial thumbnails. Note that in this beta release, Opera Link is disabled.

You can display pages using either regular desktop view, in which you can scroll around the page and zoom in and out, or in Mobile view, where the whole page is reformatted to a single column. The latter tends to work better for devices with narrow screens.

Opera Mini 5 standards support

Opera Mini 5 now uses the Opera Presto 2.2 rendering engine, bringing its display capabilities in line with Opera Mobile 9.7 beta and Opera 10 for desktop. This means that you can take advantage of the same standards support on Opera Mini 5 as on its desktop cousin, with a few small exceptions: HTML 5 Forms and Web Fonts are not supported, and the blur effect on text-shadows and SMIL animations are also disabled. The majority of JavaScript functions are available, except those that require asynchronous operations or user interaction once the page has been loaded. Note that plug-ins, such as Adobe Flash, are not supported.

The vast majority of readers will be familiar with common web standards usage, but we’ll still cover some of Opera Mini 5 beta’s more interesting supported features:

CSS 3 Media Queries. These allow you to dynamically optimize CSS layouts and styling depending on device attributes such as screen width and height. See the Media Queries section for an example.
CSS 3 colors: RGB(A) and HSL(A). Opera Mini 5 also now supports the RGB(A) and HSL(A) color models outlined in the CSS 3 Color Module. You can find more details about these color models in our Color in Opera 10 — HSL, RGB and Alpha Transparency article.

Have a look at our RGB(A)/HSL(A) example using Opera Mini 5. You’ll see a series of tables with individually-colored cells, to demonstrate the effect of iterative increases to the different channels in the two color models.
CSS 3 Selectors: Opera Mini has support for all the selectors listed in the CSS 3 Selectors Module. We have created a typical zebra-striped playlist table that makes use of the nth-child pseudo-selector and a CSS 3 attribute selector. Have a look at the source code to see what is going on. There are a number of Dev.Opera CSS articles that cover many of these selectors in detail, and you can find a lot more good information on CSS 3 selectors and other features at CSS3.info.
SVG: Opera Mini 5 supports SVG. You can try it out by loading this SVG based Opera logo in Opera Mini 5 beta.

You can find more details about standards support in Opera Presto 2.2 on the Web specifications supported in Opera Presto 2.2 page, and additional examples in our recently published Opera 10 article.

Identifying Opera Mini 5: The user agent string

A browser can be recognised by its user agent string. Opera Mini 5 identifies as Opera 9.8, with Opera Mini/5.x included in the parentheses. Its default user agent string is as follows:

Opera/9.80 (J2ME/MIDP; Opera Mini/5.0.2056/866; U; en) Presto/2.2

It is important to bear in mind that phone manufacturers and mobile carriers often customize their browser’s user agent strings, so sniffing for an exact match to any particular user agent string doesn’t always yield the desired results. The Opera Mini/5.x portion of the string should always be included, where x is the minor version number. Also note that in general, Opera can be identified by using JavaScript to test for the window.opera object.

We’d like to advise that, where possible, you shouldn’t test for browsers or features and serve different content. Instead, you can make your sites work well across a variety of devices and screen sizes using Web standards and Media Queries. The following section has more details.

Optimizing for mobile

In this section we will look at specific techniques and tips for optimizing pages for mobile viewing.

Media Queries

With all the devices of different shapes and sizes on the market, you can’t guarantee what screen size your web site will be viewed on – so design your layouts to be fluid and robust, and use Web Standards and Media Queries to dynamically optimize for different screen sizes.

Media Queries are a CSS 3 feature that allow you to specify under what conditions a style sheet should be applied. They are applied using the @media at-rule, a media type, and optional expressions that limit the scope of the style sheet. For instance, to limit a style sheet to only apply to a screen which is 480px or less, you could use the following Media Query:

@media screen and (max-device-width: 480px) {  
  // insert CSS rules here
}

After the @media declaration, you first list the media types that this block of rules applies to. After that you can optionally define a series of expressions which set further condition on when the rules should be applied. In the example we’re limiting the scope of the style rules with max-device-width – this tests the physical width of the screen. You can also use max-width, which on a desktop browser would test the width of the browser window, but on mobile browsers checks the width of the virtual viewport. A list of supported media features can be found in the Opera Presto 2.2 Media Queries spec. Media Queries are also supported by recent versions of WebKit and Gecko.

Let’s have a look at a Media Queries example, as seen in Figure 3.

Figure 3: Media Query example on desktop.

@media screen and (min-width: 480px) {
  .content p:before  {
    content: "You are now using the styling designed for screen. ";
    font-weight: bold;
  }
}

The Media Query works in the same way as described above, but tests for a minimum width, via the min-width media feature. If the condition is met, the rules inside the block are applied.

@media handheld, screen and (max-width: 480px),
       screen and (max-device-width: 480px)  {
  .content p:before  {
    content: "You are now using the styling designed for
              handhelds or devices with < 480px screens. ";
    font-weight: bold;
  }

  div.sidebar, div.content {
    width: auto;
    float: none;
    margin: 0;
    padding: 0.5em;
  }
}

The second Media Query includes three expressions. The CSS in this block is applied if any of these expressions are true:

The browser identifies itself as a handheld via the handheld media type. Opera Mini and Mobile ignore this unless they are switched to the Mobile View by the user.
The browser window width or virtual viewport is 480 pixels or less.
The screen width of the device is 480 pixels or less

To see the Media Query in action, view this example on Opera Mini 5, and try it on Opera 10 desktop and reduce the width of the browser window below 480 pixels - see Figure 4.

Figure 4: The Media Query example running on Opera Mini 5 beta, and on Opera 10 desktop with a narrow window width.

Other tips and caveats

Mobile devices in general have less memory and CPU speed than their desktop counterparts. Think carefully about how memory-intensive your web applications are, and optimize them as much as possible. Battery life is an important constraint on mobile, so avoid intensive use of JavaScript and especially XHR.
Make sure your site is usable both via keyboard and mouse. Mobile phones can come with spatial navigation, virtual mouse pointers and touch input, and your web application should work in all these scenarios.
Keep text entry to a minimum, as entering text is far more awkward on mobile than on desktop. For example, where possible, allow your users to select options from a list rather than entering them as free-form text.
In case you decide to create a separate mobile-specific version of your site, make sure that users can still easily reach the full desktop version and set it as their default via a cookie or profile preference.
As a final point, it is a good idea to test your site in a number of mobile browsers and devices, even if it is just to get some familiarity with the different contexts in which users view your site.

You can find more tips on designing for mobile browsers in our Introduction to the mobile web article.

Summary

We hope you’ve enjoyed this overview of Opera Mini 5 beta. We’ve taken you through its main new features and exciting new web standards support. As always, let us know how you like it!

Dev Opera Articles

4: Web 標準のモデル — HTML, CSS, JavaScript

Opera Mobile 10 beta developer’s introduction

Introduction

Opera Mobile 10 features

The Opera Mobile 10 beta user agent string

Optimizing for mobile

Viewport meta tag

Media Queries

Improved remote debugging with Opera Dragonfly

New standards support

Background-origin

Background-repeat

Word-wrap

Summary

3: インターネットのしくみ

はじめに

インターネット上でコンピューターが行う通信

リクエスト/レスポンスサイクルの詳細

コンテンツの種類

プレーンテキスト

Web 標準

動的な Web ページ

他のアプリケーションやプラグインを必要とするフォーマット

静的な Web サイト vs. 動的な Web サイト

まとめ

練習問題

著者紹介

翻訳者について

矢倉 眞隆 (Masataka Yakura)

株式会社 ミツエーリンクス

2: インターネットと Web の歴史、そして Web 標準の進化

はじめに

インターネットのはじまり

World Wide Web の創成

ブラウザー戦争の勃発

Web 標準の到来

W3C の設立

Web Standards Project

Web 標準の高まり

まとめ

関連資料

練習問題

著者紹介

翻訳者について

矢倉 眞隆 (Masataka Yakura)

株式会社 ミツエーリンクス

1: Web 標準カリキュラムの紹介

はじめに

なぜ、Web 標準なのか？

コースの構成

このコースを利用すべき人は誰？

Web標準カリキュラム：目次

はじめに

Web 標準の世界へのいざない

Web デザインの基本理念

HTML の基礎

HTML の中身

アクセシビリティ

CSS

CSS の上級コース

JavaScript の基本

モバイル Web 開発

補足記事

マイクロフォーマット

アクセシビリティに関する補足記事

そのほか

謝辞

連絡先

著者について

翻訳者について

矢倉 眞隆 (Masataka Yakura)

株式会社 ミツエーリンクス

Opera Desktop Widgets evolved

Opera Unite developer’s primer — revisited

Introduction

Basic concepts

What is Opera Unite?

Opera Unite proxy

Opera Unite applications

矢倉眞隆 (Masataka Yakura)

株式会社ミツエーリンクス

矢倉眞隆 (Masataka Yakura)

株式会社ミツエーリンクス

矢倉眞隆 (Masataka Yakura)

株式会社ミツエーリンクス