以前に擬似要素と擬似クラスにてCSS2の:beforeと:afterを用いてid属性値を示す、という活用例を書いた。今回はもっと思い切ってフルに活用し、HTMLの要素を浮き彫りにする利用法をテスト。いくつか記述忘れがあるかもしれないが、せっかくなので晒してみる。
big・smallが抜けている&非推奨ではない要素も非推奨要素に含まれているとの指摘を受け、修正。
/* all of content */
*:before,*:after{
color:#555; background-color:#fff; border:1px solid #abb;
font:normal normal 15px monospace; margin:0 0.3em; padding: 0 0.2em;
letter-spacing: 0; white-space: nowrap;
}
/* hn */
h1:before{content:"<h1>";}h1:after{content:"</h1>";}
h2:before{content:"<h2>";}h2:after{content:"</h2>";}
h3:before{content:"<h3>";}h3:after{content:"</h3>";}
h4:before{content:"<h4>";}h4:after{content:"</h4>";}
h5:before{content:"<h5>";}h5:after{content:"</h5>";}
h6:before{content:"<h6>";}h6:after{content:"</h6>";}
/* referance */
blockquote:before{content:"<blockquote>";}blockquote:after{content:"</blockquote>";}
q:before{content:"<q>";}q:after{content:"</q>";}
cite:before{content:"<cite>";}cite:after{content:"</cite>";}
address:before{content:"<address>";}address:after{content:"</address>";}
/* list */
ol:before{content:"<ol>";}ol:after{content:"</ol>";}
ul:before{content:"<ul>";}ul:after{content:"</ul>";}
li:before{content:"<li>";}li:after{content:"</li>";}
dt:before{content:"<dt>";}dt:after{content:"</dt>";}
dd:before{content:"<dd>";}dd:after{content:"</dd>";}
/* meaning */
abbr:before{content:"<abbr>";}abbr:after{content:"</abbr>";}
acronym:before{content:"<acronym>";}acronym:after{content:"</acronym>";}
em:before{content:"<em>";}em:after{content:"</em>";}
strong:before{content:"<strong>";}strong:after{content:"</strong>";}
bdo:before{content:"<bdo>";}bdo:after{content:"</bdo>";}
sub:before{content:"<sub>";}sub:after{content:"</sub>";}
sup:before{content:"<sup>";}sup:after{content:"</sup>";}
big:before{content:"<big>";}big:after{content:"<big>";}
small:before{content:"<small>";}small:after{content:"<small>";}
b:before{content:"<b>";}b:after{content:"<b>";}
i:before{content:"<i>";}i:after{content:"<i>";}
tt:before{content:"<tt>";}tt:after{content:"<tt>";}
/* RUBY関連要素(XHTML1.1以降) */
ruby:before{content:"<ruby>";}ruby:after{content:"</ruby>";}
rb:before{content:"<rb>";}rb:after{content:"</rb>";}
rbc:before{content:"<rbc>";}rbc:after{content:"</rbc>";}
rt:before{content:"<rt>";}rt:after{content:"</rt>";}
rtc:before{content:"<rtc>";}rtc:after{content:"</rtc>";}
rp:before{content:"<rp>";}rp:after{content:"</rp>";}/* technical term */
dfn:before{content:"<dfn>";}dfn:after{content:"</dfn>";}
pre:before{content:"<pre>";}pre:after{content:"</pre>";}
code:before{content:"<code>";}code:after{content:"</code>";}
kbd:before{content:"<kbd>";}kbd:after{content:"</kbd>";}
samp:before{content:"<samp>";}samp:after{content:"</samp>";}
var:before{content:"<var>";}var:after{content:"</var>";}
del:before{content:"<del>";}del:after{content:"</del>";}
ins:before{content:"<ins>";}ins:after{content:"</ins>";}
map:before{content:"<map>";}map:after{content:"</map>";}
area:before{content:"<area>";}area:after{content:"</area>";}
/* empty */
img:before{content:"<img />";}
br:before{content:"<br />";}
hr:before{content:"<hr />";}
/* table */
table *:before,table *:after{}
caption:before{content:"<caption>";}caption:after{content:"</caption>";}
thead:before{content:"<thead>";}thead:after{content:"</thead>";}
tbody:before{content:"<tbody>";}tbody:after{content:"</tbody>";}
tfoot:before{content:"<tfoot>";}tfoot:after{content:"</tfoot>";}
tr:before{content:"<tr>";}tr:after{content:"</tr>";display: table-cell;}
tr *:before,tr *:after{display: block;}
th:before{content:"<th>";}th:after{content:"</th>";}
td:before{content:"<td>";}td:after{content:"</td>";}
/* form */
form:before{content:"<form>";}form:after{content:"</form>";}
input:before{content:"<input>";}input:after{content:"</input>";}
button:before{content:"<button>";}button:after{content:"</button>";}
textarea:before{content:"<textarea>";}textarea:after{content:"</textarea>";}
select:before{content:"<select>";}select:after{content:"</select>";}
option:before{content:"<option>";}option:after{content:"</option>";}
optgroup:before{content:"<optgroup>";}optgroup:after{content:"</optgroup>";}
fieldset:before{content:"<fieldset>";}fieldset:after{content:"</fieldset>";}
legend:before{content:"<legend>";}legend:after{content:"</legend>";}
label:before{content:"<label>";}label:after{content:"</label>";}
/* other */
div:before{content:"<div>";}div:after{content:"</div>";}
span:before{content:"<span>";}span:after{content:"</span>";}
p:before{content:"<p>";}p:after{content:"</p>";}
a:before{content:"<a>";}a:after{content:"</a>";}
ちなみに、XHTML1.0Strictにおいては非推奨とされる要素は省いてある。あえて明示するなら以下のコードを足せばよい。ミスで含めていたbig要素・small要素・b要素・i要素・tt要素は削除。
/* XHTML1.0 Strictにおいて非推奨 */
font:before,basefont:before,
s:before,strike:before,u:before,
center:before,isindex:before,menu:before,dir:before,
font:after,basefont:after,
s:after,strike:after,u:after,
center:after,isindex:after,menu:after,dir:after{ color: #f00 !important;}
font:before{content:"<font>";}font:after{content:"</font>";}
s:before{content:"<s>";}s:after{content:"</s>";}
strike:before{content:"<strike>";}strick:after{content:"</strike>";}
u:before{content:"<u>";}u:after{content:"</u>";}
isindex:before{content:"<isindex>";}isindex:after{content:"</isindex>";}
basefont:before{content:"<basefont>";}basefont:after{content:"</basefont>";}
center:before{content:"<center>";}center:after{content:"</center>";}
menu:before{content:"<menu>";}menu:after{content:"</menu>";}
dir:before{content:"<dir>";}dir:after{content:"</dir>";}
「DTDに照らしてvalidか」をチェックするならばAnother HTML-lint gatewayがすでに見事な仕事をしてくれているけれど、「構造のシンプルさ」は点数で見直すことができない。しかし例えば上記のコードをユーザーCSSに仕込めば、普段見慣れた表示に開始タグ・終了タグを上書きして構造的にシンプルかを視覚的に即実感できる。ユーザーエージェントにどう認識されているかに想いを馳せるのも一興。
また制作者自身が自分のHTML文書記述法がどのようなものであるか、それに対しどのようなCSSをあてがっているかを直感的に再検討できる。positionプロパティやdisplayプロパティを使用して表示や配置をいじくっていると、不思議な画面になったり(例えばうちのデフォルトCSSではページ最上部にdt無しのddが表示されたり)する。
面白いじゃないですか。
インターネットがコンピューターや高速接続の枠を越え、街の通りやビルの壁にまでウェブページが広がったとしたら？
こんな発想から、新しい双方向型メディアプロジェクト『グラフィディア』(grafedia)が生まれた。世界を人々が表現するためのキャンバスに変えようという同プロジェクトは、人目に触れる場所に電子メールのアドレスやキーワードを書き込んでおき、それを見た人が、対応する携帯電話やパソコンを通じて電子メールを送信すると、そのキーワードに対応した画像その他のコンテンツが送られてくる(写真)というものだ。
便所の落書きという言葉が、Webの掲示板を揶揄する際に使われたりしていた。しかしマジもののの公園の便所からWebサイトへとリンクしていく情景は想像していると楽しい。ふと立ち寄った便所の中にアジビラなりグラフィカルアートなりがあって、気になったらフルブラウザ搭載携帯電話でアクセス、とか。つい最近購入したアバタールチューナーの「カルマ端末からマントラダウンロード」というノリが携帯電話で実際にできるやもしれん(あれはハッキングだけれども)。
あとは直接コンテンツと結びつけるのもありだけれど、RDFを用いればより機能的でスマートなリンクを表現できる。むしろこういう取り組みにこそもってこいじゃねぇか、と思ったり。RDFの活用はRSSを更新情報として、FOAFを自己紹介として利用する流れなんかで広まってきたけれど、もっと色々な発想がありうる。Geo metadata - 位置に関するメタデータとその応用とかでWebから便所へのリンクも実現されればより双方向的で、リアルで、わくわくするような気がする。そういえばQRコードなんてものもあるが、あれにもうちょっと美しいデザインを施す余地があれば、この手の広報と機能面で見事に合致すると思うんだけどな、おしいな。
と希望的観測を述べてきたけれど、もし広まれば携帯電話のセキュリティの穴やらデータの詐称、詐欺なんかも当然急増してしまったりするだろう。クソ重たいvirus対策ソフトやらなにやらを携帯が積むのも大変そうだし。
hiyokoyaさんの有害図書指定と優良図書指定とかの話に、影響論ってのはうだうだ...といったコメントを残したところ、僕の話の論拠となりそうな文章の紹介と突っ込みをセットで書いてくれた件(「暴力」の概念がいいかげんなのではなかろうか、という話。)について。
まず「暴力性」についての丁寧なリファレンスは僕にも参考になった。感謝。そして突っ込まれた部分については、これ以上僕の曖昧な文でコメント欄を埋め尽くしてしまうのは気が引けるので、こちらで書いておきたい。
が、ぶっちゃけた感想を言ってしまうと、これって理論系の人がいかにもやりそうなツッこみでもあるわけですね。そこそこの期間、人文・社会科学系の理論とかをかじっている人なら、多分既視感を覚えてしまうような。
ありふれた突っ込みと言われてしまうとどうしようもないけれど、僕が坂元氏について言及したのは、「ゲームをめぐる議論が影響論で埋め尽くされていくのは嫌だなぁ(注)」という文脈の上でだった(そのわりにだらだらと書き連ねてしまったのは僕の反省点)。そして坂元氏個人に関しては、教育云々とか家庭の取り組み云々とか余計なことを言わずに得意分野であろう実験・統計で信頼できる仕事をしてくれ
れば僕も文句は特にない。
しかも、何よりも悲しいことにこう突っ込まれたところで実証系の研究をやってる人たちの研究手法の具体的な改善につながるかどうか…というと、あまりつながらないことの方が多かったりするというのが経験的な話としてあったりします。つながれよ！とは思うものの、つながらない。「じゃあ、どういう方法論で研究をやれっつーのよ？」とか言われると、具体的な代替案がいまひとつ出しにくい。
確かに。しかし理論が実践現場での矛盾を踏まえて再検討されるべきであることと同じように、基本的には指摘を受けた側が代替案を練るのが妥当なのでは。もっとも問題意識を共有して共通の課題に取り組めているのなら、代替案を捻出することも指摘する人間の仕事に含まれる気はするけれど。お互い様なのを承知で書くが、僕はあまり坂元氏の議論に(ある種の効果は認めるものの)そういう気持ちを持てない。
メディアの中の読書行為において和田敦彦氏が影響関係を中心とした議論からは、ビデオゲーム経験自体がいったいどういったものなのか、といった問いがなされてこない
と述べているように、「影響が実証されたか否か」という論点はある種の分野(または立場)に限られたもの。しかしそうした議論が強い吸引力を持つと、前提を作るための本来ありうる幾多の議論が日の目を浴びなくなってしまう。だから坂元氏の議論の内容よりも、そうしたものばかりが目立つ(目立たされる)ことに問題を感じていた。
しかし、そもそもそうした状況が現れるのはまさしくゲームに関する人文・社会科学分野の立ち遅れが大本にある、とも思う。すでに立脚しているものを叩くより、やるべきことは他にあるという気もする。
僕のしたい議論ももっと書くべきだろうけれど、少し疲れたので小休止。僕も再プレイ中のガンパレードマーチで幻獣相手に「国家的暴力」
ふるってきます(笑)。
以前junk-style for SageなるユーザーCSSを公開したわけだけれども、これのDescriptionを非表示にしたバージョン(つまり:hoverを用いたややこしいコードのないもの)を作成したのであわせて公開しておく。いちいち告知するほどのものでもないけれど、CSSをまったくいじれない人とかも使うかもしれないし。導入手順やら関係各所の案内は、以前の記事Sage用ユーザCSS作成にて行っているので割愛。
以前のバージョンはRSS1.0、つまり「概要」提示するRSSの補足であれば特に問題ない(:hoverで概要を表示させてもそれほどCPUの負担にならない)のだけれど、RSS0.91、RSS2.0、さらにAtomなんかまでいっしょくたに扱うとなると、コンテンツそのものがマウス操作で浮かび上がるというわけのわからぬ事態が起きたりする。これだともう、CPUの負担はどうしようもないくらいひどくなるわけで。
今回はとりあえず2パターン出しておいて、もしうちのCSSを使うならば、どんなフィードをよく利用するかで選べるようにと思って作成した。Sageの制作者がFeedの形態によってCSSを割り振るまたは出力するHTMLを変更するなどの対処をしてくれればいいなぁ、と無責任な願望を持っていたりする。それがいいなら開発すべきとも思うけど、XBLはよくわからないので保留。
申し訳なさで頭がくらくらしてしまうURI変更も、似非プログラミングに頼っているから、なんだかんだと必要になってしまう。せっかくリニューアルしたけれど、niftyでcgi-binから動的生成させるのは負荷が半端なくかかる。ゆえにindexページのぞき、全ての記事はリダイレクトで静的コンテンツにつなぐことにする。多くの方を惑わしてしまうこの決定をしたのには、端的に言って以下の理由がある。
これではサイト制作があまりにもしづらい。というか、胃がきりきりしている。鬱々とコンピュータの前に座っている時間があまりにも長くなってしまった。正直、書きたいことを書くところの気分ではなかった。なまじ大学の春休みで、悩む時間もありすぎた。思えばクールなURIは変わらないの引用から制作開始していながら、ばりばりにクエリ文字列入りのURIを使ってきたことのツケが回ってきたのかもしれない。また同じくnifty鯖で雑記を公開中のブルーライトノヴァが、なにゆえにhpcgi*.nifty.comではなく、homepage*.nifty.comでの公開を選択していたのかをなぜ考えなかったのだろう。別に上記のような理由とは限らないけれど、最初から完全にHTMLファイルとして公開する道もあったはずなのに。痛恨のミスだったと思う。
そういうことで、うちのcgi-bin内のURLはいずれ移動するものと考えておいてください。個別の記事はすべて4月からリダイレクトかけます。でもこの方法の場合(4月以後表示速度の改善されるはずの)Webブラウザで来る方はともかくとして、アンテナには負担をかけて申し訳ない。あやまってもしょうがないけど、そう書くしかない。
…しかしこんなこと書いた後で自サイトをうろうろするとなんだか軽い。もう鯖のためか自分のPCの不調かもよくわからん…。でもQuery含んだURIの件もあるし、上記の宣言は決行したい…。ヒヨっている俺。だめだなぁ。イロイロと。
Perlを用いて似非Weblogを改築していたのだけれど、いじればいじるほど設計に不満が出てくる。現在は記事の一つ一つにタイトルをつけて処理しているので、形としてはそれぞれが独立したHTML文書として公開されていることになる。しかしこれがえらく負荷の高い話。一行程度のメモ書きも長文もいっしょくたのくせに、独立したオブジェクトとして扱っているから始末が悪い。タイトルを有したHTML文書ならば自動生成ではなく、拡張子を持つファイルとして公開すべきではないかと。
いちいちアクセスの度に鯖から全文出力させるのはあまりにniftyに申し訳ないし、文書をみなCGIに解釈可能な形で書くのも妙に不自由。少し、自動処理させるべきデータがどれだけあるかゆっくりと考え直したい。
たぶん(自サイトネタは「たぶん」ばかりだけれど)、この似非Weblogは似非のWeblogですらなくなる、すなわちWeb日記化することになると思う。Weblogという名乗り方もやめて、方向性をチャラに戻してみたい。
ちなみに再構築の際、RSS1.0のRDFファイルをリダイレクトかける方法がわからなくて(これだけ何故か静的コンテンツにしてしまい、cgi-binからではどうしようもないので)悩んでいます。誰かわかる方いたら是非ともご教授ください(涙)。最悪、文面でのURL変更連絡を行いますが…。その際は、補足してくださっている方々にゴメンナサイ、です。