HTML5 | プログラマーズ雑記帳

「 HTML5 」タグ記事

HTML5 Please 読み方ガイド 2012-03-05
IE を実際のバージョンで動作させるサイト側の指定方法 2012-07-21
雑把の UI アーキテクチャー史(MVCからMVVMへ) 2013-02-28

HTML5 Please 読み方ガイド

HTML5 CSS3 ガイド web制作使い方

Web 制作などで、非常に役に立つ HTML5 Please というサイトがあります。
このサイトの紹介と、ぱっと見は何が書いてあるのかわかりづらいところもあるので、読み方ガイド的なものを書いてみました。
英語のサイトですが、用語の意味さえ分かっていれば、英語があまり分からなくても、ある程度使えるのではないかなと思います。

どんなサイト ?

"HTML5 Please" は「 HTML5 をどうぞ」とか「 HTML5 をどうぞ使ってください」ぐらいの意味でしょう。要するに HTML5 を薦めているサイトです。 HTML5, CSS3 といった新機能に対して、メジャーなブラウザ(IE, Firefox, Crome, Safari, Opera)の対応状況を元にその機能をもう使っていいのか、まだやめておいた方がいいのかといった情報がコンパクトにまとめてあります。

このサイトでは機能のリストの一覧が表示されています。
このリスト項目をクリックすると各機能の説明が表示されます。ただし、利用に関する説明で機能自体の説明は書かれていません。 あらかじめ使いたい機能があって、それが使っていいのかチェックする という使い方になると思います。

さらに説明内の [View browser share %] のリンクをクリックするとブラウザごとの対応状況の一覧も表示されます。

use, caution, avoid

まず、大きく use, caution, avoid で分けられます。
use, avoid はわかりやすいでしょう。ブラウザが対応しているので、使ってもいいというのが use で、未対応のブラウザが多いので、まだ使わないほうがいいというのが avoid です。

では、 caution は何だろうというと、使ってもいいけど、使うのには注意が必要 という機能です。
たとえば、 caution になっているものに box-shadow という機能があります。これはボックスに影を付ける機能で、このブログではサイドバーの各要素の囲みに使っています。
この機能の説明では、あまり大きな領域に対して使うとパフォーマンスが落ちるので、気をつけた方がいいですよという但し書きが付いています。

ただ、 use でも注意しておいた方がいい点もあります。
それは基準が各ブラウザの最新バージョンで対応済みであれば、 use になるということです。
Windows XP だと IE 8.0 までしかアップグレードできないので、まだシェアは高いと思いますが、 IE 8.0 で使えない機能も use で表示されます。

また、理由はよく分かりませんが、 IE 9 で対応済みとされている機能が実際には対応していないということも多いです。
たとえば、境界線の角を丸く表示する border-radius という機能があります。これはこのブログでもナビなどのボタンやサイドバーの各要素の囲みに使っているのですが、私の環境の IE 9 では丸く表示されていません。
先ほどの box-shadow も同様に IE 9 では機能していません。

追記 2012-7-21

IE が IE7 のレンダリングモードで動作してるのが原因でした。
IE9 で動作するように指定すれば、 border-radius, box-shadow ともにちゃんと機能するようになりました。

IE を実際のバージョンで動作させるサイト側の指定方法 | プログラマーズ雑記帳

polyfill, fallback

use や caution の後に with polyfill や with fallback がついているものがあります。この polyfill, fallback とはなんでしょうか。

polyfill

polyfill というのは web 関連の造語で、ブラウザがまだ対応していない機能を提供する JavaScript やアドオンなどを指しています。ある機能に対応していないブラウザがあったとしても、その機能を実現する polyfill があれば、すべてのメジャーブラウザで機能を使えるようになります。
例えば、<canvas> という html 上に図を描画する機能は IE 9 ではまだ対応していませんが、 polyfill を使えば、 IE でも canvas が使えます。

HTML5 Please ではお勧め polyfill もリンク付きで紹介されています。

polyfill なんていう便利なものがあるなら、ブラウザが対応していなくても、新しい機能をどんどん使っていけばいいやと思う方もいるかもしれません。
しかし、この polyfill は大抵 JavaScript で無理やり実現させたもので、スクリプトのロード時間もあり、ブラウザで対応されている方が処理速度は速いです。
実現しようとする機能によっては、 JavaScript でやろうとすると著しく時間がかかってしまうものもあります。実は caution で紹介した box-shadow にはもう一つ但し書きがあり、そこには box-shadow の polyfill は遅くなってしまうので、使わない方がいいよと書かれています。

fallback

fallback は日本語ではいざという時の予備品，代替物といった意味になります。
これが付いている機能はブラウザが対応していないときの備えをしてから、使おうということになります。

例えば、 fallback になっている機能に gradient という CSS の機能があります。これはグラデーションをかけて色を付けることが出来る機能で、このブログでは記事タイトルなどに使っています。

この機能はグラデーションのついた画像を背景に使うことで代用することが出来ます。ただし、画像の方が遅くなりますし、長くなって 2 行になった場合などではきれいに表示できません。
HTML5 Please では画像を使う方法や単一の背景色を指定することで、対応していないブラウザに備えておくことが推奨さています。

ちなみにサイトでは理由までは説明さていませんが、 gradient に関しては border-radius や box-shadow と違い、対応ブラウザの備えとして背景色の指定はやっておいた方がいいです。
というのも、 gradient に対応していないブラウザでは、背景色が描画されないためです。正確には、 <body> などのベースとなる要素の背景色になるのですが、背景色が期せずして使われると、情報を伝えるというところにも影響を与えることがあります。例えばその背景色が白で、文字色も白に近い色だった場合、コンテンツの内容が読めなくなってしまいます。

また、 gradient の説明にはベンダープレフィックスを付けるように薦められています。
ベンダープレフィックスというのは仕様の確定していない機能に対して、ブラウザごとの書き方をするものです。詳しくは以前の記事に書いたので、そちらを見てみて下さい。

ブラウザとレンダリングエンジン#ベンダープレフィックス

    background-color: #F5F5F5; /* 代用色 (gradient に対応していないとこの色になる) */
    background: linear-gradient(top, white, silver);
    background: -moz-linear-gradient(top, white, silver);
    background: -o-gradient(top, white, silver);
    background: -webkit-gradient(linear, left top, left bottom, from(white), to(silver));

polyfill か fallback か

未対応のブラウザがある機能を使う場合、 polyfill か fallback かということになります。 HTML5 Please ではこれはどのように選択されているのでしょうか。

この選択の説明の前にまず、最近 web 制作で主流になりつつある プログレッシブエンハンスメント という考え方について説明しておきます。
これは 高機能なブラウザではかっこよく、そうでなくてもそれなりに という考え方です。モダンなブラウザを使っている人には新しい技術を取り入れた高度な見せ方で提供して、そうでない場合でも、見え方はシンプルになるけど内容は損なわないようにしようということです。

クロスブラウザはもう古い！ HTML5 ＋ CSS3 時代のプログレッシブ・エンハンスメント - @IT

いままでに紹介した border-radius や box-shadow などは角を丸くしたり、影を付けたりするだけで機能していなくても、中身に影響はないので、どんどん使っていくべきです。
それに対して <canvas> といった新しいタグを使うと解析に失敗したりするなどして表示自体できなくなったり、内容を損なったりします。こういった場合は polyfill を使うか、まだ使用を避けるということになるでしょう。

HTML5 Please もこういった思想を元に作られているようです。
基本的に表示の装飾だけに関係するものは fallback になっていて、 機能しないと困るようなものは polyfill というようになっています。
また、 JavaScript で作られた polyfill だと処理速度がかかるので使わない方がいいという情報や、逆に fallback でもお勧めの polyfill がある場合には、その polyfill へのリンクが紹介されています。

フィルター

最後にフィルター機能について紹介したいと思います。
ページの上部にあるテキストボックスやリンクで表示内容をフィルタリングすることができるようになっています。テキストボックスのフィルターも便利なのですが、リンクも use だけ、 css だけといった感じでフィルタリングができ、知りたい情報をピックアップしてみることが出来ます。
中でも便利な 2 つのフィルターをあげておきます。

IE8+: まだシェアの広い IE 8 から対応している機能のみを表示します。
prefixes: CSS のベンダープレフィックスが必要な機能のフィルタリングです。

スポンサーサイト

IE を実際のバージョンで動作させるサイト側の指定方法

web制作 SNS ブラウザ HTML5 CSS3

タイトルがちょっとわかりづらいと思いますが、実は IE は実際のバージョンよりも古いバージョンで動作する ことがあります。これを本来のバージョンで動作させるようにサイト側から指定する方法の紹介です。

例えば、 IE9 を使っていたとしても、ページによっては、 IE7 としてレンダリングしてしまいます。
この場合、 HTML5 や CSS3 などの標準仕様で、 IE9 や IE8 から使えるようになった機能は対応しなくなります。

HTML5 Please 読み方ガイド | プログラマーズ雑記帳

特に困るのは Google+ などの SNS のシェアボタンで inline-block の機能を使っているものが勝手に改行されて、表示が乱れてしまうことです。
IE7 での表示

自分のページがどのバージョンのレンダリングモードになるかは、 IE で表示し、[F12] で IE の開発ツールを起動させると確認することができます。

IE7 で動作してしまう条件はいろいろあってややこしいです。ただ、実際の IE のバージョンでレンダリングさせるだけなら、以下を html のヘッダー部(<head>..</head>)内に記述すれば対応できます。

<meta http-equiv="X-UA-Compatible" content="IE=edge">

参考
- IE8 のレンダリングモードに関するまとめ ? SummerWind
- Google +1 ボタン改行させないようにするには

雑把の UI アーキテクチャー史(MVCからMVVMへ)

GUI比較 web制作 Rails JavaScript HTML5

今回は UI アーキテクチャーの歴史についてです。

もともとスライドだったのですが、説明を追加して、記事にしてみました。
最初は MVVM の簡単な説明のつもりでしたが、 MVC とその問題点を付けて、最近の UI 開発の傾向を書いて、とやっているうちに変に広がった内容になってます。

スライド版はこちらです。

ここからブログ版です。

MVC 以前

最初に MVC 以前の状態とともに UI アーキテクチャーにおける前提ついてお話します。

UI アーキテクチャーの大前提

MVC 以降いろいろな UI アーキテクチャーが登場しますが、共通している目的は アプリケーションのコア部分と UI 部分を分離する ということです。

これはかっこよく言うと、次のようになります。

ビジネスロジックとプレゼンテーションロジックを分割する

MVC 以前ではそれらを 1 つのオブジェクトにまとめる傾向があったらしいです。
MVC 自体は賛否両論あるかも知れませんが、そういった考えが広まり、 UI アーキテクチャーが注目されるきっかけとなったことは大きな意味があると思います。

もう一つ最初に伝えておくべきことは 完璧な UI アーキテクチャーはない ということです。

銀の弾丸などない という格言があります。
ソフトウェア開発では、魔法のように問題を解決するような技術は存在しないことを示唆する言葉です。これは UI アーキテクチャーでも同様です。

そのため、最後に出てきた UI アーキテクチャーでも決定版とはなりません。
問題がでてきて、新しいものが生まれるという繰り返しが今後も続いていくでしょう。

MVC と拡張 MVC

MVC (GoF 本)

MVC が広くつかわれるようになったのは、『 GoF 本』で紹介されたことが大きかったでしょう。
そこで、『 GoF 本』での MVC から始めることにします。

モジュール	説明
Model	アプリケーションオブジェクト、データ管理
View	画面の表現
Controller	ユーザー入力に対するインターフェース

もう少しわかりやすいように Wikipedia にあったシナリオをコラボレーション図風にしました。

今までの説明で MVC は理解できたでしょうか ?

Model 、 View の方はわりとわかりやすいと思います。
しかし、 Controller はわかりづらいです。ユーザー入力に対するインターフェースといわれても、 "View に入るんじゃないの ?" と思う人も多いでしょう。

また、ちゃんと理解できたとしても、"もっといい方法があるんじゃないか" と指摘したい点も多々あるんじゃないでしょうか。
例えば、私は Model から View へ矢印がでているのは、結合が密になりよくないと思います。

誤解されたり、改良されたりで、 MVC は人によって解釈が様々になってしまっているのが現状です。
MVC が何を指しているのか、はっきり言って正解はわかりません。

今度は、この変化していった Web、 PC での MVC について見ていきます。

MVC (Web)

Web サービスで広く使われている MVC フレームワークとして Ruby on Rails があります。これは次のようなアーキテクチャーです。

モジュール	説明
Model	DB へのアクセス
View	html ページと html ページの作成
Controller	入力の受け取り。他のモジュールの操作

Web の場合は View と Controller の違いははっきりしてます。
View は html ページとその作成を担当します。 CGI はアドレスとパラメーター(アドレスの ? の後など)を受け取り、処理を行います。その受け取り部分が Controller です。

Model と View ではなく、なぜ MVC としたのでしょうか ?

『 GoF 本』では Controller を分ける利点をいくつか挙げられています。

キーボードの応答を変えたり、メニューからの呼び出しに変更するとき、表示方法を変更しなくていい。
入力イベントを無視するといったことをコントローラーのインスタンスの入れ替えで可能。

その他にも "View を入れ替えれば、 PC アプリ、 Web アプリでも使えるように" という理由もあります。
ちょっと無理そうな話ですが、例えば、 PC アプリが次のような構成であれば、入れ替えて使うということができるかも知れません。

ただし、アプリが複雑化してくると、すぐ厳しくなってくるはずです。
やはり、これは欲張りすぎというものでしょう。

拡張 MVC (PC アプリ)

次に PC 上で動作するデスクトップアプリケーションの場合です。
この場合は、 Widget や Control といった GUI ツールキットが提供する部品を組み合わせて作成します。

高機能な部品になってくると、どうしても表示と入力処理を兼ね合わせるものになってしまいます。このため、 View と Controller の分離は不可能になってきます。

『 GoF 本』で指摘されている機能はほとんど GUI 部品の方で機能を持っていますし、普通は PC 向けだけに作るので、あまり Controller を分ける必要もありません。

そこで、でてきたのが V と C をまとめて View とする拡張 MVC です。 (拡張といいつつ、減っていますが...)
これは、コアと UI 分離という基本原則だけ残った形です。

拡張 MVC は GUI ツールキットによっては次のような呼ばれ方もします。

MFC : Document - View
Qt : Model - View

問題点

次のような状態でしばし落ち着きます。

対象	UI アーキテクチャー
PC	拡張 MVC (MV)
Web	MVC

ただし、拡張 MVC に問題がないわけではありません。
それは View の肥大化 です。

もともと大して分けてないので、プログラムの 8, 9 割が View というのも珍しくありません。
ちゃんと意識して作らないと、全部 View で MVC 以前に戻ることもありえます。
そこで、"なんとか分けなきゃ" となります。

一方、 Web は Web で Google の Web アプリのような高機能なものが求められ、 JavaScript が大規模化し、こちらも View の肥大化が起こります。

UI アーキテクチャーの乱立

問題点の解決ためにいろいろな UI アーキテクチャーが考案されます。

MVP - Model, View, Presenter
PM - プレゼンテーションモデル
アプリケーションモデル

これらのアーキテクチャーについては次のサイトで詳しく説明されています。

開発者が知っておくべき、 6 つの UI アーキテクチャ・パターン - ＠ IT

ただし、ここで MVC の拡大解釈が話を複雑にします。
例えば、 MVP の Presenter は簡単にいうと M と V の "つなぎ" の役割ですが、 Controller の名前でそのように使われることもあります。

また、こういった UI アーキテクチャーは GUI ツールキットなどで、フレームワークとして提供されないとなかなか定着しづらいものです。

ライブラリー、ツールキット、フレームワーク違いわかる? | プログラマーズ雑記帳

要望

新たな要望も出てきます。
これはデザインの重要性が高まりからきています。

Web サイトは大手企業などでは Web デザイナーが作成しています。それと同じように画面デザインもデザイナーに任せたいという要望です。

しかし、そのためには 画面レイアウトとコードを分離する必要が出てきます。
ただ、これは GUI ビルダーでも、昔から試行錯誤されているところなので、古くからの要求ともいえます。

画面レイアウト、コード分離の難点

GUI アプリケーションでは必然的にイベント駆動プログラミングとなります。
これが分離のネックです。

イベント駆動では呼び方はいろいろありますが、基本的に次のような仕組みです。

シグナル(イベント) → コールバック

ループで画面を表示
イベント発生(ボタンクリックなど)
コールバック関数が呼ばれ、処理を実行
ループに戻る

このボタンなどの部品とコード上で定義されたコールバック関数を結び付ける必要があります。

MVVM(.NET)

問題点の解決のため、 .NET では MVVM が使わるようになってきました。

.NET の登場

Win32API と MFC
Java の台頭
C#、.NET で対抗

1.
Windows での GUI のベースは C 用の Win32API です。
.NET 登場以前は VC++ では API をラップした MFC が使われていました。 C のラッパーなので、オブジェクト指向でできていないとか、 C++ でしか使えないといった批判がありました。

2.
そんな中 Java が出て来ました。
Java はガベージコレクションなどの機能で C++ よりも開発しやすく、しかもクロスプラットフォームです。
また、 Linux も gnome や KDE などで使いやすくなってきていました。
アプリケーション開発をみんな Java に移行され、そのアプリが OS を選ばずに動作するとなれば、開発ツールだけでなく、 Windows からユーザーをごっそり持っていかれる危険性が出てきます。

3.
そこで MS が対抗して出したのが C# と .NET です。
ただし、そこで最初に用意された Form は従来の部品を .NET 用にラップしたもので、ピュア .NET ではありませんでした。
『 6 つの UI アーキテクチャ・パターン』での紹介ではフォームとコントロールですが、これはまだ拡張 MVC のままといってもいいでしょう。

WPF

その後、.NET 用に作りなおされた GUI ツールキットとして登場したのが、 WPF です。

しかし、なかなか広まっていないのが現状です。
おそらく、原因は次のようなところでしょう。

Form の方が部品が多機能で豊富
- 従来の部品を使っているからこそ、今までの蓄積分があり、 WPF の部品が貧相に見えてしまいます。
使い方がわかりづらい
- WPF では VS で部品を配置した後、ハタと次どうすればいいかわからなくなってしまいます。 Form の方が使い方は想像しやすいです。
  また、使っている人が少ない → いいドキュメントも少ないということもあります。
長い間 MS 製品ですら使われなかった
- 「さぁ、使ってください」と出された WPF ですが、使う場合には「本当に実用に耐えうるの ? 」というのは気になるところです。
  そんな中、 MS 自身が自分のところの開発に使っていないとなると「大丈夫かこれ。」と思うのは当然でしょう。

MVVM の登場

WPF はなかなか使われません。しかし、だからといって Form のままでは問題点と要望が解決できません。

View の肥大化
画面レイアウトとコードの分離

ここで問題解決のための MVVM の登場となります。
流れとしては MVP → PM → MVVM といった感じです。

WPF のための MODEL-VIEW-VIEWMODEL (MVVM) デザインパターン # Model-View-ViewModel の進化

と、その前に採用されている技術を紹介しましょう。

データバインディング
コマンドパターン

データバインディング

今更ですが、データを扱う部分は Data や Core ではなく、何故 Model というのでしょうか ?

ここでの Model の意味はモデル化、モデリングといった時と同じで抽象化の意味です。
データは XML ファイルや DB などですが、これをプログラム内では扱いやすい構造体(オブジェクト)などに変換して使います。データそのものではなく、構造体などに抽象化しているところなので、 Model です。

デスクトップアプリでは、 Model 内でデータを構造体(オブジェクト)として直接管理することもありますが、多くはファイル、 DB から構造体(オブジェクト)に変換する必要があります。
この技術をデータバインディング といいます。
ただ、プログラミング言語にメタプログラミング(リフレクション)の機能が必要だったり、 C++ のようにそれがない言語では特殊な前処理が必要だったりとそうそう簡単にできるものでもありません。

設定画面でよくあるパターン

『 GoF 本』にでてくるようなパターンではありませんが、設定画面などでよく使われる手法があります。

それは画面の内容と構造体(オブジェクト)との相互に変換する機能を持たせることです。
デフォルト値があったり、部品の値がそのまま確定ではないモーダルなダイアログだったりする場合に向いています。

通常、この変換は自分で実装しないといけないのですが、 WPF ではこの実装を助ける機能があり、双方向データバインディングと呼ばれています。

これ、 Model で使われるものと似ていないでしょうか ?
画面(View)を構造体(オブジェクト)に変換することで、抽象化しています。 ViewModel の由来は View 用の Model というところからきています。

双方向データバインディングにより、 ViewModel のオブジェクトの値を変更すると画面が変更され、逆に画面を変更すると ViewModel の値が変わります。画面を抽象化した ViewModel としておくことで、プレゼンテーションロジックのテストがやりやすくなります。

コマンドパターン

こちらは『 GoF 本』にもでてくるパターンです。

要求をオブジェクトでカプセル化するパターンで、いろいろなところからの呼び出しに対応しやすくなります。

MVVM

MVVM は次のような構成です。

画面レイアウトとコードの分離

View

XAML : XML でレイアウト定義

ViewModel

データ: 双方向バインディングで同期 (大部分をこれで行う)
コマンド : 必要最小限のイベント駆動

View で画面の作成を行い、このレイアウト定義を XML に記述します。
これにより、画面デザインは Expression Blend などのデザインツールで行えるようになります。

パラメーター項目の設定などはデータバンディングを使い、 [OK] ボタンを押すといった必要最小限だけイベント駆動にします。
これにより、なるべくコードと分離しています。

View の分割

拡張 MVC (MV) における View の部分を View と ViewModel に分割することで肥大化を軽減しています。

ただ、 ViewModel がコマンドの管理だけならば、 Controller と区別しづらく、MVC に取り込まれていたかもしれません。
データバインドが MVVM の特徴です。

逆にデータバインドの機構がないと実装が大変なため、 MVVM は WPF 用の UI アーキテクチャー と言えます。

MVVM の実装

確かに MVVM は WPF 用の UI アーキテクチャーです。
しかし、注意していただきたいのは、 WPF は MVVM フレームワークではないということです。

これは次のようなことを意味します。

WPF で作れば MVVM になるわけではない
- MVVM のアーキテクチャーを崩さないよう意識して実装する必要がある
MVVM を実装するには毎回同じようなコードを書く必要がある

毎回同じようなコードを書くのは面倒なことです。そこで MVVM 用のライブラリー(フレームワーク)がいくつか存在します。
(『 MVVM 入門その４「ライブラリを使おう」言語: C# Visual Studio 2010 用』)

.NET 以外の傾向

.NET 以外にも、最近の傾向について触れておきます。

Web アプリケーション

問題のところで Web では JavaScript の部分が大規模化していると記述しました。
この解決策としては、 JavaScript の部分もフレームワークを使うというものがあります。

よく使われるフレームワークは Backbone.js、 AngularJS といったもので、 MVC が主流のようです。

2 段構えになってややこしいですが、 JavaScript はセキュリティ上、サーバー側のアクセスには制約があり、仕方ないところでしょう。
ただ、最近は Node.js などのサーバーサイド JavaScript もあり、コードを共有化して減らすといった工夫もできます。

また、 JavaScript には "スクリプトのわりに書きづらい"、 "大規模開発に向いていない" といった欠点があります。このため、変換系の新言語や Dart に移行するという流れもあります。

続々出てきた JavaScript 系新言語。どれを使う? | プログラマーズ雑記帳

MVVM にはデータバインディングが必要と書きましたが、実は Dart の UI パッケージにもデータバインディングの機能があります。
ただし、こちらは MDV(model-driven view) というアーキテクチャーを採用しているようです。

Web UI Package | Dart: Structured web apps

モバイル

スマホ、タブレットの出現により、今までの PC 、 Web に加え、 モバイルという分野ができてきました。

このモバイル用アプリは標準では次の言語で開発します。

OS	言語
iOS	Objective-C
Android	Java

しかし、 iOS 用のアプリを作ったら、次は Android 版もというのが自然な流れです。
当然、ソースコードはなるべく共通化したいでしょう。

そのため、いろいろな言語での開発環境が出てきています。注目されているのは、これだと思います。

HTML5 + JavaScript

JQuery Mobile や Titanium といったフレームワークがあります。

.NET 以外の PC アプリ

.NET 以外の PC アプリでも Mozilla の XUL、 Qt の QML のように画面レイアウト定義に XML が使われる傾向があります。
.NET と違うのは、これらは HTML のように JavaScript を使います。 JavaScript をにかわ(glue)言語として使う構成です。

対象	作成
画面レイアウト	XML
GUI 部品	GUI ツールキットが提供(C++)
アプリケーション全体	JavaScript
コア、スピードネック部分	C++

また、 GNOME でも GUI アプリは JavaScript を使うようになって来ています。

JavaScript が GNOME の第一言語になる

今後、どうなる ?

Web アプリでは同一のソースを PC ブラウザー、スマホ、タブレットのそれぞれの画面にあわせて表示する レスポンシブ Web デザインという技術が注目されています。
これはモバイルアプリでも必要な技術です。
HTML5 + JavaScriptで Web 、モバイルは統一化される傾向があり、実際 Titanium では、共通のソースで作成できるようです。

シェアはかなり小さいですが、 MS も Windows Phone というスマホ用の OS を出しています。
こちらの開発環境は PC 版から機能を削った SilverLight です。 SilverLight でも WPF と同様に MVVM が使えます。

Windows 8 のタッチパネル対応などもあり、 .NET では PC 、モバイルの統一化の傾向が見受けられます。

モバイルの Titanium から派生した TideSDK では HTML5 + JavaScript といった Web の技術で PC アプリを開発できます。

TideSDK | Create multi-platform desktop apps with HTML5, CSS3 and JavaScript

こうやってみてくると Web 、モバイル、 PC の開発が近づいてきているようです。
MVC の頃は PC と Web の共通化は無理と思ったものですが、 3 つの共通化が実現できる日がくるかも知れません。

日	月	火	水	木	金	土
-	-	-	-	-	1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

プログラマーズ雑記帳