冬コミ申し込みました
決済しただけですけどね。
26日までにサークルカットと発行誌名を決めないといけません。
日曜日に執筆陣を集めて第一回製作会議を行いました。
以下、決まったこと
- nooyoshさんが執筆者に参戦
- 原稿形式はtex*1
- Subversionでファイル管理
- 基本的には中高生が読める程度の文章にする*2
- 表紙はオライリーのパロでケモノと女の子(誰か描いて送りつけてください)
- 火曜日までにサークルカットと発行誌名
- 12月頭の完成を目指す
- 執筆者紹介欄にそれぞれの手の写真を加える
- 掲載候補のネタ
- その他執筆してもらいたい記事と執筆者の選定
- 来週までに概要の提出、執筆者の依頼
なんかまとめてみたらすでに候補記事のボリュームがすごいw
これ全部載ったらやばいですね。書いてみたい記事がある方は内容・分量問わず募集してますので、ご一報ください!今のところ配列系の話が多めですが、削ることは考えてませんしまだまだ増えても問題ないです!
それと、サークルカットをでっちあげたのでチェックお願いします。サークルカットにもいろいろ規定があって、カットが原因で書類不備で落とされるサークルもたくさんあるみたいなので、参加経験のある方とか見てもらえるとありがたいです。デザイン的にもツッコミいただけると幸いです。(キー部分がものすごいいい加減ですが、僕にはこれが限界です……)
実際はカタログとかに載るのでかなり小さくなります。
これくらい?
あとは発行誌名決めれば申し込み完了!!
冬コミタイピング本申し込みます!!
冬コミでタイピング本を出そう!! - tomoemonの日記
ノリで、と言いつつ協力者誰もいなかったらどうしよう……とビクビクしながら上げたエントリでしたが、思っていたよりもはるかにみなさんの関心が高くて驚きました。そして、すでに何人かの方から執筆やその他作業の手伝いを申し出てくる方がいらっしゃいますので、
冬コミ申し込みます!
というわけで、考えないといけないなーと思ってることと、手伝ってくれる方と相談したいことや先に伝えておきたいことをもろもろ。
サークル名
急募したらいくつか候補をいただきました。
- THE TYPING OF THE DOJIN
- TYPEかんせい(完成/感性/慣性)
- keyboard Mania(音ゲー勢釣り系)
- †漆黒の打鍵師†
- だけんおん!(旬のアニメあやかり系)
- 打つ病患者の集い
- タイピングガチ勢(シンプルイズベスト系)
下5つはぐみさんですね。瞬時にこれだけの名前を出せるそのセンスに脱帽です。
漆黒の打鍵師とか割と好みなんですが、ここはあえて直球の「タイピングガチ勢」で行きたいと思います。ガチタイパー勢ではないところにくすぐられました。今回の話を聞いて少し勘違いした人がいるかもしれませんが、今回書きたいと思っているのは必ずしもタイパーだけにとって利する内容ではないというのと、タイパーじゃないと書けない話の集まりというわけでもないです。
タイピングという行為を競技、ソフト、配列、キーボード、大会、人、教育、歴史といった様々な視点から語る、それはもうタイピングに対してガチで取り組んでないとできないことですし、そういう人達と協力して作っていきたいと思っています。すでに申し出てくれている人たちは十分にガチなのでそういう意味では名前負けしてないと思います。
って書くとまた敷居上がりそうですがw
ただの建前です!
記事を書いてみたい方はまだまだ募集していますのでよろしくお願いします。
サークルカット
絶賛募集中!!8/26まで!!
まあ、作ってくれる人はいないと思いますのでなんかでっちあげると思います。
ジャンル
たぶん、評論・情報とやらで3日目になりそうです。
ページ数・ボリューム見込み
50〜100?
これはまったく何も決まってません。今のところ記事の執筆協力を申し出てくれてる方が4人いるので、少なくとも5本の記事は作られると思いますが、それ以下になることもあるでしょうし、うまく行けばもっと書けるでしょう。
発行部数
これも具体的にモノができてから決めようと思いますが、タイパーの予約がそこそこ見込めそうなので、予約を取って、それプラス50とかそういう感じにしようと思います。
印刷形態
これも後から決めれば良いですが、とりあえず印刷所に持ってって印刷する予定です。
協力予定メンバー
記事を書いていただこうと思っている人たち
- mikonyan(みこやん)さん
- vuttar(テル)さん
- x_i(W/H)さん
- y_koutarou(kouy)さん
- tomoemon
絵を書いてもらえる?
- enbukushi(炎舞寺)さん
その他協力申し出ていただいた人たち
- 933(ぐみ)さん
- remotibi(レモチビ)さん
- ymcm_na(美琴)さん
- 716cream(クリーム)さん
協力の申し出ありがとうございます。
びしばし馬車馬のように手伝ってもらおうと思います!(違
記事のネタ、分量、担当者
現状ざっくり決まっているのは
あたりでしょうか。僕が何の記事書くのか何も決めてませんでしたが。
このあたりも詳細は担当メンバーで話しあって決めようと思います。
広げた風呂敷の割にはカバーできているネタが狭いので、まだまだ書いてみたい方募集中です。
キックオフについて
以下、基本的に執筆者向けの話です。
最初に意思統一というか、どういうネタを書くか、ここはどうするのか、みたいな話をしたいので、日取りを決めてSkype等を使ってミーティングをしたいと考えています。時間の都合があえば今週末の土日のどちらかを考えています。
会計
お金まわりの面倒は避けたいので、印刷代は全部僕が出します。
黒字になったらタイピングオフなりで還元します。
手伝い報酬
最初に原稿を手にできます!
あとは……達成感?
お金は出ませんよと念のため書いておきます。
タイパー向け?一般向け?
この前のブログで一般人にも〜的な話を書きましたが、そもそも「一般人」とは何かを定義することが難しいので、すべての記事が誰にでもわかるように!ということは考えていません。
今のところ筆者の書きたいように書いてもらうのが良いと思っています。あまりにニッチでマニアックなところは解説を加えるなどの修正を入れるかもしれませんが、こういう本の場合、マニアックゆえの面白さもあると思うので、そこは相談の上決めます。
原稿フォーマット
wordとかtexとか。texでフォーマット決めてしまえばきっちりした形式にまとめるのは楽っちゃ楽です。レイアウトに凝るのでなければ、執筆者からはテキストだけ受け取ってtexのあれこれを僕がやるというのも一つの手です。ただ、レイアウトを凝りたい人がいるとちょっと難しそうです。まあ、これも執筆者の書きたいもの次第なので要相談。
記事の形式
- このブログのような文章
- キャラクター対話
- インタビュー
- アンケート
などなど。僕が普通にやると全部固い文章になっちゃいそうなのですが、それは避けたいです。インタビューはすでに一つ盛り込んでいますが、その他の記事の構成や見栄えについても行間広めを意識して作っていきたい(意識しないと論文誌みたいになりそうなw)ので、そういう案のある方はどんどん提案お願いします。
記事の完成までの流れ
キックオフのあとに、早めの締切を作って執筆者に100〜200字程度の概要を作ってもらいます。執筆者同士でそれぞれどういうものを書くか確認して、膨らませそうであるとか、関係しそうであるとか、全体像を把握します。記事の形式についてもこのときに決めます。また、このタイミングでその他のネタの執筆依頼を投げたりするかもしれません。協力が得られそうなら挿絵についても、このタイミングで先に決めておきたいです。
その後、個人で書けるネタについてはそのまま書いてもらいます。はじめはレイアウトとかにこだわらずに内容を考えて欲しいと思います。インタビューやアンケートなど他者に協力を依頼するものについては、いったんインタビュー内容やアンケート項目を作ってもらい、確認してから依頼先に投げてもらいます。
記事が上がってきたら、各自時間のあるときに他の執筆者の草稿をレビューします。個々の記事のレイアウトについてはこのあたりで考えればよいと思っています。
草稿とかの扱いについて
基本的にクローズドでお願いしたいと考えています。要素要素について例えばブログなどに書いて意見を募るといったことはもちろん構わないですが、まるまる上げて見てください、というのは遠慮していただきたいです。
全部の記事を先に上げてしまうとできあがったときの面白みに欠ける、というのもありますが、たくさんの意見をもらえることで必ずしも記事作成に良い影響を与えない、いろんな意見に左右されて書こうと思っていたものが書けなくなってしまう、というのが少し心配です。
これについても初めに相談しようと思います。
チケット管理やらバージョン管理やら
協力作業していくときに定番な便利システムがあったりするので、どういうの使っていくかという話です。バージョン管理は以前の版からどう変わったのか確認したりするのに使えますし、チケット管理には各人の担当作業を確認したりします。誰かが草稿をレビューしたときの内容を確認しやすくする、とかそういうのもあった気がします。
挿絵・表紙どうする
記事の形式にも関係する話で、挿絵とかパラパラっと開いた時の見栄えはかなり大事なので、積極的に入れていきたいです。たくさん書いてもらえればそれが一番ですが、そういう素材を探したり、執筆者が何とかする、というのが現実的。
表紙も悩みどころですが、たぶん後からなんとでもできそうなところです。
宣伝
できあがる前から宣伝も何もないですね。
できあがるころに考えましょう。
落ちたらどうすんの
というかまあ割と高い確率で落ちると思います。ただ、知り合いで委託できるところはありそうですし、なかったとしてもタイピング関係者に見てもらう、という形で良いと思うので本は作るつもりです。
という感じでまだまだ決まってないことだらけですが、なんとか進行していく予定ですのでよろしくお願いします。
冬コミでタイピング本を出そう!!
夏コミ参加の勢いでとりあえずぶちあげておきます。といっても申し込み締め切りがすぐ(8/22)ですし、一緒に書けそうな方が見つからなければ諦めるか、とりあえず申し込むかします。
書きたい、(誰か)書けそうなネタ
- 競技タイピング的攻略
- 上記ソフト+毎パソ、ニコ生タイピングなどに関して
- 入力最適化話
- 英文タイピング
- 日本語入力との違い
- 海外勢との競争とか
- タイパー列伝
- 偉大な記録を残したタイパー
- 最速のタイパーは誰だ的ネタを真面目に書けると面白そう
- タイピング界年表
- タイピングソフト、サイト
- タイパー
- キーボード
- キーボード配列
- タイピングゲーム話
- タイピングゲームの変遷
- 求められる機能(アンケートとか百質とか)
- 単語自由登録系:打トレ/ウェザタイ/八重タイ
- 自作系:tsuikyo
- タイピング考察
- ここまでの話に入らないような考察ネタ
- タイピング界コミュニティ
- ソフトごとのコミュ
- 全日本タイピスト連合
- 2ch
- 海外勢
- タイピングオフのあれこれ
大体こんな感じのことは書けるかなーと思ってます。読者は基本的にタイパーを想定していますが、一般人が読んでタイピング界とかタイパーってのはこういうもんなんだな、という雰囲気がつかめる本が書けると良いなと思っています。大枠はわかりやすそうなテーマで区切ってます。それぞれのテーマで重複する部分もありますが、かぶってもたぶん問題ないです。こんなテーマは?とかこんなことなら書けるというの募集中。
本を作るにあたって考えてること
本を作りたいと思ったのは半分以上ノリですが、過去にw/hさんがコミケに出していること、今ならtwitter上でタイパーの協力が得られたりするかもという期待があること、自分の観測できる範囲だけでもすでに10年以上の歴史があるタイピング界のまとめや成果的なものがあったらいいな、とかそんなことを考えていました。
理想的にはタイピング界全体を過去から現在まで俯瞰したようなものが作れると面白いのですが、あまりにも大風呂敷すぎるので、おそらく相当な手間をかけた上で余程の好機と幸運に恵まれないとたためません。ただ、本の作成が継続的になって最終的にそういうものになっていっても良いと思っています。
なので今回も書けるもの、残せるものを書いていくという少しゆるめな感じで考えています。
ブログやwikiで協力してまとめる、というやり方もありますが、あえて本という形式を選択するのはその方がより質の高いものに仕上げやすいと考えてるからです。単純に言えば本のほうが強制力が高い。まず、締切が存在すること、そして印刷費その他もろもろかかるのでどうせ出すなら質の高いものにしようという意識に持って行きやすいだろうと考えてます。
逆に言えば他の人と協力してやること前提なので、スケジューリングとかで苦労することは確実なのですが、それでも内容の充実と質の向上を考えればそこはどうにかしたいところです。
というわけでこんな感じのタイピング本を作ることに興味のある方募集します。僕のブログとか見てる方は、どういう感じのものを作りたいかなんとなくイメージできるかなと思います。タイパーカプ的な記事は僕は書けないですが、記事を書いてくれる人がいればどんどん採用したいですね(´ε` ) それから、記事を書いてもらえればもちろんありがたいですが、記事を書く以外にもいろいろやることがあるので、そういう手伝いとかやってくれる方いると嬉しいです(表紙絵とか表紙絵とかサークルカットとか)。twitterの観測範囲内とかでそれっぽい発言を見つけたら勝手に捕捉していきます!
個別にDMとか送って打診するかもしれませんがよろしくお願いします。
そんなすごいものができなくても良いけど、本を作るということ行為自体がわりと日常からかけ離れてるので、なんかすごい感じのイメージになってしまう。軽いノリで行きたいけど軽いノリにしづらいところですね。まあ、なんとなく面白そうと思ったら手伝ってくれると嬉しいです!
スーパーバルブ導入!
しばらく前から自転車の空気が徐々に抜けていく症状が出ていて、1週間で抜けて空気を入れ直したら次は3日で抜け、次は1日で抜け、最後は空気ポンプを外した瞬間に空気が漏れ出すという状態でした。
で、明らかに空気の抜け方が普通のパンクと違ったので、バルブを抜いてみたらこんな状態でした(画像左が問題のバルブ、右は正常な状態のバルブ)。
これまでの自転車生活の中でいろんなパンクを経験しましたし、走ってる最中にパーン!!とバーストしたこともありましたが、バルブが原因ってのは初めてですね。まあ、気づかずにチューブごと交換したこともあったかもしれませんが、はっきりバルブが原因とわかったのは初めてでした。
そもそもバルブの構造がどんなのか知らなかったのですが、あらためて調べてみると、このゴムの部分で空気の逆流を防いでるようで、ゴムが劣化して外れたりすると逆流を防ぐことができず、入れたそばから空気が抜けてしまうとのことでした。
で、このバルブなのですが写真の形のものはもともと耐久性が低く、結構な頻度でダメになってしまうらしいのです。ゴムの部分だけ交換することもできるのですが、まったく別の構造で耐久性の高い製品もあるというじゃないですか。
それが、スーパーバルブ!!
スーパーバルブ(自転車用新型英式バルブ) を使う 【Takaよろず研究所】
(一番右側のスーパーバルブゴム型というやつです)
100均でも売ってるらしいのですが、近くに大きな100均がなかったので自転車屋で300円で2個入りを買ってきました。従来品に比べてゴム部分が小さくすっきりしてて良い感じです。バルブを付け替えて空気を入れ、無事に復活しました。
シティサイクルの後輪のタイヤは外すのが結構面倒くさいので、バルブの交換だけで済んで助かりました。ロードレーサーのクイックリリースに慣れちゃうと、もう後輪外すとかやりたくないんですよね……。
新しい価値観と自分探し
「新しい価値観を見つけたいんだ」
先日、ふとそんなことを言われて「へっ?」って変な顔になった。
価値観って単語自体はよく使われるし別に珍しいものでもないが、新しい価値観を見つけたい、というのは一体どういうことだろう。そんなこと考えたこともなかったので、その場ではなんとも言えなかったのだけど、なんかひっかかったのでちょっと考えてみた。
ぼんやりとした抽象的な話になるのであしからず。
まず価値観とはなんだろう。
これは別に難しくない。自分にとって何(ヒト・モノ・コト)が大事で、何がどうでもいいかっていうモノサシだ。人は大事な何かのために行動するから、価値観とは行動原理であると思っている。人の活動を本能(意識しない活動)によるものと理性(意識した活動)によるものに分けるなら、理性の活動とはすなわち現状を価値観という基準で測った上で、より良い指標になることを目指すための活動と言えるだろう。
この「より良い」がモノサシである価値観によってバラバラなので、「価値観は人それぞれだよー」なんて言葉がよく使われるが、あまりに自分とは異なる方向を向いてるモノサシだったり、変な形のモノサシの持ち主に出会うと許容範囲を超えて「そんなアニメとかフィギュアとかいい加減卒業したら?」なんてことになったりして衝突する。
価値観はその人の行動の基準になるので、今現在の「自分」を表すものであると言える。さらに、価値観が過去から現在までの経験に基づいて作られる、ユニーク*1なものであることから「自分」そのものであると言っても過言ではないと思う。同じものが好きという人に出会うことは十分ありうるが、すべての物事の好き嫌いがまったく同程度ということはありえない。価値観を単純な方法で表現するなら、あらゆるヒト・モノ・コトのそれぞれについて好きな度合いを0〜1の実数の要素として持つベクトルになるだろうか。2値にしたとしてもまったく同じ価値観の人に出会うことはないだろう。
さて、価値観が自分そのものであると言えるなら、
新しい価値観を探すというのは新しい自分を探すことをほぼ同義である。
自分探しと言い換えるとわりと耳慣れた言葉になるが、残念ながら僕は自分探しをしたいと思ったこともない。就活の時に自己分析とやらをするらしいが、まああれも自分探しの一種だろう(やらなかったけど)。先ほどの価値観の表現例で言えば、自己分析はこれは好きか嫌いかという項目がいっぱい入った表を埋めていって誰が見てもはっきりさせる作業だと思う。ぼんやりしているモノサシの形状をはっきりさせる作業と言ってもいいかもしれない。
僕は自分が何を好んで何を好まないか大雑把にわかってればいいし、基本的に自分の次の行動を決める上で自分の持つモノサシで判断に困ることがあまりない、というのが自分探しをしたいと思わない理由なんじゃないだろうか。どこにあるか分からない新しい自分を求めるよりは、今の自分の価値観の先に存在する理想の自分になる方が、少なくとも今の僕にとってはずっと価値のあることに思える。
価値観が持つ価値という話を出したが、人が持つ価値観そのものを評価することはできるだろうか。さっきの好き嫌いを1/0で表したときに1が多い方が良い、とかそういうものである。別に僕は何でもかんでも好きという人の価値観が良いとは思わないが、そう感じる人もいるだろう。それもまた価値観の一つに違いない。
僕は値の入っている項目の数で価値観の持つ価値が変わるかもしれないと思っている。例えば死ぬまで家の中で過ごした人が接したヒト・モノ・コトはそうでない人に比べて少なく、知らないものに対する好き嫌いは付けられないので、価値観テーブル*2は小さいままになってしまうだろう。逆にいろんな社会、世界に属している人は様々なことを知っていて、大きな価値観テーブルを持っていると思われる。
別のイメージで捉えると、価値観は自分と世界をつなぐ神経みたいなものだろうか。世界を知れば知る程自分と世界をつなぐ神経は増えて、いろんな情報のやり取りが発生する。好きなものにつながっている神経はたくさん情報をやり取りして、嫌いなものにつながっている神経はあんまり活性化しないようにする。そんなイメージ。
新しい価値観を見つけるというのが、自己分析(今の自分を価値観の表を埋める作業)ではなく、すでに値の埋まっているテーブルに加える新しい項目を探しに行くこと、と考えると僕もやぶさかではないかもしれない。新しい価値(あるものないもの)を知ることで、すでに持っている価値観を別の視点から見ることができ、より信頼の置けるモノサシになるのではないかという可能性を考えたりもする。
話があっちこっち行ったけど、書きながらなんとなく自分が納得したのでおしまい!
で、最近ちょうどこんな本を買ったばかりだったりする。
割とどうでもいいけど、森さんはこの本を12時間程度で書いたらしい。僕はこの記事を1時間半かけて書いたわけで……森さんぱねえ。
奈々さん東京ドームライブキタ━━━━(゚∀゚)━━━━ッ!!
久しぶりのライブ!久しぶりの奈々さん!
SCARLET KNIHGTからの!ETERNAL BLAZEからの!十字架のスプレッド!
最初っから最後まで全力全開でしたねー。誇張抜きで汗だく。
30分ぐらいがしがしバイクこいだのと同じくらい汗かいた気がしますw
いい汗かいたところで最後の奈々さんからの発表がこれ。
404 Not Found
東京ドーム公演ついにキタ━━━━(゚∀゚)━━━━ッ!!
ちなみにwikipediaにこんな項目があるんですけど
東京ドームコンサートを開催したミュージシャンの一覧 - Wikipedia
実現したら7人しかいない女性ソロミュージシャンリストに仲間入りですね!!
さすが奈々さん!!!
はー楽しみすぎる( ´∀`)
サイ本15章ドキュメントの制御
友達と一緒に読み進めて気づいたら15章まで来てました。
第13章第2部以降はJavascriptの言語そのものではなく、ブラウザ実装におけるJavascriptの話です。例えばサーバサイド実装であるNode.js等には関係のない話ですが、Javascriptを語る上でブラウザ上のクライアントサイドスクリプティングは避けて通れないので、ある意味ではこれまでより重要な章になります。
ブラウザにおけるJavascriptで特に重要なのがこの章のDOMの話で、静的なhtml構造を動的に解釈・操作するための基礎知識になります。DOM自体はJavascriptの実装に依存するものではなく、xmlやhtmlドキュメントを操作するためのインターフェースとしてW3Cで定義されているもので、他の言語からこれらのドキュメントを操作する上でも役に立つ知識です。
では前置きをこのくらいにして
「ドキュメントの制御」……ドキュメントって?
この章のタイトルで指している「ドキュメント」はJavascriptで言う
window.document // windowはグローバルオブジェクトなので以下の形でも参照できる document
を指しています。このオブジェクトを操作することで、ページ内のすべての構造や要素を変更することができるようになります。その核となる(DOMを表す)プロパティがdocument.documentElementですが、ここでは先にそれ以外のプロパティを見ていきます。
document.* プロパティ
レガシーなプロパティとして紹介されているものとして以下のようなものがあります。レガシーと言いつつ、bgColor以外は基本的には現在でも使うものです。
- document.bgColor
- ページ全体の背景色を表す。使うな
- document.cookie
- cookieの取得や操作。普通に使え
- document.domain
- 現在のページのドメインを取得、または同一出身ポリシー制限を緩和するために設定する(後述)
- document.lastModified
- ドキュメントの最終更新日。htmlファイルであれば通常そのファイルの更新日。動的ページの場合はwebサーバが出すLast-modifiedヘッダの値(参考)
- document.referrer
- リファラURL(このページに来る前にいたURL)
- document.title
- 現在のページタイトル
- document.URL
- 現在のページのURL(リダイレクトされた場合はリダイレクト後のURL),document.location.href(リダイレクトされた場合はリダイレクト前のURL)
document.domainはあの説明じゃ分からないと思うので、軽く説明を。以下のようにhostA, hostBと2つの異なるホストでサイトを運営している場合に、それぞれのサイト間で動的に連携したい場合を想定しています。
- hostA: home.exmple.com
- hostB: catalog.example.com
hostAからロードされたスクリプトがhostBのドキュメントをロードしたい
→同一出身ポリシーに違反する(document.domainが異なる)のでダメ
そんなときにそれぞれのdocument.domainを設定します。
document.domain = "example.com"; // 指定できるのは元々のdomainのサフィックス、かつピリオドを1つ以上含む文字列
レガシーDOM
DOMはドキュメントを操作するためのインターフェースと初めに言いましたが、現在DOMと呼んでいるものは基本的にW3Cで標準化されているDOMを指しています。ここでは、標準化される以前に使われていたものを超簡単に紹介します。ググったときに出てくる古い紹介ページなどで見かけたら( ´_ゝ`)フーンと思ってください。
- document.anchors[]
- anchor(aタグのname属性)リスト
- document.applets[]
- javaアプレットリスト
- document.forms[]
- formタグリスト
- document.images[]
- imgタグリスト
- document.links[]
- link URL(aタグのhref属性)リスト
最初から配列として取得できるのは便利な面もありますが、W3C DOMではこれらを一般化してより柔軟に操作できるようになっているので、今後は基本的に使わないほうが良いでしょう。
W3C DOM
さて、ようやくW3C DOM(以下単にDOMと書きます)です。DOMを大雑把に言うとツリー構造で表現できるドキュメントを操作するためのインターフェースです。そして、現在ツリー構造で表現するドキュメントと言えばxmlとかhtmlです。pythonやphpといった様々な言語でdomを扱えるライブラリが存在していますが、それらは基本的にこの共通のインターフェース定義に基づいて実装されています(はずです)。
document.documentElementがツリーのルートを表しており、その下は以下のようにご存知のhtmlタグがツリー上に並びます。bodyだけなんかショートカットがありますが、一般的にDOMを操作する上でよく使うのがhtmlの中のbodyだから、というだけの理由みたいです。
一つ一つの要素はすべてNodeであり、特にhtmlのタグを表す要素についてはHTMLElementノード、テキストデータを表す要素についてはTextノードのインターフェースを実装したオブジェクトになっています。DOMにおけるインターフェースの関係を一部抜粋すると以下のようになります。
Nodeには自分の前に一つ要素を追加するinsertBeforeや、自分の子要素に追加するappendChildといったツリー構造を操作する汎用メソッドが用意されています。HTMLElementは単にhtmlタグ全体に共通で定義されているid,styleといった属性のプロパティが追加されているだけなので、基本的にはDocument, Node, Elementあたりを把握しておけば十分でしょう。
だらだらと書いてきましたが、具体的にどんなコードになるかというとこんなコードです。
// ノードの取得 var n = document.documentElement; // htmlタグを表す var children = n.childNodes; // head, bodyノードのリスト var body = children[1]; // ノードの作成・挿入 var t = document.createTextNode("text node"); body.appendChild(t);
別に大したことはありませんね。HTMLのツリー構造をイメージできれば問題なく使えるはずです。他にどんなメソッドが使えるかは、W3Cの定義をご覧ください。DOMには1から3までのレベルがあり、ここで話した内容についてはDOM Level1で十分です(レベルはバージョンとは違い、ライブラリ側でどこまでを実装するかという話なので、Level 1が古いといったわけではありません)
Document Object Model Core
なぜここでインターフェースの詳細を紹介したくないかと言えば、もうDOMの操作なんてjQuery使えばいいじゃん、と言いたいからです。createElement, getElementById, getElementsByTagName, getElementsByNameといったメソッドは当然jQueryの内部で使われているわけですが、こんな長い関数名をだらだら打って覚えるくらいだったら、jQueryのメソッドの使い方を1つでも覚えたほうがスマートにDOMを操作できます。
というわけでぶん投げて以上!
おまけ:document.write
Javascriptでhello worldといえば、おそらく以下の形で書くと思います。
document.write("hello world");
ご覧のとおり document.write は簡単に動的な出力を実現することができる便利関数ですが、この関数は使い方によってはちょっと曲者なので解説しておきます。
大事なこと
document.writeを使ってページ内に何を出力できるのはページ読み込みと同時に実行できるscriptのみ。イベントハンドラによってdocument.writeを実行すると、ページが真っ白になってしまう。
わかりづらいと思うので、例を書きます。
問題ない例
<html> <head></head> <body> <script> document.write("hello "); </script> world </body> </html>
hello worldと表示されます。
問題ある例
<html> <head></head> <body> <button onclick='document.write("hello ")'>click</button> world </body> </html>
ボタンとworldだけが表示されている状態でボタンをクリックすると、真っ白い画面に hello とだけ表示されます。
document.writeの謎
なぜこういうことになるのか、Javascriptで新しいウィンドウを作成してその中に文字を出力する例を見て考えてみましょう。以下の例では、新しいウィンドウを作成してその中に Hello World!と表示しています。
function hello() { var w = window.open(); var d = w.document; // phase1 d.open(); // phase2 d.write("<h1>Hello World!</h1>"); d.close(); // ドキュメントを閉じ、画面に表示される // phase3 }
先ほどの「問題ない例」はhtml"出力中"の document.write であり、上記の phase2 で実行した場合に相当します。一方「問題ある例」はhtmlの出力が終わった(closeされた)後のイベントハンドラによる document.write であり、上記の phase3 に相当します。さて、ここからは document.write の仕様ですが、1度 close された document 上で document.write すると、出力する前にその document を再度 open します。そして、open するとその document はまっさらな状態になるため、結果的に真っ白な画面に指定した文字列だけが寂しく残る、という表示になるのです。