HTML5 Conference 2012に行ってきた
2012/09/08 (土)にHTML5 Conference 2012があったので行ってきた。
参加したのは以下のセッション。（最後のスペシャルセッションは出なかった・・がUstreamで録画もされているので、見れなかったやつもあとで見ようと思う）
- 11:00 - 11:30 基調講演
- 11:45 - 12:30 HTML5マークアップ珍プレー集
- 14:00 - 14:45 HTML5時代のWebデザイン
- 15:00 - 15:45 Web最先端、エキスパートたちの視点から
- 16:00 - 16:45 パララックスでレスポンシブでjQuery Mobileなサイトのつくりかた
- 17:00 - 17:45 ブラウザを介した新しいリアルタイムコミュニケーション
以下メモってたやつとか。
基調講演
メモってなかった。
html5 マークアップ珍プレー集
最初は羽田野太巳さんのセッション。
雀百まで踊り忘れず
HTML5から入った人はしあわせね。HTML4.1とかXHTMLとかの人は色々引っかかるところがあるよ。
廃止された要素が幾つかあるよ
center, applet, acronym, bgsound
frame, frameset, font, marquee, ttなどなど
オーサー向けの仕様、ブラウザベンダー向けの仕様が一緒に書かれている
ブラウザベンダー向けには廃止要素も互換性確保のため実装しろよ
オーサー向けには廃止だからつかうなよと
仏作って魂入れず
図画
- <ｉｍｇ src="" alt="some alt">(こんなのはダメ)
- alt=代替、画像の代わりになるものを入れる
- 理想：読み上げされるときに、前後の文章と繋がるように書かれるべき。そこが画像だったことを、聞いている人に意識させないように。
- 仕様書にaltの膨大な説明がある。色々なシーンでの例がある
- HTML5 Outlinerというのがあって便利だよ
HTML5時代のWebデザイン
多くのブラウザに対応するにはどうすればいいか
機種ごとに仕様が違うとか、過去のバージョンの対応とか
必ずしもPCに向かっているわけではない
これまでとは状況が違う
- 閲覧環境の変化を意識する
- 様々な閲覧デバイス・利用シーンを考える
- 新しい技術の登場
Webの根本にあることを見直す
閲覧環境に左右されず、情報を取得できること
Webが本来持っている正確、それをもう一度改めて考える
だれでも、自分の環境でストレスなく見たい
もう一回デザイン手法考えたかを見直そう
- 所狭しと情報を並べることがいいこと？
- ランディングページはそれでいいの？
- デザイン性が高い？見た目が面白い？それだけでいい？
- パフォーマンスはでてるのか
- クライアントの望みを忠実に再現すればいいの？
パネルディスカッション
Web技術を介したブラウザやPC以外のデバイスとの連携
WeｂIntentが重要になってくる
これまでと違ったフィールドでWebが使われるときパフォーマンスや安定性が足りないので、
そのあたりの改善が必要とされてくる
カーナビや家電などWeb以外の業界が、Web技術の標準化に参入してくる
そのとき、これまでのWebのドライブ感などのメリットを殺さず、
どうやってうまくやっていくかが課題となる
例えば、ECMAの方にGoogleが提案をした時、
それを入れると組み込みの方から重くなるので入れたくないという要望がくる、とか
JavaScriptがもっといろんなところで使われるようになる
DLNAとの連携
レスポンシブでパララックスなWebデザイン
白石俊平さんが最近camobileのサイトを作った。そこでのノウハウとか。大変だったこととか。全部大変だったみたい。
http://www.camobile.com/:tilte
- レスポンシブ
- アプリケーション化
・パララックススクロールをモバイルでも実現したい
ライブラリがたくさんある
parallax scrolling tutorial で検索,
CSS background fixedだけでJSなしで出来るっぽい
→ モバイルで動くライブラリがない
NIKEのサイトは対応していたので、参考にした
githubで公開中
・レス音支部で動きまわるサイトを作らなくてはならない
Fluid Grid
幅を％指定
Fluid Image
画像の幅を％指定
なるべく大きな画像を用意してい幅を％指定でかえる
CSS Media Queries
LESS/SASSは必須
メディアクエリは控えめに。巨大なSwitch-caseみたいになる。すぐ肥大化する
メディアクエリ＝CSSの切り替え
単一のマークアップに異なるCSSをあてる
揺らがないマークアップが必要
状態変化を意識したコーディングをする
cssのプロパティを直接いじらず、
addClass, removeClassをベースにする
JavaScriptでCSSのプロパティをあまりいじらない。
→ 保守性が向上する（変更箇所がCSSに集約される）
・レスポンシブで画像満載のさいと
レスポンシブイメージ
異なるスクリーンサイズで異なるサイズの画像を読み込みたい
PC向けの画像をスマフォで読むとなるとパフォーマンスに影響するので問題
Riloadr
レスポンシブイメージを実現するフレームワーク
JSのセットアップをしたらマークアップをしていくだけ。
レスポンシブイメージも仕様が策定中。だが、喧嘩みたいな状態らしい
CSSスプライトアニメーション
Android2.3の標準ブラウザでは、すぷらいとの１枚目がずっと残り続けるバグがあるので、
１枚目は透明にした。
・jQuery mobileを使うべきかどうか
悩ましい。方にはめられてしまうので、自由度が。
フレームワークがかってにHTMLをいじってしまう
デザインにこだわるならカスタマイズが必須。
カスタマイズが面倒
遅い
なれれば簡単にページがさくさく作れる
マルチプラットフォーム
ページ分割・読み込みが用意
全ページが一意なURLを持つ（SEO的に完璧なページになる）
→ クリエイティブなページ以外ではどんどん使う
・定形タスクを自動化したい
JavaScript、CSSのミニファイ
ファイルの結合
LESSのコンパイル
異なるサイズの画像の生成
→ grunt.jsで定型化した作業
ブラウザを介した新しいリアルタイムミュニケーション（WebRTC)
色々笑いの絶えなかった、あんどうやすしさんのセッション。
RTC リアルタイムミュニケーション
ブラウザ上でやる
歴史
・Comet
サーバプッシュを実現する技術の総称
→ リアルタイムなアプリには不向き
・Server sent event
Web標準に従った正しいCometみたいな
→ サーバからPushするので、双方向ではない
・WebSocket
ウェブアプリからサーバ側プロセスと双方向通信できる
→ ウェブアプリ同士が双方向通信するものではない
WebRTC
リアルタイム
ウェブでの高品質、音声／ビデオなどが出来る
今のところ、音声／ビデオチャットを作るためのもの
マイク・かめらからマルチメディアストリームを取り込める
ローカルのストリームをリモートに送る
NAT越え
→ 今後任意のデータをリモートに送る（まだできてない）
getUserMedia カメラとかマイクとか取る
MediaStream ストリームをリモートに送ったり
取り込んだ映像は、CSSフィルターとかかけられるので面白い
PeerConnection
P2P接続
STUNでNAT越え
ICE STUNサーバからとってきたIP/ポートの情報をまとめて、
相手にOfferして／Answerを返すところの仕組み
SDP（プロトコル）でやり取り
key=valueの情報をやりとり
JSEP(Javascript session establish protocol)
onIceCandidateでSDPとラベルをなんとかして相手に送る
送信元ぴあからOfferを送信
受け取り側はOfferを受信、Answerを送信
Answerを受信して、セットして受信開始
Data Channel API
音声データのところになんでも渡せるようになる
まだつかえない
