JavaScript連載第13回

JavaScript

クロスブラウザJavaScript入門の第13回です。今回は簡単なアプリケーションの作成ってことで、これまでのまとめ・復習的な内容になっています。ただ「簡単な」と書きましたが、あんまり簡単じゃないかも…。
JavaScript部分は特に問題はなかったんですが、やはりCSS周りで少々手こずりました。IE6がposition:fixedに対応していないので、ページ全体としてはスクロールバーを出さずに、部分的にスクロールさせることでposition:fixed相当の表示をする方法を試してみました。IEがなんとかなったと思ったらOperaが…とか。

短縮URLの展開に使っているのは以前書いたAPI(ソース)です。Access-Control-Allow-Originヘッダをつけてあります。ちなみにこのAPIで一度に複数のURLを受け取らないのは、このサーバーから大量のリクエストを投げてしまうようなことがないように、という意図があったりします(気分的な話です)。

デベロッパーツール特集第2回

Google Chrome版Firebug：デベロッパーツール取扱説明書の第2回JavaScriptのデバッグとチューニングが公開されています。
前回は適当に使ってても大体わかるような基本的な使い方が多かったですが、今回は調べないとわからないだろうと思ったところを取り上げてみました。記事中でもリンクしていますが、id:monjudohさんのFirebugで元のJavaScriptのコードに手を入れずにdebug用のconsole出力を入れる方法 - 文殊堂のネタも取り上げました。
console.logはFirebug版と同じく、printfライクな機能を備えていますが、桁揃えみたいなフォーマット機能はサポートしていないのでイマイチ使い道がなかったり…。
WebInspectorの場合、console.logかconsole.dirのどちらか(DOMを解析したい場合にdirを使う)で事足りるでしょう。

プログラミングに最適なConsolasとかInconsolataとか

でInconsolataだけが紹介されているので、おまけ情報を少々。
Inconsolataというのは、Windows Vista/7 に標準で付属しているConsolasフォントに感銘を受けた作者がConsolasを意識して作ったフォントです。
ConsolasのほうはVista/7だけでなく、Visual Studioに付属してたりもします。一応、こちらからダウンロードもできるようです。
Download: Consolas Font Pack - Microsoft Download Center - Download Details

Windows(少なくとも7では)ではConsolasのほうがより(ClearTypeの効きが)綺麗だと思います。というか、InconsolataはWindowsだとどうも今一つ…、ただMacやLinuxではWindowsでのConsolasと同じくらいに綺麗みたいです。
Consolas:f:id:os0x:20100823013119p:image
Inconsolata:f:id:os0x:20100823013120p:image

もうひとつ、InconsolataはGoogle Font APIでも提供されています。
Inconsolata Font Family – Google Font Directory
そのため、

<link href='http://fonts.googleapis.com/css?family=Inconsolata' rel='stylesheet' type='text/css'>
<style type='text/css'>
pre{
  font-family: 'Consolas', 'Inconsolata', monospace;
}
</style>

のようにすることでウェブ上でもInconsolataを手軽に利用できます(Consolasはお好みで)。


参考:yebo blog

JavaScript連載12回とデベロッパーツールの特集開始

JavaScript Chrome

これでできる！ クロスブラウザJavaScript入門の第12回として、XMLHttpRequest入門が、Google Chrome版Firebug：デベロッパーツール取扱説明書として、詳説：デベロッパーツールの使い方が公開されています。
デベロッパーツールというのはWebKitのWebInspectorのことで、FirefoxのFirebugに当たるブラウザベースのデバッグツールです。って、まあこのブログを読んでくださっている方には今更感があるとは思いますが。ただ、Firebugを始めWebInspector、Dragonfly(Opera)、さらにIEの開発者ツールにいたっても、すごい勢いで改良が進められていて、高機能化してきています。もはや、これらのデバッグツールなしでウェブ開発をするなんて考えられないでしょう。同時に使い方がわかり難くなってきている面もあるので、画像大盛りの解説にしてみました。
あと、WebInspectorはFirebugと機能的にはほとんど差がないし、なんといっても軽いので、もっとみんな使ってみてほしいなーと思っています。
# この前、id:secondlifeさんにWebInspectorだってCookieの編集くらいできますよと自慢げに話してしまったんですが、記事書いてて削除しかできないことに気が付きました。死にたい。localStorageは編集もできるんだけどね。
コンソールで複数行モードがないのが惜しいんですが、改行を含むコードをコピペすれば編集はできるので…。

script, styleタグ内のコードの書き方

# 最初にちょっと余談を。Chromium-Extensions-JapanのほうにChrome6 Betaの変更点を書きました。どうぞよろしく。

さて、scriptタグ内をHTMLコメントで括ってからJavaScript書くのって意味あるの? - Togetterの件に関して、関連ネタをいくつか書いておきます。。
まず前提として、scriptタグの中に直にコードを書くというのはできる限り避けたほうが良いです。とはいえ、ちょっとしたコードをいちいち外部ファイルにしていると読み込みのコストも馬鹿にならないので、インラインで書く事もよくあります。なので、以下は主に数行程度のコードをインラインに書く場合の話です。

scriptタグの中に直にコードを書くときはscriptタグに非対応なブラウザのために<！--で始め*1 // -->で閉じるというノウハウは今でも結構使われているみたいです。
しかし、scriptタグはNetscape Navigaterは2.0から、Internet Explorerは3.0から対応しています。古い携帯電話ではscriptタグに非対応な場合があり、それらはまだ使われている場合もあると思われますが、そもそもそういう携帯は専用のHTMLじゃないとまともに表示できません。
なので、<！-- // -->は不要という結論で良いと思うのですが、こういう話もあります。





<！-- //-->はXSSフィルタの誤検出隠しに有効とのこと。
ただ、そのユーザーが嫌がらせを受けているのはほぼ確実なので、それがユーザーの目にも見えたほうが良いとも考えられます。前提に戻って、インラインにコードを書かないという対策を取るのがベターでしょう。

追記:


<！--を使わなくてもスクリプトが出力されるってことはなくなったらしいので、やはり<！--は不要です。もう一度言います。不要です。

また、script要素に対応していないブラウザでは<！-- //-->でコメントアウトしていると、文字列リテラル中に-->が出てきた時にそれをコメントの終了みなしてしまって、それ以降がコメントとみなされないという問題もあります。詳しくはXSS対策:JavaScriptのエスケープ(その3) - ockeghem(徳丸浩)の日記に。ほとんどの場合、JavaScriptが動かない程度の問題でしかないので脅威ではありませんが、<！-- // -->を避ける理由としては十分でしょう。前述の通り、script要素に対応していない環境は考慮する必要はもはやないので、特に気にする必要はないでしょう。
なお、当たり前ですが「ブラウザがscript要素に対応していない」と、「JavaScriptを無効にしている」というのは別の話です。script要素に対応していない環境は想定しなくとも、JavaScriptを無効にしているユーザーやscriptを実行しないブラウザのためにnoscript要素などで代替コンテンツなどを用意するべきです。


ちなみに、

で触れられているように、Polyglot Markup(和訳)では

<script>
//<![CDATA[
	(script goes here)
//]]>
</script>
<style>
/*<![CDATA[*/
	(styles go here)
/*]]>*/
</style>

の形が例示されています。
これは、HTMLとしても、XHTMLとしても解釈できるようにするためのテクニックです。
ちなみに、scriptの時もstyleにあわせて、

<script>
/*<![CDATA[*/
	(script goes here)
/*]]>*/
</script>

としてもOKです(逆はできません)。
ただ、前者がコメントアウト→CDATA開始→スクリプト本体→コメントアウト→CDATA終了とまだ違和感なく解釈されるのに対して、後者はコメントアウト開始→CDATA開始→コメントアウト終了→…と開始と終了のネストに違和感があります。まあ、styleタグではどうしようもないし、気分的な問題に過ぎませんが。
つまりは、結局のところはこれもバッドノウハウなので、XHTMLやSVGとか(要はXML)では/**/を入れずに直接 <！[CDATA[ を書き、HTMLでは直にコードを書くほうが良いような気もします。悩ましいところですね。

もひとつおまけで、scriptタグ内の<！--をブラウザはどう解釈しているのかというと、実は//(一行コメント)として解釈しているそうです。ネタ元→HTMLJS - JavaScriptで遊ぶよ - g:javascript
なので、下記のalertは実行されません。*2

<script>
<！-- alert('hello'); // 実行されない
1;
//-->
</script>

以上、小ネタの盛り合わせでした。

*1:はてな記法でコメントアウトされないように!を全角にしています

*2:もう一度繰り返しておくと、はてな記法でコメントアウトされないように!を全角にしています

ECMAの読み方

# なんかTwitter記法がうまく動いてないんだけど、なにが悪いのかわからない…
この前の#orejsや今日の#hatenatechでも話題になっていたECMAの読みについて。*1


http://twitter.com/Constellation/status/19413623287

http://twitter.com/rwest2112/status/20355293935
どっちやねんと。
nanto_viさん曰く

http://twitter.com/nanto_vi/status/19428658459
このかつて存在した団体というのがポイントで、元々は欧州電子計算機工業会（European Computer Manufacturers Association）という団体があったそうです。この団体の略称が頭文字を取ってECMAなんですね。このときの、読みはイーシーエムエーでした。
ただ、欧州という地域限定から国際的な団体へとシフトするという方向転換があり、その際にEcma International(エクマ インターナショナル)という名称に名前を変えたそうです。このEcmaは略語ではなく、Ecmaで1つの名称であるとしたとのことです。
で、ECMAScriptやECMA-262をエクマと読むかイーシーエムエーと読むかという件ですが、どっちも間違ってないのでどちらでも良いのでしょう。
個人的には、欧州電子計算機工業会の略称として呼ぶとき以外にはイーシーエムエーとは呼ばない派(実質エクマ一本)です。

*1:ただ、[http://ja.wikipedia.org/wiki/Ecma_International:title=Wikipedia]レベルの知識なのでツッコミ歓迎

JavaScript連載第11回

JavaScript

これでできる！ クロスブラウザJavaScript入門の第11回はJSONP入門です。
いわゆるAjaxと呼ばれる範囲の一部で、少し高度な内容になる、と思わせてすごく基礎的なところを取り上げています。というか、数学に例えると「公式の使い方の説明ではなく、公式の導き方を解説した」といったところでしょうか。
特にJSONPがバッドノウハウであることが良くわかる内容になっていると思います。個人的にはバッドノウハウな部分を含めてJSONPは好きなので、もっとJSONPを褒めたいんですが仕方ないですね。