近頃の、とあるR。

BOMにハマるのその後。

TExchange

複数行置換ソフトTExchangeはその後も快調で、UTF-8の文字化けもまだありません。
ただし、仕様上BOMが付いてしまいますので、それを取らねば…

KanjiTranslator

BOMを取るために導入したKanjiTranslator。分かりやすく使いやすいGUIで快調でしたが、置換結果を示す文字列に、
「このテキストはUTF-8ですが、変換できない文字があります」と表示されているのを発見。BOMのみならず文字コードや改行コードも変えてくれるツールなので、奇妙な文字列が入っていると当然、BOMもとってくれません。
ツール自体は、悪いデータを指摘してくれるすばらしいものです。問題は、どの文字に問題があるのかがなかなか分からない事(ノД｀)
他のエディタでは引っかからない場合も少なくありませんので、ひょっとすると、Unicodeの奇々怪々な仕様に由来する部分なのかもしれません（未確認）。

non-BOM

と言うわけで、BOMだけ取るnon-BOMを導入する事にしました。Sendtoのディレクトリに入れ「右クリックの送る」でフォルダまるごと処理。
問題があるとされてKanjiTranslatorでスキップされてしまうファイルのBOMもサッパリと外してくれます。

しばらくは、TExchange＋non-BOM で行ってみよう(・∀・)

HTMLコーディングの罠は白にもあります。今度は、モニタ特性上の罠ではなく、windows設定上の罠。

ブラウザのデフォルト背景色は白ではない

大抵は白なのですが、ブラウザのデフォルト背景色は白ではなく、windowsで「ウィンドウの色」として設定されている色なんです。

yahoo Japanなどはその色を尊重して、わざと色をつけていないようなのですが、それでも、あれ？と思う部分は少なくありません。

ミスを未然に防ぐ為にも

ミスを視認できるように「ウィンドウの色」をついつい白以外にしてしまうのはHTMLコーダの性でしょうか(ﾉ∀`)

近頃、PCモニタの主流、いやほとんど全ては液晶となりました。TN、VA、IPS、さまざまなタイプのものがあり、また技術進歩も早いようです。そのような中、私のPCモニタは…なお話。

一般的な環境を知っている事

制作側としては、少なからず一般に比し強力な環境が必要となります。私の場合「デュアルモニタ」は譲れません。
しかし同時に、制作者にとって「一般的な環境」を体感で知っている事は、何気に大切なセンスの一つと感じています。あまり「ズパ抜けた環境」ではサイトのインターフェイス感覚も狂ってしまいそうですし。とは言え、近頃では一般の方でもHD環境(横1920ドット)の方が多く、モニタサイズに関しては以前ほどの差はなくなって来ているかもしれません。

液晶の落とし穴

ウェブサイト制作的な、最大の落とし穴はやはり「黒際」ではないでしょうか。

この画像、
黒は#222222～#000000
白は#dddddd～#ffffff
のグラデーションです。本当です(・ω・)
白の分かりやすさに比べ、黒の判別はなんと難しい事か。流石にグラデーションですと分かりにくいので、それぞれ単色のも用意してみました。

私の場合、デフォルトのモニタ設定ですと、非常に目が疲れてしまいますので、コントラストも光度も下げて使っています。
しかし下げすぎると、全然ダメダメに。最低限？上記の黒の差に「気付ける」程度を基準にしています。

小さな差が大きな差

液晶ですと確かに微妙な差です。ほとんどが液晶モニタの昨今、気にする必要もあまり無いのかもしれません。
しかしこれ、ブラウン管で見ると、本当に全然違う色なのです。それはもう、くっきりはっきりと明確に違う＼(^o^)／
技術進歩に伴いPCモニタの性能も底上げされ、これらの違いが再びクッキリと表れる日が訪れるのも、そう遠くはないでしょう。

ブラウン管と液晶が入り乱れた時期には、結構気を使っていましたが、最近気が抜けてるかも(ﾉ∀`) 自戒せねば

いわゆるSSLのページです。「https」で始まるセキュアなページ。
リンクの書き方でちょっと工夫する必要があるのですが、エレガントな記述方が見つかりません(ﾉ∀`)

リンクの記述方

セキュアなページ「へ」のリンク

通常のページからセキュアなページへ飛ぶには、リンクをhttpsから始まる絶対パスで記述します。

セキュアなページ「から」のリンク

セキュアなページから通常のページへ飛ぶには、リンクをhttpから始まる絶対パスで記述します。

不都合

• ローカル環境で確認しにくい
• 更新直前に書き直す必要が生じる場合が多い
• 複雑化する

なんだか、必要以上に面倒くさいのです。「必要以上」と言うのは個人的な感覚に過ぎませんが、もっとエレガントな方法を取れば労力を大きく節約できるに違いありません。
おそらく諸悪の根源は、URI(URL)に位置情報であるサーバ名やファイル名だけではなく、通信情報であるポート番号やプロトコル(スキーム)まで含まれていることです。

どうなればエレガントか

プロトコルとパスの指定を分離できれば。例えば、
<a href=”../index.html” by=”http”>トップページへ</a>
などと記述できれば、プロトコル指定が必要で位置を相対指定できない問題が解消されます。
ええ、無いものねだりですとも･ﾟ･(ﾉД`)･ﾟ･

メニューなどで、マウスが乗ると画像が反転したりする、アレのお話です。
(ソースを格好よく表示するプラグインが本末転倒になっておりますが…)

昔は、Javascriptで反転

メリット

• とにかく、安定して動く
• 印刷でも背景扱いにならない

デメリット

• とにかく、HTMLソースが読み辛い
• IEでツールチップ（ポコっとなるaltの代替テキスト）が出る

昨今は、cssで反転

メリット

• HTMLソースが読みやすい
• 複数の画像を１つにまとめちゃったりもできる
• ツールチップが出ない

デメリット

• CSSソースが読み辛い。凝り具合によっては壊滅的
• 印刷が背景扱いになる

トップへ

これから（既にか？）は、再びJavascript

メリット

• HTMLソースはなかなか読みやすい
• CSSソースもかなり読みやすい
• 印刷で背景扱いにならない

デメリット

• IEだとやっぱりツールチップが出る
• 弱いPCだと重い場合も考えられる

しばらくJSで行ってみます

hタグに画像が入ったり、ナビ上でツールチップが出ちゃうのが気に入りませんが、座標取りが楽で印刷対応も柔軟に行えますし、なによりcssがキレイなので、来月からはマウスオーバーはJSメインで組もうかな。現在作業中の案件も同様。

月並みに言いますと、ウェブサイトにはその組織のあり方が鮮明に映し出されています。HTMLコーダ的に、リテール商品を取り扱う大企業をいろいろ観察し、そのエッセンスをまとめてみようと思いました。
…しかし、最初の一つの「三菱東京UFJ」が予想以上に興味深かったので、単体エントリに。

胃が痛くなりそうだが…案外

現場はものすごく頑張っていると思います(ノД｀)
三菱東京UFJのサイトは見れば見るほど、胃に来ます。統合の関係でカオスの道を進んでしまった基幹システム部の悲劇は隠しようもなくはっきりと見え、無関係な私でさえ胃が…。
とは言え、純粋にウェブサイトとしてみると、なかなかエレガントではありませんか。情報構造はスルーしますが、ドメインも含めてグループ間でもなかなか統一されています。

リニューアル中？

グループレベルでのデザイン統一は、なかなか骨の折れる仕事です。まず「ちゃんとした仕事」のできる組織でなくてはなりません。さらっと眺めてみると…三菱UFJ信託銀行だけ、ちょっとデザインが違いますね。
巨大サイトですと、少なからず万年リニューアルの様相もあるのですが、これには「大きな節目」のようなものを感じます（←結論としては誤解）。
近頃の流れも踏まえると、

• より幅広に
• センター寄せ

な信託銀行の方が新しいのでしょうか。なぜか、納得行きません。しっくり来ません。鈍い私の感覚でも、信託銀行以外の方がビジュアル感覚は優れているような(ﾉ∀`)
ソースをみてみます。おおーグループのほとんどのページはテーブルレイアウトなんですね。信託銀行だけXHTML定義。最近の流れではCSS化もリニューアルの動機になるようです。よくよく見れば、共通部はCSS化されていたり、トップ以外では印刷スタイルでナビ等を非表示にしてあったりも。なかなか経緯を感じさせる具合です。

三菱ＵＦＪ信託銀行

DTDがXHTMLな事も有り、tableも散見されるものの、まぁ一応CSS的か。そして…これは、硬派(ノД｀)1行目に<?xml version=”1.0″ encoding=”shift_jis”?>が記述されています。
書いても書かなくても良いこの１行目。XML（HTMLではなく）としては書くのが理想的な表記なんだそうです。ただ、コーディング的にはIE6と非常に相性が悪く、なかなか厄介な存在。この1行を書くだけで、IE6への対応が大きく変わってしまう、難儀な呪文です。テーブルの多用はその辺にも理由があるのかもしれません。

成り立ちを調べてみる

そういえばそう、そうそうそうでしたね。信託銀行は「引っ張りダコ」だったんでしたっけ。ひょっとすると、その辺の影響が表れているのかもしれません。
スタートは、2005年の10月。確かに、CSSとtableの混ざり具合は2005年的かもしれません(ノ∀`) Internet Archive的にも、近年こうなった訳ではなく、2005年の発足当初から今のデザインだったようです。つまり、リニューアル中でもなんでもなく、最初からそうだったんですね。

得られたエッセンス

銀行系サイトですと、どこも結構イライラするんです。私は。得たい情報になかなかたどり着けなかったりで。手っ取り早く電話で聞いちゃったりさえします。なので、醍醐味の詰まっているであろう情報構造に関してはあえてスルー＼(^o^)／銀行系の経験もありませんし、情報構造に踏み込むのはちょっと失礼な気もしました。
…まぁ、そもそも失礼なエントリなんですがね(笑)

避けては通れないカオスが存在する

ネットバンキングが２系統ある。このカオスだけで逝けます。要望や命令も２系統なんでしょうか(ノД｀)それを吸収し翻訳する機能を持つ部署なり担当者がいらっしゃるのでしょうが、その方が神なんですかね。

レギュレーションこそ古いが頑張っている

究極クラスの超カオスの中、スタートアップはすばらしい仕事をしたと言えるでしょう。
そして、おそらくそのカオスへの対処は今日でもなお、大変な作業。費用も非常にかかっているでしょうし、レギュレーションの大幅改訂にも迫られているかもしれません。他人事ながら、頭が下がる思いです。

SyntaxHighlighterを入れてみました。

表示のズレ

私の環境ではcssが被って表示がずれてしまったので、SyntaxHighlighter.css を微調整。1行目にカンマを入れｗ6,7行目を追加。むむ、なんか変更点を文章で表現するのは早速格好悪いですね･ﾟ･(ﾉД`)･ﾟ･

.dp-highlighter,
.dp-highlighter ol,
.dp-highlighter ol li,
.dp-highlighter ol li span
{
	margin: 0 !important;
	padding: 0 !important;
	font-weight: normal;
	font-family: "Consolas", "Monaco", "Courier New",
	Courier, monospace !important;
	font-size: 12px;
}

専用タグを拡張

[code='css'] ここにコードを書く [/code]
等とするのがこのプラグインの書式です。
非常に便利なのですが、専用タグはなんかこう、ムズムズします。プラグインを変えた場合にコードとして扱われなってしまう痒さ。もっとも、専用タグを一括置換してしまえば良い気もします。
今回は、<pre>タグも専用タグとして使えるよう弄ってみました。

書き換えたソースも説明してみるつもりだったのですが、該当部が専用タグそのものなので上手く使えず･ﾟ･(ﾉД`)･ﾟ･
いきなり大失敗の予感です。