メモ

Adobe BrowserLab アドビに登録が必要（AdobeIDとかいうので、確か無料で誰でも作れたと思います）ですが、無料で使えるブラウザ表示のシミュレートツール。 任意のページについて、選んだブラウザでの表示をサーバー上でシミュレーションして画像として見せてくれます。 今日現在で見られるOSとブラウザの組み合わせは以下の通り Chrome 3.0 - WinXP FireFox 2.0、FireFox 3.0、FireFox 3.5 - WinXP、OSX IE6.0、IE7.0、IE8.0 - WinXP Safari 3.0、Safari 4.0 - OSX 横に並べたり、重ねて透明度を変えて比較することもできます。 あくまで擬似的なものですが、簡易的なチェックには役にたつでしょう。 ちょっと時間が掛かるのが玉に瑕ですね。 というか、こういう機能はDreamWeaverに入れてくれればいいのに。

cssだけに限りませんね。jsとかphpでincludeするファイルとか、要するにそれらの文字コードが揃っていないと文字が化け化けになった結果、タグに使う文字（三角括弧やクォーテーション）が出てきてしまうと全体のタグ構成がおかしくなるので崩れます。 最近では基本UTF-8で組めば良いんだろうけど、携帯対応とか古いプログラムの流用とかでShift-JISを使わざるを得ない場合もあったりして、DreamWeaverの設定を切り替えながら作業していると、たまに忘れちゃうときがあるんですね。複数スタッフで１つのサイトを時なんかに紛れ込んだりもします。 文字コードって重要ですね。。。

新人がよくはまります。 classやidの名前を数字で始めてはいけないんですね。 文字としては使えるんですけど、最初はアルファベットを使うと。 ところがなぜかブラウザによってちゃんと見えてしまったり、そもそもDreamWeaverのプレビューでOKだったりしちゃうので、ハマルと気づかないのです。たしかIEでcssが利かないと思った。 基本的なチェックポイントなんだけど、あまりに基本過ぎて見落としてしまう事があるので記録。

DD_belatedPNGに付いての過去のエントリはこちら IE6でのPNG透過 DD_belatedPNGとOperaの組み合わせで、意図しない隙間ができる不具合？ 便利に使えていたDD_belatedPNGですが、テーブルのthの背景に、200ピクセル四方の半透明PNGをリピートで敷き詰めたところ、該当ページを表示し要素したときに読み込み中のまま先に進まなくなるという現象が発生しました。 DD_belatedPNGのバグと言えるのかどうかはハッキリしないけど、意図した動作をしないという意味で、なんらかバグ的なものというレベルでしょうか。まぁ、元々難しいことを簡単にできるようにして頂いているので、その辺は広い心で受け入れよう。 具体的には、画面が真っ白のまま、一切の操作を受け付けなくなります。（落ちたりはしない） リピートしたときの負荷的な問題だろうか？ 原因についてはそのうちもう少し調査してみるつもりだけど、とりあえず今回は単に半透明の背景色を敷いて、さらにその下が透けるようにしたかっただけで、角丸とかドロップシャドウは使っていない単純なものだったので、IE6での透過表示は諦めて、該当箇所でのDD_belatedPNG使用をやめました。

CSSにはtext-justifyというプロパティがありますが、残念ながら実用的には使えません。 そう言うときにはjQueryで補う！ということで、探してみたところ、やっぱりありました。 左右いっぱいに文字をそろえる均等割り付け、印刷ではよく使われますが、Webでこれを表現するのはいかがなものかなぁと思います。別に必要ないんじゃないか、と。 困るのは、印刷畑の人が持ち込んできたデザインをコーディングする時ね。 基本的にこれはできないと言ってきたので、今回も断るのですが（笑）、一応切り札としてはjQueryでやる方法もありそうです。 でも、やっぱりWebに均等割り付けはなければないで良いと思う。。。 普通に使えるようになるのなら、デザイン的に使いたいところもあるけど、ここまでしてやることだろうか。 Character Justification Pluginのダウンロードページ 均等割付の話の続き（オチ？）はこちら

３連休に何冊か取り込みをしてみました。試したのは文庫の小説、詰碁（笑）２冊です。 結果分かったこと。 (1)文字などの黒色が薄い本は、コントラストが結構甘めになる。 (2)紙の色が白でない本は、紙の色がきれいに出ない。 （ベタッと全体が同じような色で出て欲しいが、グラデーションしてしまう） (3)適当設定で取り込んでも読めるが、やはりレベル補正をかける方が断然きれい。 (4)携帯（940SH）にJpegを転送して見てみたが、思いの外きれいに見えて感動！ (1)文字などの黒色が薄い本は、コントラストが結構甘めになる。 本はだいたい白黒の二色で印刷されていますが、黒と言っても真っ黒になっているわけではなくて、どうしても濃いグレーになってしまう。 scansnapは基本的にグレーの設定で取り込んでいるが、文字が少し薄めの色になるだけで、取り込み結果では割と差が出る。 もってないけどKindleとか、携帯の液晶画面で見る分には全然気にしなくても良いのかと思うんだけど、取り込み直後にPCで確認しているから結構気になってしまう。 (2)古くて紙の色が変わってしまう事もあるけど、文庫本の紙の色って少し色が付いている事が多い。これも(1)と同様、文字とのコントラストを下げる原因になるので、取り込み後の画像も文字が薄めになってしまったりする。 (3)上記を解決するためにはやはりレベル補正（あるいはトーンカーブ）で補正をした方が良い。 特に本はオリジナルを処分してライブラリ化する予定なので、一応このくらいはしておきたい。 レベル補正については、サンプル画像も入れつつ、別途やってみたい。 (4)最終的にはiPadなどのタブレット機で読むのがゴールなのだが、まだ手元になので（あたりまえ）、とりあえず携帯電話940SHにJpegで転送して、読んでみた。 文庫サイズの詰碁の本で、詰め碁というのは問題の図（碁盤の絵）は一部分だけだから大きいし、文字も小説よりも大きい。 元々紙が真っ白に近くてきれいなのだが、黒色が若干薄い。なのでレベル補正は強めにかけた。 携帯の画面サイズが横幅480ピクセルなので、レベル補正と同時にPhotoShopで縮小。 できた画像はパソコンで見るとさすがに小さい。が、携帯で見ると、超きれい！ 画面のドットの密度が高い...

いかさまです。 本当は最初に組むときにしっかり考えれば必要のないことなのですが、あとからデザインが変わったときに既に組んでしまったHTMLを変えずに、CSSの微調整だけでは直せないことがあります。 HTML側も変えるとなると、既に別行程（プログラマのPHP組込）などに移っているものも戻してもらわないといけないので、場合によってはちょっと面倒だったりします。 今回起こったのは、もともとサブメニューとメインコンテンツの二段組みにしていたコンテンツで、左右の高さはそれぞれの成り行きになるように組んでいた。 ところがデザインの関係上、メインコンテンツ側の縦幅がサブメニューの縦幅より小さいときにはサブメニューの縦幅分の高さは確保したい、というもの。 jQueryのhight()で高さを取得できるので、それを使って以下のように解決。 var mainHeight = ($("#main").height()); var sideHeight = ($("#side").height()); if (sideHeight > mainHeight ){ ($("#main").height(side)); } これで、mainの縦幅が小さいときは、sideに自動的に合います。 ページがロードされてから実行されるため、一瞬、本来の高さでmainが表示され、すぐにsideの高さまで広がります。 全体に読み込ませているjsファイルに5行仕込んで終了。らくちん。 でもまぁ、こんな事やらないに越したことはないですけどね。