チーフコーダーのコーディングメモ

コーディングを進める上で、CSSの整理は重要なタスクの一つとなります

全くコメントもファイル分けもせずに、作成したら、
作った本人すら、わからなくなったりしてしまいます。

こういう状態を解消するには、役割ごとにファイルを分けて、
importさせるのが、得策です。

例えば、
font.css　・・・フォントサイズ、フォントカラーのクラス群をまとめる
blank.css(speacer.css)　・・・余白系（margin,padding,text-indentなど）のクラス群
をまとめる

最近は常識になりつつありますが、こういう風にまとめると、
可読性も一気に高まり、スピードもグンと上がります。

最近、と言っても結構前の話なんですが、

google,yahoo,Live(Microsoft)の3社が「ページの正当なURL」を
定義するための方法を導入しました。
いわゆる、URLの正規化というものです。

検索エンジン対策が主な用途で、

<link rel="canonical" href="http://www.hoge.jp/" />
というタグを入れた場合、
http://hoge.jpという参照元からアクセスしても、
http://www.hoge.jpというふうに、検索ロボットには、
認識されるようで、URLの分散を防ぐことにより、
より、SEO的には非常に良いようです。

その他、
http://hoge.jp/index.html?id=2&clumn=3
のようなurlで参照してきても、検索ロボットには
全て、http://www.hoge.jp/
で統一されるようです。

まだやってない方は、是非試してください！

今日はちょっと横道にそれて、PHPよりの話

最近はSmartyの使いどころが、とんと難しくなりました

数年前までは、デザイナーとプログラマーの分離と謳われ、
一世を風靡したPHPテンプレートエンジンも、

便利なフレームワークの登場で、すっかり影が薄くなって参りました。

Zend,CakePHP,symfony,CodeIgniter・・・・などなど

Smartyのみを使うwebシステムやサイトは、
テンプレートの部分は多少なりとも楽になりますが、上で挙げたツワモノ達に比べると、
やっぱり、作業量は格段に上がります。

逆に、手軽に使おうと、メールフォームやアンケートフォームのみで使うとしても、
やや大袈裟すぎます。（別に使っちゃまずいという事はないんですが）

しかし！

上で挙げたフレームワーク達のほとんどが、プラグインなどで、
使用出来るんです。

彼にもまだ生きる道があったんです。
（実際、そういう使い方する人をあまり聞いた事ないんですが）

まあ、とにかく、Smartyの魅力は何よりあの可読性です！
<?=$hoge?>なんかよりも{$hoge}の方が、
訳の分からない度は、格段下がります。


響き的にもオシャレな気がしたので、何かやる度に、
Smartyを使ったりと若造な時期もあったものですが、
今思うとゾッとするようなくらい、あちこちのサイトに、
Smartyフォルダを忍ばせておりました


今日は有用な情報が一つも無いような気がしないでもないと思いつつ、
また次回よろしくお願いします！

案件によっても異なるが、パスの記述方法で作業環境は大きく左右される。

特に制作段階で面倒なのは最近主流の「ルート相対」。

これは通常の相対と異なりとりあえずルート（root=最上階層）に上ってからパスをたどる記述方法。

利点はサイト内共通箇所に大きく表れる。

例えば、全ページに共通のバナー画像を同じレイアウト（同ソース）で配置する場合、

相対であればその画像パスは各階層ページで異なるソースとなる。

しかし、ルート相対を使えばどの階層ページであろうが全く同じソース記述で済む。

※画像へのパスがルートからたどるため共通。

これによって更新作業や修正作業がし易く効率化できる。

以上の事を考慮すると、ヘッダーやグローバルナビなどに使用すれば

相対パスでは更新時や修正時に発生していた面倒な問題や心配（一発置換的な）がかなり解決できる。

ただし、実はこのルート相対、ローカルでは普通に確認ができない。

ローカルでのルートをたどってしまう。。

仮にCドライブで制作作業をしているなら、Cドラ直下にプレビューファイルを構築すればプレビューできるが、、、

まさかそんな事はしたくないし、しない方が良い。

そこでやっと本題だが、xampp を使う。

基本的にはプログラム開発用の位置づけだが、こういった場合にもかなり使える。

コーディング自体、いかに制作環境を効率化するかで大きな時間短縮につながる場合が多い。

使える便利なものはすべて使う。

使用方法は xampp バーチャルホスト 等の検索で調べてみてください。

コーディング時にその後の更新や利便性を考慮し、

コメントアウトにてそこに記述されている要素が何なのかをマークしておく必要がある。

これはあくまで一般的な使い方。

それとは別に、不要なスペースを消す意味でコメントアウトをする使い方もある。

例えば、

画像を横並びに並べた場合、ソース上は改行くらいして整理しておきたい。

でも、これを普通に改行だけしたのでは画像と画像の間に不要なスペースが入る。

ブラウザにもよるがこの現象を回避するのにコメントアウトを使う。

こうする事で、見た目とソースの見た目、

つまりユーザー側と制作側、どちらにとっても良い仕様が出来る。

専門的で難しい小技もたくさんあるが、こんな事の積み重ねも大切な小技のひとつ。

チェックツールとは少し違いますが、

「W3C」（World Wide Web Consortium）という多くのWeb標準を策定している国際的な団体があります。

ここの定める規定をクリアすると、パスした証にW3Cバナーをサイトに貼ることが許されるのです。

といってもそこまでお堅いものでもありませんが。

W3Cをパスする利点は、多少のアクセシビリティアップ？ SEO対策？

つまり正しいマークアップがされていれば自然とついてくる多少の効果各々です。

とは言うものの、コーディング代行などそれを売りにする職業やサービスサイトであれば

ないよりあった方がぜんぜん良いでしょう。　印象という意味でも。

■Ｗ３Ｃ　公式サイトトップ

■Ｗ３Ｃ　(x)html チェック

■W3C　cssチェック

コーディング内容のチェックツールには様々あります。

下記は用途によって使い分けるのがベストかと思いますが、

コーダーやウェブ制作に携わる人間としては知っておきたいチェックツールです。

それぞれ、違った観点から採点・評価しますので

案件ごとの重視ポイントに合わせて使い分けると良いと思います。

■Another HTML-lint gateway

採点のほか、減点理由も表記されるので簡易的なチェックには最適です。

■ウェブアクセシビリティチェックサイトHAREL

アクセシビリティ適合度をチェックする、解説付きでわかりやすいツールです。

■WebInspector

同じくアクセシビリティを診断するソフトウェアで主に、高齢者や視覚に障害のある方にとって重要な問題を指摘します。

以上、代表的なものですが他にもまだまだたくさんあります。

SEO的なソースチェックを行ってくれるものから、キーワード出現率まで・・・

チェック結果を元にすべてを修正していては無駄な時間が多すぎます。

最低ラインはクリアした上で、最終的なチェックツールとして使用するのが良いと思います。

コーディングの中でかなり重要で、かつ面倒なのがブラウザです。

基本は FireFox で確認しつつ、IE でのバグがあれば調整する。

といったやり方が普通ですが、

それぞれのブラウザを開く手間や、それぞれのバージョン、、

いろいろと面倒でもう少し作業の効率化を図りたいと思うことが多々あります。

そんな時のご参考に。　

■IE5.5, IE6, IE7, IE8の確認を同時にする　IETester

IEについてはバージョンによって異なる現象がおきる事もあり

なるべく幅広くチェックしておきたいです。

CSSでのレイアウト制御が主流になってから

誰もがテーブル組みの時にはなかった現象に頭をかかえたはずです。

親要素の背景が反映されなかったり、

テキストが前要素に重なったり・・・

その他いろいろ。

そんな時はとにかく clearfix を試してみる。

それで回避できる事が多いはずです。

しかし、これも使い方を間違えると厄介なことになります。

とにかく使いまくるのではなく、なるべく使わない様に心がけながら

使用すべきところで、正しい使い方をおすすめします。

clearfix についての宣言方法は、検索すればすぐ見つかります。

ちなみに使用する際はcss内で clearfix用のクラスを設定しておくのがベストです。

あまりにも有名で、基本的なバグです。

通常は組んでいる時に気付く、もっと言えば

デザイン段階でこのバグを考えながら作業を進める人だっていると思います。

ここではあまり詳しく解説しませんが、

とりあえず代表的な回避方法だけ。

【float要素に "inline" 】

フォントサイズの可変時などに崩れが起きる可能性はありますが、

簡単で、周辺要素を見直す時間がないとすぐに使っちゃいます。

【padding で調整】

おそらくこの状況に陥った方は、すでにfloat要素へのwidth指定などで

paddingは使用できない状態でしょう・・・

もし使える状況なら margin → padding へ！

【IE限定ハックにて対処】

IEでおこる現象なら、IEにだけ処置を。

という事でアンダースコアハック。

例）；

margin-left: 20px;　の場合

_margin-left: 10px;　をIE用に追加。

といった感じです。

やはり一番の回避策は、デザイン段階でコーディング方法も頭の中で同時進行する事。

これが出来れば綺麗なソースとコーディングが実現できます。

通常はデザインとコーディングは別工程で進む事が多いためなかなか難しいですが。。