昔のメモ
2005年1月14日（金）
実態参照覚書
自分がよく使いそうなものを抜き出します。
| 実態名/コード | 文字 | 覚書 |
|---|---|---|
| " | " | quotation |
| & | & | ampersand |
| < | < | less-than |
| > | > | greater-than |
| © | © | copyright |
| @ | @ | （上のリンク先にはない） |
文字実態参照は大文字と小文字を区別するので、& を & と書いてはいけません。
@ について
メールアドレスの @ を数値実態参照で記述すれば、スパムメールを多少は防げるかも。
URL 中の &
URL の文字列の中に & がある場合、ソース上ではきちんと実態参照で記述しなければなりません。よくあるのが次のような例。
- Amazon アソシエイトのURL
-
<A HREF="http://www.amazon.co.jp/exec/obidos/redirect?tag=アソシエイトID&path=tg/browse/-/489986">上は、Amazonアソシエイトでリンクを張るときに、「1. HTMLのコピー」として Amazon から提供される HTML ソースの一部です。 & をきちんと & に直してから利用します。
- Google 検索の URL
-
http://www.google.co.jp/search?hl=ja&q=%E3%81%BF%E3%81%A6%E3%81%8F%E3%82%8C%E3%81%A6%E3%81%82%E3%82%8A%E3%81%8C%E3%81%A8%E3%81%86&lr=ここでも & は & とします。
実態参照を使わなくても不具合が起こらないのは、& に続く文字列がたまたま実態参照の文字列として定義されていないためです。
2005年1月8日（土）
リンクの装飾、擬似クラスの宣言順について
リンクにマウスポインタが乗ったときに、アンカーテキストの色や背景色を変えたりするには、 CSS の :hover 疑似クラスを使います。その際、擬似クラスの宣言順序に注意しなければならない、とはよく言われることですが、 その理由まで解説しているサイトをなかなか見かけなかったので、ここにメモ。
理由はリンク先を見ていただくとして、結局、擬似クラスの宣言順は次のようにします。
- a:link （未訪問リンク）
- a:visited （訪問済みリンク）
- a:hover （リンクにマウスポインタが乗ったときなど）
- a:active （リンクをクリックしたときなど）
しかし、これだけだと <a name> で名前をつけた箇所にも :hover や :active が効いてしまうブラウザがある（正しい挙動らしい）ので、
たとえば以下のように記述します（あるいは、<a name> は使わないで、id 属性のみ利用する）。
a:link{ color : blue }
a:visited{ color : purple }
a:link:hover,a:visited:hover{background : yellow }
a:link:active,a:visited:active{ color : red }
class 属性付きのリンクの場合は、たとえば次のようにします。
a.external:hover{ background: fuchsia }2005年1月3日（月）
まともな HTML のオタ系サイト
「オタ系サイト」なんかに分類されて気分を害されるかもしれませんが、自分の知ってるサイトをメモしてみる。
- オタ系サイトの定義
アニメや漫画の話題を扱っている。 または、リンク集に特定のサイトがある。実はコレこそが重要で、ある「コミュニティ」内のサイト（と自分が感じるもの）を指します。
- まともなHTMLの定義
見出し要素、リスト要素、blockquote 要素等を適切に使っており、文法違反も少ない。 必ずしも Valid で Strict である必要はない（そんなサイトはほとんどないので）。
とりあえず「まともな HTML のオタ系サイト」を以上のように定義します。というわけで以下に列挙。
- またたび.ws
「まとも」どころか Valid です。本人も
HTML原理主義者になったと言うかValidなHTMLを書くようになった
と言ってますね。「オタ系」ってのは Amazon アソシエイトのラインナップを見ればわかります。<BR>病は面白かったです。- 電脳遊星D
個人ニュースサイトにしてはめずらしく ul 要素を適切に使っています。2段組レイアウトをテーブルで実現しているのが惜しいところですが、 メイン領域を左側（ソースでは上にくる）にし、summary 属性まで書いていることから、HTML へのこだわりを感じます。表示互換性を優先して仕方なくテーブルレイアウトを採用した、というところでしょうか。
- Cool Blue
バナーを ul 要素とし、メニューは ul 要素＋
display:inlineで横に並べています。CSS で3段組レイアウト。リンク柱がソースでは上にきてしまうのが惜しいです。 リンク柱幅固定＋メイン可変＋ float レイアウトの場合、こうするのが一番簡単なんですが。というか、こうするしかない？- 黒板ぽ
ここを「オタ系」に分類してよいか迷いましたが、サイト内を「オタ」で検索したら結構引っかかったので。 ニュースの分類、リンク先のサイト名表記、ネタ元表記、記事ごとのアンカーなど「個人ニュースサイトの究極のフォーマット」を追及してるっぽい雰囲気。
- Notes. - 世の中を斜めから観ているページ
きちんとマークアップされたページはソースを見るまでもなく、雰囲気でなんとなくわかります。 そんな雰囲気を醸し出している素敵なサイト。
他にも見つけたら順次追加していく予定。
2005年1月2日（日）
「こちら」というリンクはだめ- HERE症候群 -
リンクアンカーの文字列として「こちら」等はふさわしくない、という話。散々既出なのだけれども。
※この記事内の「こちらリンク」はこちらへのリンクとしています。普通ならデッドリンクにするところですが、まぁネタということで。
「こちらリンク」は不便
「こちらリンク」がよくないと言われる理由のひとつは、リンクを辿ってみるまでリンク先がどんなページかわからないというものです。 こう言うと、前後の文脈でわかるじゃないか、という反論もあるかもしれません。たとえば以下の例。
管理人によるイベントレポートはこちら
たしかに、この文脈を見ればリンク先がイベントレポートのページであることはわかります。 しかし、リンク部分だけを抽出するなどして文脈を見ない場合、「こちら」が何を表しているのかわかりません。 実感が沸かない？
画像は、ある個人ニュースサイトのリンク部分のみを Opera で抽出し、「こちら」でソート（並び替え）した画面です。
これらの「こちら」はそれぞれリンク先が異なるのです。これはやや極端な例ですが、「こちらリンク」の不便さがよくわかると思います。
ちなみに、Another HTML-lint gateway ではリンクアンカーに「こちら」とか「ここ」を使うと減点されます。 また、ページ内に同一のアンカーテキストでリンク先が異なるものが含まれる場合も減点してくれます。（素晴らしい！）
「こちらリンク」が閲覧者に嫌われる理由をまとめると
- リンク先が不明
- 音声読み上げブラウザ利用者にとって極めて不便
- 印刷したとき、テキストをコピペしたときに意味不明
さて、「こちらリンク」は不便だからやってはいけないのかというと、
そうではなくて本質は別のところにあるという指摘もあります。
すなわち、「リンクする」とはリソースとリソースの関係を明示すること
であり、
「こちら」という文字列とリンク先を関連付けてはならないというものです（後述）。
Google はアンカーの文字列を利用する
Googleでは入力されたキーワードのすべてがテキストかリンクアンカーと一致するページだけを検索結果に表示します。
強調は引用者。リンクアンカーに「こちら」などを使うべきでないことは、この Google の仕組みからもわかります。 リンク先を適切に表すテキストをアンカーにすれば、Google にとって有用な情報となる、ひいては Google を頻繁に利用する我々にとっても有用なのです。
「こちらリンク」ではもったいない
この「ココをクリック」の問題点は実はたった一つです。もといそう考えるべきです。
この例では、「ココ」という文字列と、終点となるリソースが関係付けられていることになります。つまり、これをやってしまった制作者は、終点リソース（例えば http://www.google.com/ 等）と、「ココ」という文字列を関係付けたことになってしまっています。しかし、制作者にそのような意図は無い筈です。
では、終点リソースと「ココ」という文字列を関係付け
てしまうと、どんな問題があるのでしょうか。
Google で「こちら」を検索すると約 74,900,000 件ヒットする（！）ようですが、
その中の Windows Media ダウンロード センターのキャッシュを見てみます。
これらのキーワードは、このページにむけて張られているリンクに含まれています： こちら
つまり、大勢のサイト制作者が、たとえば「Windows Media Player はこちらからダウンロードしてください」というリンクを張ってしまったために Google は「こちら」と「Windows Media ダウンロード センター」を関連付けてしまったのです。
先ほどのイベントレポートの例でいうと、「イベントレポート」というテキストをアンカーにすればそのページがイベントレポートのページであるという評価を Google に与えることができたのに、 「こちら」という（ほぼ無意味な）テキストを使ってしまったため、Google のリンクアンカーによる評価を無意味にしてしまっているのです。 もったいないと思いませんか？リンク先が自分の作成したページならば、なおさらです。
リンクアンカーはどうすべきか
リンクアンカーはそのまま読んでも文章として意味の通じるものにする、 あるいは、リンク先の見出し要素や title 要素の文字列をリンクアンカーにすれば、関連付けという点でも問題ないでしょう。
余談
イベントレポートの「こちらリンク」は現在では改善されています。
2004年12月27日（月）
サイト制作のためのメモサイト -このサイトについて-
このサイトについて
Web サイトを作る上で、気づいたこと、覚えたこと、気になったことなどをメモしていくページです。
作成支援サイトは多々ありますが、自分が自分のために作ったページというものは、自分にとって最もわかりやすいのではないか、 そういう思い（と、ある別な思惑）からこのサイトを立ち上げました。
リンク集
リンク集は個人的によく利用するものです。あまり使わないものは外してしまうこともあるかと思います。
ご注意
記事の追記・訂正は結構やると思います。その際は、記事を修正した日付を「最終更新日」に反映させます。
アンカー
h3 要素の日付に id 属性によって名前をつけています。 このサイトに日付単位でリンクしたい人はソースを見て id 属性の値を参照してください。Firefox の「選択した部分のソースを表示」機能が便利です。
凡例-サイト制作時における表記の一貫性について-
サイト制作時には表現・表記に一貫性を持たせたいものです。英数字は半角と全角のどちらを使うか。 漢字にするかひらがなにするか。class 名、id 名をどうするか、などなど。 それらの約束事を忘れないようにここにメモしておきます。
※言うまでもなく、これは自分用のメモです。こうしたほうがいいんじゃない？ というアドバイスなどがあれば、教えてくださるとうれしいです。
- 英数字の表記
英数字はすべて半角文字を使用する。
- Disk と Disc
- （）や @
（）は全角。@ は半角。
- class 名
-
- 日付には class="date"
- 更新日には class="update"
- その他、汎用性のある名前を思いついたらここにメモする。
- アルファベットと日本語混じりの文章
アルファベットの前後に半角スペースを空ける。
- 日付の表記
YYYY-MM-DD または YYYY年M月D日と表記する。
- JavaScript
Javascript でも JAVASCRIPT でも javascript でも Java Script でもなく、JavaScript
- リンクを貼る or 張る？
-
- リンクを「貼る」？それとも「張る」？→「張る」
