正しくHTMLを書こうと心がけている人に5つの質問
der Gegenwartで面白そうな質問があったので回答してみます。
- HTML文書を制作する際に使用しているプログラムをお答えください。（Webプログラムも含む）
- 採用しているDTDとその理由をお答えください。
- 何故正しくHTMLを書いているのですか？
- W3CとWHATWG、どちらに期待してますか？
- あなたにとってHTMLとは何ですか？
HTML文書を制作する際に使用しているプログラムをお答えください。（Webプログラムも含む）
会社ではDreamWeaver、自宅ではemacsです。
個人でAdobe CS2のパッケージを持っているので、Adobe CS3が発売されたら自宅でもDreamWeaverになると思います。
HTMLもCSSもPHPも書けてO'reillyのリファレンスまで標準装備しているDreamWeaverって、本当に便利ですよねぇ。
採用しているDTDとその理由をお答えください。
会社ではHTML4.01 Strict、自宅では基本的にXHTML1.1 Strictです。
レガシーなブラウザに対応する必要が減り、ほぼ100%CSSでレイアウトを行えるようになったので、HTMLにはできるだけ文書構造のみを記述するようにしています。なので、Validatorで厳密に追い込めるStrictが好きです。
何故正しくHTMLを書いているのですか？
そういうものだから。つか、inValidなHTMLを書く理由が分からない。
IEとかfirefoxで表示できればいい、というのであれば誰でも書けます。
あいまいなHTMLでもブラウザが頑張って解釈して表示してくれたからこそ今のインターネットの発展があるので、そういう大らかな文化はあっても良いと思います。しかし、仕事として書くのであれば、少なくとも自分が書いたコードを胸を張って言えるだけの事をすべきだと思います。
あと、綺麗な構造にしておくと、あとでいろいろ使い回せるという汎用性を持たせられるというのもありますね。
W3CとWHATWG、どちらに期待してますか？
W3Cかなぁ。どちらかといえば、W3CよりもWCAG2とXHTML2に期待しています。まあ、WHATWGって今知ったのでWHATWGを知らないってのもありますが。
あなたにとってHTMLとは何ですか？
文書を構造化する言語。YAMLやJSONを見ると冗長にも見えてしまいますが、業界内の共通言語として今後も使われていくことでしょう。section要素が使えるようになれば、見出し要素と文章が紐付けられていいですね。
最近は、正しくHTMLを書くというよりは正しく書いて当然と思っています。ただ、「正しい」が単にValidであるか妥当な文書構造を意識できているかは、まだ作業時間とモチベーションに左右される程度のスキルなので、もっと精進しなければいけないと思う今日こと頃であります。
070417
少し修正しました。
ゲーム機とwebブラウザのインターフェースの違いについて考えてみる
既知の事ではありますが、文書に起こしてみると今後の考察に役立つかもしれないのでメモ。
今まで、テレビと親和性の高いインタラクションなインターフェースを持った機器といえば、PS2やN64などのゲーム機でした。
ゲーム機のインタフェースを言えば、代表的な形としては十字キーと４つボタンのコントローラーです。それに、スタート/オプションキー、LRキー、アナログスティックなどがサブ的な要素で付いていました。
これで、ゲーム上の操作をすべてまかなうため、一つの操作を一つのキーに割り当ててしまうと、多少ゲームが複雑になっただけでボタンが足りなくなってしまいます。
そのため、必然的にモードによる操作切り替えが行われるようになっていったのではないかと推測します。
例えばRPGでのAボタンは、マップ移行時には「その場を調べる」、戦闘時には「アクションを決定する」、イベント時には「ページ送りをする」と言った具合に。
翻って、PCのwebブラウザは元々ハイパーテキストを表示したり読んだりするために作られたものなので、テキストをスクロールするためのキー操作と、ハイパーリンクから別のテキストにリンクするためのキー操作やマウス操作をサポートしています。
そのため、どのようなページでもどのようなリンクであってもテキストリンクであってもマウスのクリックは「ハイパーリンクする」という、単一の動作が割り当てられていると見なすことができます。
よって、Wiiのようなゲーム機で、Wiiらしい(ゲームらしい?)コンテンツとしてwebコンテンツを見せるのであれば、モード的な操作を取り入れると、よりそれっぽくなるのではないでしょうか。
webコンテンツでモード的な操作って何だよ、と言われても困るのですが…。
prototype.jsのLightboxや、ダイアログボックスなどがモード的な操作に当たるのかな？
テレビで見るwebコンテンツのベストな見せ方は？
Wii用のOpera試用版がリリースされてから、この手の話がでるようになりましたね。よいことです。うん。
この方は結論として「主要なコンテンツは画面の中央におくべき」と結論付けています。
それは至極まっとうな意見だと思います。
しかし、それ以外にも何箇所が気をつけると、もっと整理しやすくなるのではないでしょうか？
テキストの扱い
「コンテンツ」には何が入るのでしょうか？ 動画？ 画像？ 音声？
webのコンテンツであれば、圧倒的にテキストが多いでしょう。統計とっていないけど。
英語や日本語のテキストは通常左から右に書かれます。
1〜2行のテキストであれば、中央寄せにして画面中央に配置で問題ありませんが、それ以上の分量を読ませようとした場合、圧倒的に左寄せにした方が読みやすいです。
この場合、問題になるのは、配置位置ではなく、1画面あたりの文章量や文字サイズの方でしょう。
「主要な」コンテンツとは？
用途やコンテキストによって、大きく変わるのではないでしょうか？
Wiitubeのような動画を見せるサービスであれば、動画がメインのコンテンツです。
一方、ショッピングのサービスであれば、商品選択時は「ショッピングアイテム」、送り先入力時であれば「テキストフィールド」、購入決定時であれば「購入|はい|決定」といった意思確認ボタンが、メインコンテンツとなります。
そのため、モーダルダイアログやドリルダウン形式の構成、あるいはハブ&スポークのアプリケーション構成といった、どちらかといえばゲームで取り入れているコンテンツとナビゲーションの設計も考えたほうがいいでしょう。
テレビというメディアの特性は？
テレビは動画をプッシュするメディアです。
そのため、地上波などの放送番組は、画面構成としては基本的にはフルスクリーンで1コンテンツです。
補足情報として時報や字幕スーパーが入る場合もありますが、画面の隅に1〜2個、最近の過剰な演出でも3個が最大でしょう。
これは動画そのものの情報量が多いため、複数の項目を並列に見せたとしても、視聴者が受け取れ切れないからだと考えます。
そのため、webコンテンツを放送番組に近づけて見せるのであれば、画面配置だけではなく、自動ページ送りやスライドショーなどの時系列をもった見せ方などで、よりプッシュ型のメディアとして見せる事も考慮したほうがいいでしょう。
と、つらつら書いてみましたが、最近インターフェースの本を読んだのでただ単にそれを披露したかっただけでもあります。
オライリー・ジャパン (2007/01)
売り上げランキング: 2276
僕のような美大上がりのweb屋は、とにかく論理的な思考が苦手なので、この本のような体系だったインターフェースの考え方は非常に勉強になります。本当は社会に出る前に勉強できるのがベストですが。
余談になりますが、昔、地方のテレビ局で文字スーパー打ちのバイトをしていた頃、地方ニュースのタイトル(「○○市で震度3の地震」、のようなアナウンサーの下に表示されるアレ)の最大文字数が13文字というのを聞いて、ニュースは可読性第一なんだなぁ、と思ったことがあります。
PHP始めました。
ここ数日、CSSやHTMLを書くよりもバッチやマクロを書いている時間の方が長かったような気がします。
最近ようやく仕事に慣れてきて、ルーチンワークとそれ以外の作業の切り分けや仕事の優先順位を付けられるようになってきたので、手を動かさなくてもすむような作業は自動化か、あるいは半自動化してしまおうと思い、HTMLやCSSを組む時の補助に使うために、ちょっとサーバサイドスクリプトも勉強してみようと思いました。
早速本屋に行って、サンプル集とさんざん迷ったあげく、初心者向けの書籍を買ってみました。
オライリージャパン
売り上げランキング: 38583
よく考えると、簡単なJavascriptとかActionScriptを書いたことはありますが、きちんと順序立てて言語の勉強をするのは初めてだったりするので、知らない事が山盛りで面白いです。オブジェクト指向って、こういうことだったんですね。
Jqueryがいろいろ面白い件について
prototype.jsとかscript.aculo.usのような、Javascriptのライブラリです。CSS Nite LP2でロクナナの中村さんが紹介しているのを見て取っ付きやすそうなので、作業の合間にぼちぼち触ってみています。
他のライブラリを触った事がないので素のHTMLとの比較になりますが、とにかく簡単にDOMの操作やエフェクトの追加ができる、お手軽なライブラリです。記述が多少賑やかですが、CSSのセレクタとほとんど同じ感覚で記述できます。多分、デザイナーとかCSSのコーディングやっている人はすんなり入って行けると思います。
このブログでも、検索フォームの部分に使っています。処理としてどうよ? という部分はありますが、とにかく短い記述で済むので精神的に良いです。
まあ、こんな感じです。
$(function(){
var searchBoxText = 'Yahoo!検索';
$('.module-search .searchBox').val(searchBoxText);
$('.module-search .searchBox').focus(function(){
$(this).val('');
$(this).addClass('onFocus');
});
$('.module-search .searchBox').blur(function(){
$(this).removeClass('onFocus');
$(this).val(searchBoxText);
});
});
この先スクリプトを触る機会が増えそうなので、これを機会にもっときちんと勉強しようと思います。
blogをいろいろいじってみた
仕事も一段落して余裕が出てきたので、blogに手を入れてみました。
外見はほとんど変わっていませんが、中身をいろいろいじってあります。
動的ページにしてみた
大したアクセス数ではないので、全ページphpにしてみました。.htaccessに細工してあるので拡張子はhtmlですが、サーバ側ではアクセスする度にphpが呼び出されます。
サーバの中の人からすれば迷惑だとは思いますが、動的ページにしたことによって、いろいろできることが増えました。
ページのパーツをモジュール化してみた
右カラムの個々のパーツやヘッダーなどを別ファイルで作成し、requireで読み込むようにしてみました。
静的ページを生成できるのがウリのMovable Typeを使うメリットはなくなりつつありますが、これで、個々のパーツの調整や、パーツの追加や削除などの細かい修正が楽になりました。
個々のエントリーページに右カラムを付けてみた。
今までこれをしようとすると、「最近のエントリー」などのエントリーが追加される度に更新されるパーツがある場合、そのたびそのパーツがあるページを全て生成し直す必要がありましたが、モジュール化してそのファイルだけを更新すれば済むようになったので個々のエントリーページにもカラムを付けてみました。
ファイルの整理をした
画像ファイルがいろんなところに散っていたのでまとめました。
なので、今後画像ファイルとかにリンク切れが起きる事があります。もし見つけた
ら超能力か伝書鳩かメールで教えてください。
これはDreamWeaverのファイラーのおかげです。ファイラーがなかったらまるでやる気が起きませんでした。やっぱりDreamWeaverはよく考えられて作られているなぁ。
del.ico.usからのポストを表示しないようにした。
Movable Typeを2.xから3.xにアップデートする前にも一時期していましたが、プラグインを使って当日以外のポストはインデックスやアーカイブには表示しない
ようにしました。
まあそんな訳で、内部的な部分を細かく調整しましたので、近いうちにビジュアルとかインタフェースのデザインにも手を入れていこうと思います。
Web DesigningのIE7特集がよくまとまっている件について
今日届いたWeb Designingをパラパラ眺めていたところ、特集の「トラブル完全網
羅! Internet Explorer7対策ガイド」が、フロント周りを中心に情報がよくまとま
っていました。
僕らが気にするには主にCSSの解釈と標準/互換モードのスイッチの違いと
Jscriptの変化くらいですが、特集ではセキュリティ面で気にしなければいけない
点なども含められていて、さらに、トラブルが起きたときのためのフローチャート
がついていて問題の切り分けが簡単にできるので、フロントエンドの作業をしてい
てIE7で困った時にこれを見ればだいたいの問題が解決できるのではないでしょう
か。
webディレクターであれば必見だと思います。まあ、webデザイナーやディレク
ターでWeb Designing読んでいない人なんてほとんどいないとは思いますが…。
それにしても、Web Designingは本当にいい雑誌になったよなぁ。
クライアントとサーバサイドの境界線
ここ最近、WebサービスでAjaxとかflashで実装されたリッチなUIが普及のフェーズに入ってきたような気がしますが、これまたすごいサービスが出ました。
詳しくはサイトの動画を見てもらえばわかりますが、ブラウザ上でドラッグ&ドロップのインタフェースでブログを作れるサービスです。
タイトルとか画像とかGoogle Mapsとかをページにドラッグ&ドロップで配置していって「パブリッシュ」すると、ページができてしまうというもので、年賀状ソフトで年賀状を作る感覚に似ているでしょうか。
で、今後しばらくのwebサービスは従来のwebにあったUIとWordやExcelといったPC上で動作するUIが混在して、それからまたあたらしいWebのUIの慣習ができあがっていくんだなぁ、となんとなく思いました。
そうなると、ますますサーバサイドアプリケーションとクライアントサイドアプリケーションの境界線がなくなって、かつてMicrosoftが目指していたようにOSとブラウザが融合したりすると、PCはより「ネットワーク上の端末」という見られ方をするんだろうなぁ、と思ったりもしました。
webサービス立ち上げるたびにOSレベルのUIの作成を求められるのはちょっとヘビーではありますが、そういう未来もありそうな今日この頃です。