普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
流行って欲しいくない
流行るイコール消費され尽くすみたいなことが多いので、流行らないけど狭い世界では評価が高いみたいなのが良いのかなーと思う。ただ、ユーザーの場合はそれで満足できそうだけど、アーティストや開発者の場合はそれでは満足できるほどにはやっていけない。そこに金を簡単にやり取りする仕組みがあれば良い的なのがだいたいこういった話の落とし所なんだけど、狭い世界での金のやり取りって人間関係が崩壊しそうなイメージしかない。本来、こういうところに活躍の場があるのが広告なんだと思う。 インターネットの広告は「スポンサー」や「PR」みたいな変な感じのものが主流で、どっちかというと広告主の要望と欲望が最大限に反映されたものがほとんど。あたかも閲覧者に一定の配慮をしたように見せかけるコンテンツマッチやインタレストマッチみたいなものもあるけど、閲覧者のためというのはその理由の半分くらいな気がする。そして広告主と閲覧者の間にい
引用元のマークアップ
引用で引用元について明らかにすることは大切です。blockquote要素にはそのための属性としてciteが用意されていますが、ほとんど飾りのようなもので、効果的にその情報を表示することは出来ません。じゃどうすれば良いのかというような話です。 figcaption要素で引用元の情報をマークアップし、blockquote要素と共にfigure要素で括るというのがどうやら王道なようです。 <figure> <blockquote cite="http://example.com/"> <p>Lorem ipsum dolor sit amet.</p> </blockquote> <figcaption> <p><cite><a href="http://example.com/">Example Website</a></cite></p> </figcaption> </figure> bl
GoogleプロフィールとWebサイトの関連付け
Googleの提供しているプロフィール・ボタンのようにrel="author"でGoogleプロフィールへリンクを張ることによってWebサイトとGoogleプロフィールを関連付けることができます。Googleプロフィールをメインのオンライン・プロフィールとして利用していたり、これからGoogle+を活用するつもりならそれで良いと思いますが、そうでない場合はちょっとアレですね(全部のページにリンクを追加しないとならなかったりとか)。関連付けの方法としてrel="author"とrel="me"を組み合わせるというやり方もあるので、こちらを使った方がいろいろ楽だと思います(メンテナンス性とか)。 例えばこのWebサイトを例にすると、まずhead要素内で以下のようなlink要素を記述します。 <link rel="author" href="/about/"> /about/に著作者の情報がある
結局どうすればいいの？ - Dive Into HTML5
Translation of: What Does It All Mean? - Dive Into HTML5 Diving In The Doctype The Root Element The <head> Element Character Encoding Friends & (Link) Relations rel = stylesheet rel = alternate Other Link Relations in HTML5 New Semantic Elements in HTML5 A long digression into how browsers handle unknown elements Headers Articles Dates and Times Navigation Footers Further Reading 訳注 Diving In この章で
Hashbang(#!)なURLの恐怖
諸方面からお叱りの言葉しかいただけない#!なURLは様々な問題をはらんでいますが、来るべき未来(もうすぐですよ！)におけるメンテナンス性という問題についてAdactioで取り上げられていました。#!の表面的な凶悪さに思考停止していて、こういった本質的な問題についてはまったく考えていなかった気がします。 その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。 この#!なURLのメンテナンス性の悪さという問題は、URLの#以降はクライアント側の扱いなので、クラ
rel="canonical"はhead要素の先頭に置いてね
Googleでのrel="canonical"の扱いについての中の人の話。rel="canonical"が適切ではないURLを指していた場合に、Googleとしては無視したいし、多くの場合無視するので、万全を期すのなら(「If you really want to be safe」)head要素の先頭に書けと言っている。わかるけどHTMLの書き方が検索エンジンの意向に左右される世の中は嫌だなぁ……。 こういったネガティブなURL評価だけでなく、rel="canonical"のhref属性の値がスラッシュで始まる相対URLで書いてあれば信用してくれるとか、そういうポジティブなURL評価も欲しいですね。要は違うドメインを指しているrel="canonical"の評価を下げてくれれば、場合によっては無視してくれれば、良いんじゃないかとかそんな感じです。まぁユーザーのページがサブドメインで切られて
Windows XPからWindows 7に移行した時に乗り換えたソフトウェアメモ
ちょっと古いHPの無線LANプリンタのドライバ待ちだったのだけど、どうやらWindows 7には提供されないことが判明したりしたので、諦めてCrucial RealSSD C300 64GB買うついでにWindows 7に乗り換えた。結構前だけど。その時にうまく動かなかったりして乗り換えたソフトウェアのメモ。戻したくなったとき用。とか言いつつ「それならこれ使うといいよ！」っていうブクマコメントを期待してる。 Pito! → かざぐるマウス Pito!のマウスカーソル位置にスクロールをリダイレクトする機能がWPFだとうまく動かなかったのでかざぐるマウスに乗り換えた。かざぐるマウスにはAutoHotkeyでやってた加速スクロールとかもあったのでちょうど良かったかもしれない。Pito!の位置・サイズ変更ガイドの代替ソフトウェアが見つからないので併用中。 kbdacc → Hayate kbdac
iine!
Facebookとは全く関係ない。iine!は僕がウェブ上で気に入ったロゴやフォーム、ナビゲーションなどをスクリーンショットと短いコメント付きで並べていくサイト。元々ローカルでやってたのを公開するようにした。特にそれらのパクリ方作成方法を解説したりとかはない。よくあるCSSギャラリーのパーツ版みたいな感じ。いいね！ バックエンド WordPressで作ろうかと思ったけどそんな大げさなものでもないので、blosxom v2.1.2 + mod_rewriteで作った。本体は403や404を吐くためにちょっとだけ改造。 使用したプラグインは、 back_and_forth entry_index_tagged entry_title interpolate_fancy meta paginate_simple push_if_first redirectif_noflavour の8つ。Aut
ウェブサービスのアイコンを書いた
このサイトの右上にあるTwitterアイコンみたいなゆるいグラデ背景なアイコンをいくつか書いた。ここで使う予定だけどまだどう使うかぼんやりとしか考えてない。はてブのアイコンだけ書いてみたら楽しくなったので勢いで書いてしまった。画像にCC-BYとかだとかなり面倒だと思うので、パブリックドメインにしておいた。テカテカしたアイコンが好きではない人にオススメ！ Download: webservice-icons.zip 全て24x24のPNGファイルで、角丸の部分はアルファチャンネル付き。どちらかというと明るい背景向きな気がする。16x16のアイコンは結構難しいのに、24x24になると途端に難易度下がるような。 追記 Last.fmのアイコンだけ書き直して差し替えた。ちょっとベベル気味になってしまっていたのを、公式サイトのロゴと同じような感じにしただけ。
Posterousメモ
Posterousをなんとなく使い始めたので使い方をメモ。はてな記法が思い出せないのでg:subtech:h2uの代わりに使ってる。ブラウザからの投稿や編集は普通のブログ・サービスと似たような物なので、主にメールで投稿する方法について。アイコンが好き(どうでもいい)。 基本 post@posterous.com宛てにメールを送ると、件名がエントリのタイトルに、本文がエントリの本文になる。 初めて使う時も事前に登録する必要はなく、いきなりエントリを投稿するメールを送りつけるだけで良い。自動的に新しくアカウントを作成してくれる。ほぼ一年前に登録したとき感動した。 非公開エントリを投稿 private@posterous.com宛てにメールを送るだけ。 エントリのタグ付け 件名の最後に((tag: foo bar))と追加しておくと、fooとbarをタグとして認識してくれる。エントリのタイトルに
未整理のブックマークをブックマークツールバーに表示
最近はブックマークを適切なフォルダに整理することを放棄して、どんどん未整理のブックマークに放り込み、ロケーションバーから絞込みしやすいように適当に半角英数でタグ付けするだけな感じで生活している。これで大抵の場合は問題ないが、Fx3.5では未整理のブックマークには履歴とブックマークの管理のウィンドウからしかアクセスできない(よね？)ので、一覧したい時などにかなり不便。ブックマークツールバーにでも表示させられれば良いのになぁとちょっと調べてみたら結構簡単に出来たのでメモ。 未整理のブックマークはFirefox内では以下のようなで参照されているので、これをブックマークすれば良い。 place:folder=UNFILED_BOOKMARKS 具体的には下記スクリーンショットのようにしてブックマークを作成するだけ。いきなりブックマークツールバー上に作成すると、フォルダにならずクリックしても「pla
FeedBurnerからTwitterへ
最近になって「エントリ書いた」つぶやきをTwitterに投げるようになった。Twitterfeedとかを使うのは何かに負けた気がすると思ったので、エントリをPublishするPerlスクリプト内でTwitterに投げていたが、FeedBurnerでできるようになったらしいのでそれに乗り換えてみた。設定してActivateボタンを押したら502エラーとか出たけど設定は正常に行われたらしい。 と、導入出来たかどうか確認のためにエントリを書く。 設定画面はまだ日本語化されていない。TwitterのアカウントはFeedBurnerのアカウントに対しては複数設定可能だが、フィードに対しては1つだけなので、フィードが更新されたらTwitterの複数アカウントでつぶやくとかは無理そう。Hash tagsはcategory要素をハッシュ・タグとして付加してくれる。RSS 1.0でtaxo:topicsとか
らいふすとりーむ
Twitterでつぶやき始めたりLast.fmへの曲の登録を再開したりLifestreamに載せられそうなものが増えてきたので、FriendFeedでまとめて、APIを利用してLifestreamを作った。当初はChi.mpで作ろうとしていたのだけど、以前書いたエントリの通り更新遅すぎで使い物にならなかったので一番メジャーなFriendFeedに落ち着いた。 FriendFeedにはJSONPなAPIがあるのでJavaScriptだけで書いた。ざっくりと3*100件分のフィードを拾って、日付でソートしなおし(たまに時系列順に並んでなかったりするみたいなので)、7日分出力したところで止めるという感じ。直近50件とかでも良かったかもしれないけど、なんとなく日付単位で区切った方がすっきりする気がしたので切りが良い1週間分とした。 サービスのfaviconだけ並んでるというデザインはどっかで見てか
はてなブックマークの新着ブックマークとlivedoor Reader
このサイト全体のはてなブックマークでの被ブックマークをトラッキングしようとsitemap.txtを元にしたPipeを作ったのだけど、あんちぽさんに「URLで絞り込んで新着ブックマークのトラッキングできるよ」と教えてもらった。はてなにはなんでもあるな。この機能にはフィードも用意されているので、これをlivedoor Readerで購読すればOK……と思いきや、明らかに被ブックマーク情報が飛び飛びでしか閲覧できなかった。原因はフィード側ではなく、LDR側の仕様によるものみたいだ。 LDRではフィードの記事はlink要素の値で管理されているようで、link要素の値が同じitem要素が複数存在するフィードの場合、常に新しいitemの方で上書きされてしまう。そのため場合によって、LDRのクローラーが巡回する合間に複数のユーザーにより同じURLがブックマークされた時など、は記事が欠落することになる。
rev="canonical"？rel="shorturl"？それとも…… - Weblog - Hail2u.net
ノッチさんがrev="canonical"のアイディアはいいと思うけど書き方がアレだと書いている。rev属性をいまいち理解していない僕には、なるほどくらいしか感想がない。ので、1つ前のエントリではあまり書かなかったこと(書けなかったこと)とかをいくつか書いてみようと思う。 Twitterすごい、そして 議論にならずに単なる伝言ゲームみたいにアイディアだけが伝播してしまうTwitter怖い！ TinyURLとかはなぁ 好きな人いないんじゃないかと。必要に迫られてるだけで。 DiggBar ユーザー(ビジター)には便利だ。コンテンツ提供者にとってどうかというのは検索エンジンがどう扱うかに多くはかかっていると思うので、結論を出すのは早い。生理的に受け付けないとかそういうのはまぁわからなくもないけど。 rev属性 rev属性ってわかりづらいよね。説明短すぎだよね。というか僕わかってないよね。でもH
rev="canonical"
海の向こうで一気に議論が過熱したrev="canonical"ネタ。ざっくりまとめると、TwitterやSMS等の文字数制限のあるメディアで長いURLを投稿するためによく使われてるURL短縮サービスはアレだよね……というところから始まって、じゃぁ個々が自前で短いURLを用意してやって機械的に辿れる仕組み、rev="canonical"を使おうぜ！ という感じ。 URL短縮サービスの提供する短いURLは、on url shortenersで触れられているようにいくつもの問題点がある。一番身近なのはスパムの温床になっていること。インバウンドリンクの追跡が不可能であることなんかも気になる人が多いかもしれない。この話題が再燃した一番大きな原因はDiggBarの登場で、そこらへんの細かいところは短縮URLは必要悪か、単なる悪か。に詳しい。 「短縮URLは必要悪か、単なる悪か。」の最後で触れられている
Canonical URLの流行に乗り遅れた
ので、Specify your canonicalに対応させると共に大幅にHTMLをいじった。こういう普通のサイトはコンテンツが複数のURLで提供されてしまうことはまず無いのであまり意味はないと思うけど、なんとなくやってみたかった。あと階層メニューをついに捨てた。ヘッダはもっとコンパクトになるはずだったのにならなかった。 rel="canonical"を書く上での注意点は、別ドメインのURLは指定できないことくらい。blosxomでは、 <link rel="canonical" href="$url/$path_info" /> とかで良いと思う。不明なflavour回避パッチの問題点で導入したredirectif_noflavourの代わりにもなるかもしれない。 階層メニューは好きなんだけどどうもCSS書きにくい。いやそうじゃなくてサイトの構造的に必要なさそうだったので捨てました！ ロ
FirefoxのuserChrome.cssネタ #11
Firefox 2のデフォルト・テーマは悪くは無い。けれども画像で作ったタブとか画像で作ったタブとか画像で作ったタブとか画像で作ったタブとか画像で作ったタブとかはなんだかなーと思ってしまう。というわけで以前書いたフラットなタブを実現するuserChrome.cssネタをFirefox 2に対応させたりとか他にもいくつか。 タブをフラットなボタンにする(Firefox 2向け) .tabbrowser-tabs { background-image: none !important; } .tabbrowser-tab { margin-right: 3px !important; } .tabbrowser-tab[selected="true"] { font-weight: normal !important; } .tabbrowser-tab > .tab-image-left {
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
blosxom.infoの閉鎖