Web 開発者の責任 (翻訳): Days on the Moon
John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。 Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。 ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。 ブラウザを支援する解決策
Kanasan.JS JavaScript 第 5 版読書会 #7: Days on the Moon
Kanasan.JS JavaScript 第 5 版読書会 #7 に行ってきました (当日のチャットログ)。範囲は前回に引き続き CSS の操作、そしてイベント周りと、一般に「JavaScript」といったとき話題になりやすい部分です。参加者のブログ記事は「JavaScriptでCSSとイベントを扱う from Kanasan.JS | Blog.37to.net」のほか読書会のページからたどれます。 display: inline-block; サイ本では解説されていませんが、CSS の display プロパティの値 inline-block に関して話が盛り上がりました。inline-block 及びそれがどのようなレイアウトに使えるかについては以下で解説されています。 書籍などに紹介されていない display : inline-block について (ヨモツネット) inlin
WEB+DB PRESS Vol.49 WAI-ARIA: Days on the Moon
現在発売中の WEB+DB PRESS Vol. 49 にて Accessible Rich Internet Applications (WAI-ARIA) に関する記事を書かせていただきました。2009 年は Web アクセシビリティの年になるという噂をどこからともなく聞きつけてこのテーマにしたのですが、ちょうど WAI-ARIA 1.0 の最終草案も公開されよいタイミングになったのではと勝手に思っています。 WAI-ARIA とは何なのか、詳しいことは雑誌記事を参照していただくとして、簡単に言えば JavaScript で構築した RIA を機械的に認識するための仕様です。たとえば JavaScript でこったボタンを作ったとしましょう。利用者がどうやって「それがボタンである」ということを認識するかといえば、「周りから浮き出ていてマウスカーソルを乗せると色が変わる」といった感覚によ
SpiderMonkey の判別とブラウザ判別: Days on the Moon
1 行でブラウザ判別を行うスクリプト (IE 用の日本語紹介記事、Firefox、Safari 用の日本語紹介記事) が注目を集めています。それによると Firefox の判別は次の 15 文字で行えるそうです。 //Firefox detector 2/3 by DoctorDan FF=/a/[-1]=='a' いったいなぜこれで Firefox が判別できるのか、少し探ってみました。 何を判別しているのか SpiderMonkey のソースコードを探る より短い SpiderMonkey の判別法 「ブラウザ判別」としての不備 まとめ 参考文献 何を判別しているのか 実際に探っていく前にひとつ注意しなければいけないことがあります。それは、上記のコードが Firefox を判別するものではないということです。このコードには Web ブラウザ固有のオブジェクトモデルに関する情報が含まれて
HTML と XHTML で同じ XPath を使う: Days on the Moon
通常、XPath を書くときは //p のようにすることが多いと思いますが、これには名前空間の指定が含まれていないため、XHTML 文書 (MIME タイプが application/xhtml+xml で提供されている文書) では使えません。これに対するアプローチとしては、//h:p のようにあらかじめ XPath 式に名前空間の指定を含めておき、リゾルバによる名前空間接頭辞の解決時に HTML と XHTML とで処理を分けるというのが一般的でした。「XPathNSResolver のクロスブラウザとか」や「document.contentType == "application/xhtml+xml"なページでの$X」で扱っている方法です。 とはいえ、いちいち名前空間接頭辞を指定するのは面倒くさいですし、同じ名前空間に対する接頭辞が人によって違うのも不便です。XPath 式の中で要素名
Shibuya.js in Kyoto 発表資料「取説 正規表現」: Days on the Moon
オープンソースカンファレンス 2008 Kansai 内のセッション、Shibuya.js in Kyoto に発表者として参加させていただいたので、資料を公開します。 取説 正規表現 内容は JavaScript での正規表現の基本的な扱い方です。正規表現パターンの解説はよく見かけるのですが、それを実際にどう使うかという情報が不足していると感じたので、一部だけですが取り上げてみました。こちらの練習不足でぎこちないプレゼントなってしまい申し訳なかったです。 補足ですが、if ((match = re.exec(str)))、while ((match = re.exec(str))) のように条件式を丸括弧でくくっているのは、それが代入式であることを強調するためです。SpiderMonkey では if (match = re.exec(str)) などと書くと、「等値比較 (==) を代
Narcissus の正規表現: Days on the Moon
「前のエントリで書き忘れてた - 最速チュパカブラ研究会」にて、Narcissus で使われている正規表現が参考になるという話が出ています。 文字列リテラル /^"(?:\\.|[^"])*"|^'(?:[^']|\\.)*'/ 正規表現リテラル /^\/((?:\\.|[^\/])+)\/([gimy]*)/ コメント /^\/(?:\*(?:.|\n)*?\*\/|\/.*)/ 一流の人が書いたものを使いましょうというのに異を唱えるつもりはありませんが、そのままコピー & ペーストしていては意味がありません。ここはやはり一文字一文字心をこめて写経しましょう……ではなく、どうしてその書き方でうまくいくのかをきちんと考えた上で使いましょう。 文字列リテラルにマッチする正規表現 上記の文字列リテラルを表す正規表現から、一重引用符でくくられた文字列にマッチする部分だけを抜き出すと '(?:[^
オレオレ言語の MIME タイプ: Days on the Moon
「OreScript時代の幕開け - yukobaの日記」を筆頭に、JavaScript によるプログラミング言語の実装が流行っているようです。オレオレ言語はその名のとおり各人が好きに作るものですが、それらの言語を識別する MIME メディアタイプ (以下 MIME タイプ) に関してはちょっと違います。他人のつけた MIME タイプと競合してうまく動かないといったことのないよう、意識して設計しなくてはいけません。 MIME タイプの仕様 MIME に関連する規格は多数ありますが、MIME タイプに関して重要なのは RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types と RFC 4288 Media Type Specifications and Registration Procedure
Kanasan.JS レポート
関西での JavaScript 勉強会、Kanasan.JS に行ってきた。内容は Prototype.js のコードリーディング (バージョン 1.5.1.1 を使用)。「家に帰ってレポートを書き、主催者のブログにトラックバックを送るまでが勉強会です」と念を押されたので、まもなく Kanasan さんの記事経由で参加者各々の様子をうかがえるようになると思うけど、以下あとから思ったことも加えて私の場合をつらつらと。 JavaScript 概説 & コードリーディング プロトタイプ やはり皆さん一番引っかかるのはここみたい。おそらく、プロトタイプと名のつくものが 2 つあるのが混乱の原因だと思う。 prototype プロパティ 関数 (Function オブジェクト) のみが持つ。その関数をコンストラクタとして使ったときに用いられる。 [[Prototype]] 内部プロパティ すべてのオ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
