Home‎ > ‎WebDev‎ > ‎

WebsiteRegulation

レギュレーション項目 

  • ブラウザ(UA)関連のレギュレーション
    • ★★★ 対応・検証ブラウザ
    • ★★☆ 文字コード・改行コード
    • ★★☆ ターゲット解像度・色深度
    • ★★☆ 印刷対応
    • ★★★ xhtml1.0 or html4.01 等のDTD
    • ★★★ 互換モード or 標準モード
    • ★★★ ページ幅 左寄せ/中央/リキッド
    • ★★★ 文字の大きさ 可変
    • ★★☆ Flashのversion
    • ★☆☆ PDFのversion
    • ★☆☆ その他プラグイン対応
    • ★★☆ 想定接続速度
    • ★☆☆ 1Pあたりのファイル転送容量上限
  • リソース配置・html記述関連のレギュレーション
    • ★★☆ ディレクトリ・ファイル名ルール
      • 共有リソース
      • js,script,img,images,css,style,inc,include 等の汎用名称
      • 大文字,小文字,記号の扱い
      • 拡張子
      • 最大文字数
    • ★★☆ パス記述法ルール
    • ★☆☆ インデントルール
    • ★☆☆ コメントルール
    • ★☆☆ 使用禁止文字種
  • サーバ・環境関連
    • SSIの使用可否
    • .htaccessの使用可否
    • phpの使用可否
    • SSL関連
    • その他
  • 付加要件
    • レガシーブラウザ対応
    • スクリーンリーダー・音声ブラウザ対応
    • Ajaxアプリケーション

★★★ 対応・検証ブラウザ

「対応ブラウザ」 (呼び方要検討)と「検証ブラウザ」は別けておく方がよい (対応ブラウザの全てのバージョンをチェックできるわけではない)

対応ブラウザ
検証ブラウザの系列に属し、基本的に動作すると想定されるブラウザ
検証ブラウザ
実動作を確認する対象となるブラウザ
対応外のブラウザ
完全な対象外とするのはアクセシビリティなどの面から好ましくない
  • 情報取得そのものは可能にする
  • レイアウトの再現性については保証しない このあたりが、落としどころ

2006年10月現在の推奨検証ブラウザ 

  • win
    • IE 6.0
    • FireFox 1.5
    • IE 5.5
    • IE 7.0 △ 2006/10中にリリース予定らしい。尚、自動インストールは半年後に始まるとのこと。正式リリースまでは仕様変更の可能性もあるため、特別な対応は避けた方がよいかもしれない。
  • mac
    • Safari 2.0
    • Safari 1.2 △

以上で、90〜95%はカバーできている。現実的なライン。*1 これがオッケーであれば、ほぼ大丈夫といえる範囲は、98%ぐらいになるとおもわれる。 これ以上やるのであれば、やたらと検証ブラウザを増やすのではなく、ログ解析を行ってそのサイトのユーザエージェントのパーセンテージで多くを占めるモノを追加していくことを考えるべきだろう。また予算の増分も検討すべきである。

逆に減らすときは、その事由を十分に考慮し、クライアントに納得してもらった上で要件として固めるべきである。

特に、アクセシビリティ対応における、スクリーンリーダー・音声ブラウザ対応は、別途要件と考えた方がよい。 単なる、外向けのJIS規格対応ではなく、実際に通常のブラウザ検証と同等の検証を行うとすれば、5〜10倍のコストがかかる可能性もある。


★★☆文字コード・改行コード 

特に考慮すべき事項がないなら、 Shift-JIS+CR+LF で良いと思う。

文字コード 

UTF-8
多言語前提なら、ほぼ選択の余地なし。  非常に古いブラウザでは、対応していない、あるいはフォームが正常に動作しないなどあるが、現在の標準的な環境であれば問題ない。後、AJAX絡みの時もUTF-8が安全っぽい。
Shift-JIS
更新作業を手作業でやっており、WIN環境前提で低いレベルで触ることを前提とするとか  日本語だけなら、普通これでかまわない。
EUC-JP
システム開発が絡む場合、EUCが好まれることが多い。上記のような、他のコードを選択する必要があるのでなければ、別段、拒否する理由はない。DBで使用されるコードなどと合わせるといった場合も。

改行コード 

文字コードと合わせて、決めておかなくてはいけないが、重要度は低い。 どちらかというと、

CR+LF
更新環境がwinの際、安全
CR
更新環境が古いmacメインなら
LF
unixのシステムに都合良い

★★☆印刷対応 

幅640pxを越えるようであれば、印刷対応専用ページもしくは、media属性などを利用した印刷用CSSの準備をしたほうが良い。

印刷対応用のページ
全ページCMS等で生成、更新している。あるいは、一部ページだけであれば、こちらの方が好ましい。
media属性などを利用した印刷用CSS
上記の条件を満たせず、しかも幅を広く取る必要がある場合、この手の手法をとることも。

★★★xhtml1.0 or html4.01 等のDTD 

互換性重視
従来ソースの利用や手作業更新が多いと考えられる場合には、html4.01
標準化重視
オールCMS化など手作業更新を排除できるのであれば、xhtml1.0
  • xthml1.1は、現実的には使えない。
  • 標準化への強い意志とか、特別な理由がなければ、Transitionalにしておくのが無難。
  • 後に述べる、互換モードと標準モードにも連動

★★★ 互換モード or 標準モード 

IE7が正式になった時点で、標準モードにしておいた方が有利になったのではないかと思う。 そもそも互換モードは、あくまで互換であって以前の間違ったCSSの解釈と互換をとるためのモード。 特にフルCSSでコーディングするのであれば、互換モードをオススメしておく。

互換モード  後方互換性を意識したモード 

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 xhtmlの場合は、やっかいなので、DOCTYPEの宣言なし無しにしておくのが無難?そもそも互換モードを使うなら、xhtmlにすべきでない?

標準モード 標準に準拠したモード、描画も高速 

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

★★★ ページ幅 左寄せ/中央/リキッド 

ページ幅
固定かリキッドかというのはあるが、780がひとつの区切り。 これより大きいと印刷に支障を生じる場合がある。*2また、800*600画面で見ることのできる範囲という意味もある。
左寄せ
基本、コーディングの面からは一番安定している。ユーザビリティ的にも問題が少ない。
中央
固定幅をセンタリングする手法。見栄えはいいので、デザイナに好まれる傾向はあるが前述の互換モード、標準モードの絡みとともに、実現する方法など少しややこしいことがある。*3
リキッド
画面幅に追随するモードで、ポータルサイト、アプリケーションサービス系など、幅が広がることで使いやすくなるサイトで使われていることが多い。文字を読ませる、デザインを固めるのには不向きな面があるので、前述のような理由があるときにだけ使った方が無難。

ページ幅に関する考察リンク集 

★★☆ ターゲット解像度・色深度 

通常16bit(32000色以上)で問題ないと思われる。 アクセシビリティ対応などが必要な場合は、色弱対応も含めた上で256色対応も必要になる可能性有り。



★★☆ Flashのversion 


★★☆ 想定接続速度 



*1 Operaとか全然入っていないのは意外だった。
*2 印刷対応で述べたような別途対応が必要になる可能性も
*3 つまり、途中での仕様変更に弱い。対応しにくい。
Comments