data: schemeのURIでもFragment IDは有効である
data URLスキームは案外ちゃんとサポートされていない訳ではない data スキームは相対参照を認めていない。 これは間違っている。data: schemeを持つURIにおいてもFragmen IDは有効であると考えるのが正しい。Mike SmithがJulian Reschkenにも確認してくれたようなので間違いないと思われる。 RFC 3986の3.5. Fragmentには以下のように書かれている。 Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications. つまり、スキームが何であろうと、基本的にFragment IDは利用可能でなければならない。 なお、少なくとも現時点では、W3CのHTML5バリデー
サイト内の重複コンテンツを防ぐ新たな手段、rel=”canonical”が登場 - F.Ko-Jiの「一秒後は未来」
「SEOmoz | Canonical URL Tag – The Most Important Advancement in SEO Practices Since Sitemaps」によると、Google、Yahoo!、Live(Microsoft)の3社から「ページの標準URLを定義」して「サイト内の重複コンテンツを防止する」ための新たな手法が発表されたようです。 その方法とは、ページの head タグ内に次のような link タグを記述するという簡単なもの。 <link rel="canonical" href="http://blog.fkoji.com/" /> この rel=”canonical” によって、めんどくさい RewriteRule などを定義することなく、検索エンジンに対して望ましいURLを伝えることができます。 Google、Yahoo!、Liveのアナウンス
HTML の id の大文字・小文字の問題 - まじかんと雑記
HTMLに戻したい：メモランダム HTMLで小文字になっているid属性の値が大文字に変換されてしまう問題? そういえばそんな話があったなぁ。 今更だが、俺はこれは大した問題ではないと考えている。というか、これまでの議論では一つ大事な論点が忘れ去られているような気がする。それは、URI の fragment 部分 (# より後の部分) と (case-folding が行われた) id 属性値とを比較する際においても大文字と小文字を区別しなければならないのか、ということだ。 Fragment 部分と id 属性値の比較が大文字小文字の区別無しに行われるならば、何も問題ないではないか。RFC 3986, 3.5 Fragment によれば fragment 部分をどう扱うかはメディアタイプごとに決めてよいことになっている。となると HTML の仕様書に fragment 部分の扱いについてどう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
