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バリデー
濃い鉛筆用の消しゴムを比較してみた
さて、まずは4B鉛筆を一般的なコピー用紙に用いた場合の消え具合を調べた。結果をまず述べてしまえば、以下の3つが比較的良い消え具合だった。 PLUS AIR-IN PILOT FOAM ERASER PLUS OMNI 1つを除き、その他の消しゴムも当然消えないことはないのだが、この3つに比べると消すまでの労力に差が出る。そして、STAEDTLER rasplastは全く持ってお勧めできない。濃い鉛筆に対してこの消しゴムはあまりにも無力である。 上記3つのうち、PLUS OMNIが1番柔らかい。それ故か若干鉛筆の汚れが伸びてしまうことが有るので注意が必要である。PLUS AIR-INの消し心地はMONOに近い。良く消えるMONOという雰囲気である。PILOT FOAM ERASEの消し心地はイメージとしては砂消しに近い。もちろん紙を傷めることはないのだが、サラサラとした消し心地がなかなかよい
RDFとXMLの違いについて
また，今までRDFが何なのか書籍を読んでもよくわからなかったのだが，「XMLは木構造，RDFはDAG（Directed Acyclic Graph）」だと説明されて疑問が氷解（木だけ説明して，森を見させてくれない書籍だったなあ…）． 以下の文章内の「RDFがDAGである」という内容は間違いです。 DAGは「無閉回路有向グラフ」を意味し、サイクルを含むことができるRDFグラフは当てはまりません。「RDFは有向グラフである」が正しい表現となります。 お詫びして訂正します。 参照先ページののコメント欄も合わせてご覧ください。 RDFがDAGなのは、それ自体も重要なのだけれど、しかしそれのみでXMLと対比させるのは評価として正しくないと感じる。 僕が人にRDFを説明するときは、「XMLやCSVやYAMLは、情報を直列化するための仕様だけれど、RDFっていうのは情報そのものを記述するための仕様だ」っ
"Hercules RDF Library in JavaScript: SPARQL Engine Demo"を公開しました
SPARQLクエリエンジンのJavaScript実装版のデモを公開しました。まだまだアルファ版ですが、ちょこっと遊べる感じです。 Hercules RDF Library in JavaScript: SPARQL Engine Demo 色々試しながら実装中なのでコード見るとかなりゴチャゴチャしてますが、とりあえず超最低限は動きます。とはいえ、ちょっといじれば未実装の塊なのがわかりますが。今月中にはSELECTを100%実装したいと思っています。 将来的には、SPARQLクエリをベタに書かなくてもRDF/Objectマッパーから直接クエリできるようにするつもりです。 ちなみにパーサは自前でLL(1)の再帰下降パーサを作りました。車輪の再発明どころの騒ぎではありませんが、こういうのは自分で作った方が楽で良いですね（パフォーマンスを真面目に考えるとそうとも言えないですが）。一応汎用的なパーサ
ブラウザ判定に失敗した時のフォールバック先はフル機能であるべきなのか
ブラウザ判定(しかもダメダメ)しているYahoo! Japan 内容自体は概ね同意なのだが、1つ気になる文章が有った。 こういうフォールバック先は本来、そのサイトのフル機能を実装しているものの、ブラウザ(のバグ等)に対する回避処理を入れていない、理想的なブラウザでは機能するようなものであるべきです。そうでなくては新しいブラウザを含む、未知のブラウザをサポートできないからです。 この文には議論の余地があると思う。本来という言葉を使うほど、この文が示す内容は妥当なものなのだろうか。というのも、今回Yahoo! JAPANは確かに最適とは言えないブラウザの判別方法を採用してしまったわけであるが、基本的には最新のブラウザにキャッチアップしていく姿勢で有るはずだ。作って放置するサイトならまだしも、このように最新状況にキャッチアップしていくサイトにおいては、フォールバック対象を前方互換（つまり未知のブ
AjaxとObject/RDFマッピングライブラリ
Hercules - A simple JavaScript library for O/Rdf mapping RDFとJavaScriptのObjectをマップするライブラリを作り始めました。雰囲気としてはRailsのActiveRecordに似ています。JavaScriptのコードを書けば、自動的にSPARQLクエリ生成からリモートサーバへの問い合わせ、返事のパースにキャッシュまでを行ってくれます。 現在は本当に作りはじめのベータバージョンで、エラーハンドリングなどは全然していません。機能も最も単純なURIを基準としたデータの取得のみです。 <?xml version="1.0" encoding="utf-8" ?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://p
ユーザースタイルシートによる広告の消去は万引きと同じである
ユーザースタイルシートによる広告の消去は、万引きと同じである？ という議論。 個人的には、サービスを利用するのならば、ユーザースタイルシートなどで意図的に広告を消去するのは好きではない。 ある意味では、広告を見る対価としてサービスを利用する権利を得ているのだから、広告を消すことは契約違反（なんの契約かは深く考えていないが）になりかねない、というのもある。しかしそれ以上に、広告を消すという行為は、愛用しているそのサービスに多かれ少なかれダメージを与えることなる、というのが大きな理由だと考えている。極端な例を挙げれば、全員が手元で広告を除去してしまえば、広告収入で運営されているサービスは停止を余儀なくされるだろう。 一方的に利益を搾取するという意味でも、最終的にサービス側が停止に追い込まれるという意味においても、広告の消去は万引きと同じと言っていいのかもしれない？ 反対意見としては、「どうせ見
フォーカスとjavascript:void(0)の話・2
Googleがonclickにはhref="javascript:void(0)"も付ける理由？に頂いたコメントを元に再び考察してみました。 Tabでのフォーカス云々は独自にショートカットキーを実装してるので大して意味が無い話だと思います。 個人的な好みとしては、アプリケーションごとのショートカットキーを覚えるのは面倒なうえ、後述の問題があるため、あまり好きではありません（GMでカスタマイズは別として）。 というのも、Operaのような比較的高性能なショートカットキーを持つブラウザの場合、アプリケーションごとのショートカットキーが操作の邪魔となることが多いからです。例えば（サポート外なのは理解していますが）LDRですと、Shift+↑↓がフックされるため、「フォーカスの移動」が制限されてとてもストレスが溜まります。 だからといって「勝手に独自キーを定義するな」と一概に言うことは出来きないの
Googleがonclickにはhref="javascript:void(0)"も付ける理由？
Googleはonclickなアイテムにはhref="javascript:void(0)"も付けてくれることが多いあるのだが、このお陰で（少なくともFxなら）フォーカスを合わせることが出来る（フォーカス状態でEnterを押せばクリックと同じ動作になる）。対してLDRなどはonclick属性しか使用していないらしく、Tabキーでブラウジングしてる場合などに、フィードの一覧にどうやってもフォーカスが移らないため、とても残念な気持になる。 例えばspan要素などにonclick属性を付けてイベントを発生させている場合はこの方法は使えない（そもそもhref属性がない）ため、表面上のユーザビリティ的には、クリックイベントを取得する場合はa要素を使い、onclick属性と一緒にhrefも付けておくのがよいと言うことになる。 フォロー記事 フォーカスとjavascript:void(0)の話・2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
