<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>agenda</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/" />
    <link rel="self" type="application/atom+xml" href="http://jintrick.net/agenda/atom.xml" />
    <id>tag:jintrick.net,2007-11-17:/agenda//1</id>
    <updated>2009-01-05T23:15:56Z</updated>
    <subtitle>Jintrickの公開メモ帳</subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Publishing Platform 4.01</generator>

<entry>
    <title>ウェブブラウザなんかに気を遣わなくてもいい理由</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2009/01/post-440.html" />
    <id>tag:jintrick.net,2009:/agenda//1.1331</id>

    <published>2009-01-04T15:42:59Z</published>
    <updated>2009-01-05T23:15:56Z</updated>

    <summary>いつの間にか2009年になってしまった。 IE6に気を使わなくてもいい理由とか「...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="ウェブデザイン" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<p>いつの間にか2009年になってしまった。

<p><a href="http://anond.hatelabo.jp/20081217175821">IE6に気を使わなくてもいい理由</a>とか「そういう系」
の話を聞くと、なんで非営利個人サイトが自分の嫌いなウェブブラウザなんかに一々気を遣わなきゃならないんだとか思う。もちろん気を遣うのには色々理由があるだろう。だが「気を遣わなくてもいい理由」というのもあっていいんじゃないか。そう思ってだらだらと悪文を書いてみた。本当に悪文だからまとまりはないよ。

<h2>相手にしていられないほど膨大な種類の「ウェブブラウザ」</h2>

<p>この文脈においてはウェブブラウザではなく、所謂レイアウトエンジンやHTMLパーサの種類を把握すべきだろう。たとえばSleipnirもfubも、同じMSHTML.dllを利用しているなら一つとしてカウントできる。

<table><caption>ウェブページのレイアウトエンジン</caption>
<thead>
	<tr><th>レイアウトエンジン等の名称<th>主なバージョン（2009年1月現在）<th>応用しているプロダクト他
<tbody>
	<tr><td><a href="http://msdn.microsoft.com/en-us/library/aa741317.aspx" title="msdn内 MSHTML Reference">MSHTML（Trident）</a><td>4.0系, 5.0系, 5.5系, 6.0系, 7.0系, 8.0系（系統別に多数あり）<td>Internet Explorer（Windows版）、IEコンポーネントブラウザ各種
	<tr><td>Tasman<td>未調査<td>Internet Explorer 5 for Mac
	<tr><td>Gecko<td>1.9.1まで多数あり<td>Firefox他のMozilla系ブラウザ
	<tr><td>KHTML<td>未調査<td>Konqueror、KHTMLはWebkit他のレイアウトエンジンのベースにもなっている
	<tr><td><a href="http://directory.fsf.org/project/gtkhtml/">GtkHTML</a><td>3.0.10<td>Evolution他GTK+アプリケーション
	<tr><td><a href="http://webkit.org/">WebKit</a><td><a href="http://nightly.webkit.org/" title="WebKit Nightly Builds">r12084～r39572まで多数あり</a><td>Safari, Epiphany, Google Chrome, Omni Web, Adobe Dreame Weaver CS4, Adobe Air他
	<tr><td><a href="http://en.wikipedia.org/wiki/Presto_(layout_engine)" title="Presto (layout engine) - Wikipedia, the free encyclopedia">Presto（Opera）</a><td>2.2まで<td>Opera（7以降）, Nintendo DS Browser, Internet Channel（Wii）他
	<tr><td>iCab<td>未調査<td>iCab 1-3
	<tr><td><a href="http://www.princexml.com/">Prince XML</a><td>未調査<td>Prince XML（CSS対応レンダリングエンジンを搭載したPDF変換プログラム）
	<tr><td><a href="http://www.boxely.com/">Boxely</a><td>未調査<td>AOL Explorer、他AOL系ブラウザ
	<tr><td><a href="http://www.access-company.com/products/internet_appliances/netfrontinternet/internet_appliances.html">NetFront</a><td>未調査（多数の系統あり）<td>i-mode、 PSP、Dreamcast他
	<tr><td><a href="http://www.netsurf-browser.org/">NetSurf</a><td>未調査<td>NetSurf
	<tr><td><a href="http://www.levien.com/gzilla/">Gzilla</a><td>未調査<td>製品未調査（<q cite="http://www.levien.com/gzilla/">Gzilla is a web browser written in the Gtk+ framework</q>とのことなので個人開発は多数ありそう）<td>
	<tr><td><a href="http://tkhtml.tcl.tk/index.html">Tkhtml</a><td>未調査<td>Hv3などのTkアプリケーション
	<tr><td>HTMLayout<td>未調査<td>参照：<a href="http://en.wikipedia.org/wiki/HTMLayout">HTMLayout - Wikipedia, the free encyclopedia</a>
	<tr><td><a href="http://links.sourceforge.net/">Links</a><td><a href="http://www.jikos.cz/~mikulas/links//download/" title="Links downloads">0.80～0.99まで多数あり</a><td><a href="http://links.sourceforge.net/">Links</a>の他、 応用した<a href="http://elinks.or.cz/">ELinks</a>、<a href="http://links.twibright.com/" title="Twibright Labs:  Links">Links(2)</a>、<a href="http://xray.sai.msu.ru/~karpov/links-hacked/">Links Hacked</a>がある
	<tr><td><a href="http://lynx.isc.org/">Lynx</a><td>2.8.6まで<td>Lynx
	<tr><td><a href="http://w3m.sourceforge.net/">w3m</a><td><a href="http://sourceforge.net/projects/w3m/" title="SourceForge.net: w3m">0.5.2まであり</a><td>w3m、w3m-mee
</table>

<p>この他にもいくつかあるが、無名なアプリケーションしかないものは除外した。Javascriptエンジンはまた別だったりする場合がある。また、スクリーンリーダーもここでは除外している。要するに、HTMLをパースする（そしてレンダリングする）ソフトウェアは、<strong>数えきれない</strong>。

<p>こんなものに一々一々気を遣っていられない。実際に「気遣い」できるのは本当に極一部の、メジャーなブラウザだけだろう。そのメジャーなブラウザだって1年や2年で変化していくのだから、気を使う「必要」はないだろう。とりあえず<strong>HTML文書が壊れていないことを確認</strong>すれば、あとはソフトウェアが適当に処理してくれるのを信じるしかない。何かとバグがつきもののCSSだが、凝ったことをするのなら、自分が確実に確認できるレンダリングエンジンに対してのみ適用されるような配慮をすればいい。

<h2>ウェブブラウザに気を遣わずに済む方法</h2>

<p>極論すれば、CSSやJavascriptなんか<strong>使わなければ</strong>ブラウザに気を遣う必要は激減するわけだ。これは「すっぴん」で公開しろと主張するわけではなくて、先述したとおり、自分が確実に確認できる、あるいは確認するレンダリングエンジンに対してのみ、CSSやJavascriptが有効になるような配慮をすればいい。そういう配慮が不可能なレンダリングエンジンに対しては、「すっぴん」でいいんじゃないかと。

<p>私の場合、UTF-8を扱えないソフトウェアを完全に蹴るという政治的判断はあるものの、それ以外の部分では上述したような方針を取ってできる限り互換性を追求したいと思っているので、いつかやると思う。

<div id="LINKS">
<h2>参考文献</h2>
<ul>
<li><a href="http://www.powerset.com/explore/semhtml/Comparison_of_layout_engines_(Cascading_Style_Sheets)">Comparison of layout engines (Cascading Style Sheets) - Powerset</a>
<li><a href="http://www.powerset.com/explore/semhtml/Comparison_of_layout_engines_(Document_Object_Model)?query=gecko+webkit">Comparison of layout engines (Document Object Model) - Powerset</a>
<li><a href="http://en.wikipedia.org/wiki/Comparison_of_layout_engines">Comparison of layout engines - Wikipedia, the free encyclopedia</a>
<li><a href="http://en.wikipedia.org/wiki/List_of_layout_engines">List of layout engines - Wikipedia, the free encyclopedia</a>
<li>他
</ul>
<h2>更新履歴</h2>
<ul>
<li>TrasmanをTasmanにtypo訂正（<a href="http://b.hatena.ne.jp/waverider/20090105#bookmark-11532691">waverider</a>様よりご指摘あり）
</ul>
</div>
]]>
        
    </content>
</entry>

<entry>
    <title>p要素の終了タグを省略する際の注意点</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/12/p.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1330</id>

    <published>2008-12-12T05:54:09Z</published>
    <updated>2008-12-12T05:57:10Z</updated>

    <summary><![CDATA[HTML4.01ではp要素の終了タグ「&lt;/p>」は省略することができるよう...]]></summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="HTML" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<p>HTML4.01ではp要素の終了タグ「<code>&lt;/p></code>」は省略することができるようになっている。数ある省略可能なタグの中で、最も気を付けなければならないのがこの「<code>&lt;/p></code>」。

<h2>DTDの再確認</h2>

<p>まずスキーマを見てみる。p要素の内容モデルを確認するのに必要なのは次の箇所：

<blockquote cite="http://www.w3.org/TR/REC-html40/sgml/dtd.html">
<pre>&lt;!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body --></pre>
<pre>&lt;!ELEMENT P - O (%inline;)*            -- paragraph --&gt;</pre>
<pre>&lt;!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;"></pre>
<pre>
&lt;!ENTITY % fontstyle
 "TT | I | B | BIG | SMALL">

&lt;!ENTITY % phrase "EM | STRONG | DFN | CODE |
                   SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >

&lt;!ENTITY % special
   "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">

&lt;!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">
</pre>
</blockquote>

<p>つまり、終了タグを省略することができ、ins, del, %inline;以外を内容に持つことができないというわけだ。しかし<strong>実装は異なる</strong>。

<p>この仕様を正しく実装するなら、次のような処理が必要だ:

<ul>
	<li>1. 当該p要素の開始タグが現れ、その終了タグが出現するまでの間に、p要素の内容として許されない要素が出現したとき、当該p要素を終了させなければならない
	<li>2. 当該p要素の開始タグが現れ、その終了タグが出現するまでの間に、当該P要素の親要素の終了タグが出現したとき、当該p要素を終了させなければならない
</ul>


<h2>1. の処理を完全に行わないソフトウェア ――Gecko, MSHTML, Webkit, Opera</h2>

<p>p要素の内容としてtable要素の出現が許される場合がある。場合があるというか、ほとんどの場合許されるといっていい。IEだろうがFirefoxだろうがOperaだろうがsafariだろうが、p要素の内容にtableが許される。これは恐らく、レガシーな記述に対応するために後方互換として意図的にやっているのだろう。

<p>とかいいつつ、実はこの後方互換処理を行わせない方法もある。<strong>HTML4.01 Strictを宣言する</strong>。Gecko、Webkit、Operaで有効だが、MSHTMLに関してはこの限りではない。DOCTYPEスイッチで後方互換処理を無効にできないばかりか、table要素以外にも、form要素をp要素の内容に持てるようだ。


<h2>2. の処理を完全に行わないソフトウェア ――MSHTML, Webkit, Opera</h2>

<p>ちょっとまてと。もう一度「2.」を読み返してみる。平たく言えばこういうことだ。「親要素が終了したら、終了していない子要素も終了する」。これってエラー補正処理を考える上で当たり前の振る舞いじゃないか? だが、その当たり前の処理を難しくしているらしいのが「ins及びdel要素」だ。次の例を見てみよう：

<pre>&lt;ins datetime="..">&lt;p>挿入された文章..&lt;/ins> &lt;p>古い文章..</pre>

<p>MSHTML、Webkit、Operaは、p要素内において開始タグの出現なしに出現したins/del要素の終了タグ<strong>「<code>&lt;/ins></code>」を無視する</strong>。これは後方互換性とか何とかではなく、単なるバグであろう。恐らくp要素の内容として許される要素について、その開始タグの出現なしに終了タグが出現した場合、それをエラーとみなして無視しているのだと思われる。お粗末。

<h2>感想とか</h2>

<p>さて。これらは「p要素」の終了タグの話に過ぎないという点に注意。これだけ色々面倒があることを知っていたら、省略をフル活用したHTML4.01を採用することは、ひょっとしたらなかったかもしれない。だがこれまでに色々調べたり経験したりして「知って」しまったのだからもう後戻りするコストを払う意味はないし、個人的には利点の方がはるかに多い。あくまでも「個人的には」。

<p>HTMLでタグを省略するのは、普通の人はやめておいた方がいいよ。「普通の人」が読んでいるとは思えないけれども。まーとにかく色々あるし、もともと公開書庫のコンテンツとしてHTML4.01の実践的な部分は書こうと思っていたので、これからも少しずつ省略についての考察等々は公開していく予定。

<p>テストページも用意したけど、要らないよな。公開書庫に移す時には付録として公開すると思うけど。]]>
        
    </content>
</entry>

<entry>
    <title>フレームは非論理的、再掲</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/12/post-439.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1329</id>

    <published>2008-12-01T03:34:34Z</published>
    <updated>2008-12-10T07:32:17Z</updated>

    <summary> このサイトの生い立ちは、とある掲示板で議論が起こり（というよりも一方的に筆者が...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="HTML" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="（ハイパー）リンク" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<blockquote cite="http://frame.s26.xrea.com/doc/Thinking/01.shtml" title="『ナビの考え方』より引用">
<p>このサイトの生い立ちは、とある掲示板で議論が起こり（というよりも一方的に筆者が起こしたものだが）派生したのが理由だが、その掲示板にとあるサイトからの引用が投稿されたので紹介（引用）並びに筆者のそれ対する意見を記しておく。

<p><a href="http://members.jcom.home.ne.jp/jintrick/Personal/d200107f.html#d0107f27">Personnel - 2001/7/1～15 - agenda - Personnel</a>

<blockquote cite="http://members.jcom.home.ne.jp/jintrick/Personal/d200107f.html#d0107f27">
<p>私は、サイト構造を明確に示したナビゲーションの存在は、ウェブサイトの構築に是非とも必要なものだと思っている。各文書が、全体構造を示したファイルと直接結び付くことで、初めてウェブサイトたり得るのではないか。結果としてユーザビリティを高めることになるが、本質的な意味はそこにあるのではないかと思っている。
<p>ところがフレームでは、サイト構造と各文書を論理的に結び付けることはできない。視覚的に結び付いていることができるのでさえ、玄関となるトップページを開いた時だけである。ゆえに私はフレームを用いてサイト構造を分離しようとは思わない。
</blockquote>

<p><q>サイト構造を明確に示したナビゲーション</q>のくだりは、前述の通り筆者も同じ意見だ。しかし、2段落目の<q>フレームでは、サイト構造と各文書を論理的に結び付けることはできない</q>というのはどういうことなのだろう。そもそも論理的とはどのような理なのかを考えてみたい。
<dl>
<dt>ろんり 【論理】〔logic〕</dt> 
<dd>
<ol>
<li>思考の形式・法則。議論や思考を進める道筋・論法。</li>
<li><strong>認識対象の間に存在する脈絡・構造。</strong></li>
</ol>
</dd>
</dl>
<p>言うまでもなく、サイト構造と各文書を繋ぐのはナビゲーション、つまりリンクである。論理的な結び付きというのは非常に難しい言葉である。その論理の定義がどのようなものなのかははっきりと記されていないが、つまり、<strong>"全体構造を示したファイルと直接結び付くこと"＝論理的結合</strong>、だと推測する。だとすれば、"フレームでは、サイト構造と各文書を論理的に結び付けることはできない"というのは疑問を残す言い回しだ。何故ならば、文書を結び付ける手段は先述したように『リンク』なのだから。フレームは無関係である。
</blockquote>
<p class="append"><cite><a href="http://frame.s26.xrea.com/doc/Thinking/01.shtml">ナビの考え方（frame.s26.xrea.com）</a></cite>より引用

<p><strong>強調Jintrick</strong>。<strong>認識対象の間に存在する脈絡・構造。</strong>と書いてある通り。<q>文書を論理的に結びつける</q>というのは、<strong>何故、それらが結びついているのかという、</strong>その<strong>何故</strong>を明示するということ。言い換えると、結びつけた<strong>理由</strong>をそのハイパーテキストの構文で示すことだ。

<p>Framesetのやり方で結びついただけでは、ソフトウェアはそのファイルが全体構造を示していることを理解できない。理由が示されていないからだ。<strong>リンクの方向</strong>や文書間の主従関係も示されていない。たとえば左側ペインが目次、右側ペインに本文という「フレームページ」を考えてみると、本文と目次は直接結びついておらず、framesetの文書型を宣言された空っぽのHTML文書が、目次文書と本文文書にそれぞれ匿名リンクしているだけだ。図1に示す:

<table class="object" id="figure1"><caption>図1. フレームのリンク方向</caption>
<tr><td><img src="http://purl.org/jintrick/binary/smartart/frameset_and_link.png" alt="frameset文書が「主」、目次と本文が「従」で、目次が本文とリンクしていない"></table>

<p>主従がめちゃくちゃなんだよ。論理的に両者を結び付けると、本文が目次に「目次ですよ」とリンクするのが自然だ。図2に示す:

<table class="object" id="figure2"><caption>図2. 論理的なリンク方向</caption>
<tr><td><img src="http://purl.org/jintrick/binary/smartart/logical_link.png" alt="本文が「主」、目次が「従」で、本文が目次に「rel=&quot;contents&quot;」でリンクしている"></table>

<p>これが私が、何年前だっけ？6年前？に考えていたと思われる抽象的な理念。実際にどんな問題/ご利益があるかなんて今やどうでもよくなっているけれども、一つ今思いつくのは、ブラウザはフレームで構成されたウェブページの主従関係を知り得ないため「アドレスバー」とやらにヘンテコなURLを表示してユーザーを困惑させているだろう。これがその<strong>非論理性が顕在化</strong>した例だ。

<p>あと、フレームの「ボーダー」。文書と文書の境目。こんなものをHTMLで表現すべきではない。これはブラウザがやるべきだ。左に目次のペインを作り、右に本文のペインを作る。こんなのは典型的なハイパーテキストブラウザの仕事だろうよ。デスクトップアプリケーションの文脈で言うなら、HTMLはデータに相当する部分だろう。ソフトウェアとデータの関係を考えれば、フレームがあまりにも異常なのは明白ではないか。

<p>rel="contents"をまともに利用できるブラウザがないため、この関係が極めて重要な時、仕方なくフレームを利用することはあり得るかな。

</p><ins datetime="2008-12-09T20:05+09:00">
<h2>追記</h2>

<p>当為命題を意見の押し付けだという馬鹿に言及されたが、言論をパワーハラスメントか何かと勘違いしている。この手の飛躍は被害妄想から生まれると相場は決まっていて、下手に名指しすると妄想を膨らませて何をしだすか分からん。危ないので直接関わらない方がよさそうだ。どうやら「彼」は闇黒日記に着想を得て元気になり、その勢いで書いた文章らしいが、同じような疑問を抱く人もいるかもしれないから追記しておく。

<p>noframes要素は、<q cite="http://www.asahi-net.or.jp/~SD5A-UCD/rec-html401j/present/frames.html#edef-NOFRAMES">フレームをサポートしないユーザエージェントやフレームを表示しない設定になっているユーザエージェントにおいてのみ表示されるべき内容</q>である。フレームをサポートし、表示する設定にしてあるユーザーエージェントがその内容を解釈しなければならないとはされておらず、frame要素による非論理的なリンクを補完する役目をnoframesに期待することはできない。noframesに期待できるのは、フレームが無効な環境での代替内容の提供。

<p>framesetのHTML文書にrel="index"などのlink要素を記述した場合にリンクされるのは「framesetの文書」と「索引（index）文書」であり、frame要素でリンクされた文書と索引は直接リンクしていない。noframesの内容とlink要素とのリンク関係が発生するのは、上に述べたように、フレームをサポートしないユーザエージェントやフレームを表示しない設定になっているユーザエージェントにおいてのみ、である。

</ins>
]]>
        
    </content>
</entry>

<entry>
    <title>Hatena::agenda復活</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/hatenaagenda-1.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1328</id>

    <published>2008-11-29T11:23:21Z</published>
    <updated>2008-11-29T11:32:36Z</updated>

    <summary>なんか、今まで自分のブックマークはLAN接続型HDDに保存してきたんだけど、はて...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="ブックマーク" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<p>なんか、今まで自分のブックマークはLAN接続型HDDに保存してきたんだけど、はてなブックマークみたいなのを使って公開した方が良いのかなあと思って、Hatena::agendaという記事紹介ブログみたいなのを復活させてみた。以前ははてなダイアリー上でやっていたが、これは大間違いもいいところだった。なんで最初からb.hatena.ne.jpでやらなかったんだろう。当時はてなブックマークってなかったんだっけ？まあいいや。今までは本当にいたずらとか茶々入れみたいな馬鹿な目的ではてなブックマークを使っていたけれども、ちょっと心を入れ替える。真面目にタグとかもつける。これからだけど。

<ul><li><a href="http://b.hatena.ne.jp/jintrick/">Hatena::agenda（d.hatena.ne.jp）</a></ul>

<p>叩かれていると逆に使いたくなるんだよ。「本当にそうか？」って。あと、まともに使っていないから叩かれている意味がちっともわからなくて悔しい。

]]>
        
    </content>
</entry>

<entry>
    <title>「自分とは違った視点」をはてなブックマークに求めること</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/post-438.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1327</id>

    <published>2008-11-29T09:50:13Z</published>
    <updated>2008-11-29T10:10:58Z</updated>

    <summary> １．「お気に入り」に入れるのとRSSリーダーで読むのと何が違うの？ まず、ブッ...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="misc" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<blockquote cite="http://ameblo.jp/moppara/entry-10170932736.html">
<p>１．「お気に入り」に入れるのとRSSリーダーで読むのと何が違うの？
<p>まず、ブックマークのコメントが読めること
<p>他の人がその記事に対してどういう感想を抱いたのかが読め、<strong>自分とは違った視点</strong>が得られる

<p>次に他の好みのブックマーカーを見つけることが出来る

<p>上記の記事を書いた人はほぼ一人のブックマーカーしか追っていないみたいなのだが、「お気に入り」などのページから個々の記事のページ（ttp://b.hatena.ne.jp/entrｙ/～）に飛んでコメントを読むということし、そこでよく見かけるブックマーカーを「お気に入り」に入れておけば、自分の好みの記事を効率よく探すことが出来る
</blockquote>
<p class="append"><cite><a href="http://ameblo.jp/moppara/entry-10170932736.html">はてなブックマークが「ソーシャル」ブックマークたる由縁（ameblo.jp/moppara/）</a></cite>より引用

<p><strong>強調Jintrick</strong>。<q>自分とは違った視点</q>等が得たかったら、私の場合Firefoxのアドレスバーにcompareと打ち込んでEnterを押す。すると<em>私の環境では</em>その記事にリンクしていたり関連していたりする<strong>World Wide Web上の</strong>記事のリストが別タブに次々表示される（<small>もちろん「http://b.hatena.ne.jp/entry/<var>その記事のURI</var>」も表示されるので、はてなブックマーカーのコメントにも目を通す</small>）。

<p>それに<q>自分とは違った視点</q>をはてなブックマークのコメントのみに求めるのは危険だ。はてなブックマーカーのほとんどは、記事をまともに読んでいない。きちんと読んで批判したかったら:
<ol>
	<li>100文字制限のある
	<li>他人のドメイン上に
	<li>ブックマークレットなんかを使って
	<li>さっさと公開したりはしない。
</ol>
<p>稀に一言ですべて言ってのける鬼才はいるかもしれない。しかし実際はてなブックマーカーの多くはそういう気概すら持っていない。そもそも「ブックマークコメント」だし。

<p>私は、まず記事を<strong>自分の目で</strong>読んで、関連する情報は<strong>自分が欲しいと思ったときに自分で取りに行く</strong>。また、それらの関連情報は「はてなの世界」に限定されない。私の眼に映っているのはWorld Wide Webというハイパーテキストアプリケーションであって、「はてな」の世界ではない。つもり。だが依存度は比較的高い。エントリー別ページは関連記事へのリンクもあって素晴らしいし。

<hr>

<p>リンクした上記記事とは関係ないことを断わっておくが、一応「お気に入り」が楽しいというのは想像できるつもりだ。なんか「これはひどい」みたいなタグをつけて悪態をついたら、自分が「お気に入り」に入れた「仲間」が一緒になって「これはひどい」とかさ。ドラクエのパーティ（何）みたいで楽しそう。たとえが悪意に満ちているが、当たらずといえども遠からずだろう。あるいは切手集めみたいな感覚か。気に入ったはてなユーザーの、小さいアイコンがずらりと並ぶと収集欲が満たされそう。でなければ、「お気に入られ」ることによって自分の「存在を確認」とかな。

<p>私は別に楽しいとかはいいや。


]]>
        
    </content>
</entry>

<entry>
    <title>blockquote要素（またはq要素）が形成するリンクについて</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/blockquoteq.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1326</id>

    <published>2008-11-27T02:44:06Z</published>
    <updated>2008-11-28T12:17:23Z</updated>

    <summary> 私は上記の記事を「a要素などで利用者に目に見える形で表示されるものを、わざわざ...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="HTML" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="アクセシビリティ" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<blockquote cite="http://simpleism.net/blog/2008/11/link-element" title="link要素云々 （simpleism.net）より引用">
<p>私は上記の記事を「a要素などで利用者に目に見える形で表示されるものを、わざわざ(ソースなどで)隠すあるいは二重にリンクする必要はない」と解釈したのですが、私の場合これってblockquote要素のcite属性にも当てはまるんですよね。

<p>これは逆の形っていうか、「cite属性で引用元をきちんと示しているのに、a要素などでわざわざ目に見える形にする必要はない」って思うんですよ。私は引用元の前後の文書も読みたいと思うので、ソースを覗いてでもcite属性を探しますけど、多分少数だと思います。今はJavaScriptを用いて cite属性などを目に見える形に表示していますけど、それらはブラウザがやってくれてもいいんじゃなかろうか、とか思うのは望みすぎなのかな？</blockquote>
<p class="append"><cite><a href="http://simpleism.net/blog/2008/11/link-element">link要素云々 （simpleism.net）</a></cite>より引用

<p>それは私もHTMLで引用する時には毎度頭をよぎる。しかしリンクの種類を伝えられるのはcite属性でしかありえず、a要素で引用元にリンクしたとしても、それがユーザーエージェントに「引用元」だとは伝わらない。

<table class="object">
<caption>blockquote要素とa要素のリンクの相違</caption>
<thead>
	<tr><th>始点アンカー<th>省略されたソース<th>リンクの種類<th>終点アンカー
<tbody>
	<tr><th>blockquote要素<td><code class="HTML">&lt;blockquote cite="http://example.com/">..</code><td>引用<td>http://example.com
	<tr><th>a要素<td><code class="HTML">&lt;a href="http://example.com">..</code><td>不明<td>http://example.com
</table>

<p>どちらか一方だけだと片手落ちになってしまう。人が読む場合ならともかく、ソフトウェアが引用元へのリンク扱う場合、a要素の方は推論が必要になってしまう。

<h2>blockquote要素をハイパーリンクとして扱うブラウザ</h2>

<p>blockquote[@cite]要素をユーザーがきちんと利用できるリンクとして扱うのは、ハイパーテキストブラウザとして当然の挙動だとは思うけれども、結局のところ互換性を考えればそういうリンクはすべてa要素で提供すべきだから、個人的にはどうでもよかったりする。仮に「blockquote要素」を突っつくと引用元へのリンクトラバーサルが発生するようなブラウザが主流になったとしても、私は<strong>閲覧者に引用元を示したかったら</strong>a要素でもリンクを提供するだろうということ。互換性命。

<h2>「闇黒式引用」について</h2>

<p>ちなみに「闇黒式引用」というメソッドは、どこから引用しているかが閲覧者からみて自明である場合、あるいは閲覧者には特別引用元を示す必要がない場合（文脈を無視できる場合など）に有効であると解釈している。別に難しい話でも複雑な話でもない。私はtitle属性なんかつけないから「闇黒式引用」とは言えないのかもしれないけど、基本的にcite属性を記述して、閲覧者にリンクを提供したかったらa要素でやる。それだけの簡単なローカルルール。
]]>
        
    </content>
</entry>

<entry>
    <title>はてなブックマークの「お気に入り」って何？ の続き</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/post-437.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1325</id>

    <published>2008-11-26T14:05:18Z</published>
    <updated>2008-11-26T14:09:30Z</updated>

    <summary>はてなブックマークの「お気に入り」って何？ (agenda)の続き。 はてなブッ...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="misc" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<p><a href="http://jintrick.net/agenda/2008/11/post-436.html">はてなブックマークの「お気に入り」って何？ (agenda)</a>の続き。
<ul>
<li><a href="http://b.hatena.ne.jp/entry/http://jintrick.net/agenda/2008/11/post-436.html">はてなブックマーク - はてなブックマークの「お気に入り」って何？ (agenda)</a>
</ul>
<p>なんか、言いだしっぺの私が言っていいのか知らんけど、はてなブックマークの「お気に入り」がRSSリーダーより優位な点って、はてなブックマーカー達による「情報の重複」を避けられることじゃないのか？とふと思った。たとえば、RSSに登録しているはてなブックマーカーが10人いて、10人が10人同じ記事をブックマークしたとすると、RSSリーダーでは10もの個別フィードを消化することになる。しかしはてなブックマークのお気に入りに「隔離」しておけば、記事一つにコメントが集められる形で表示されるのですっきりする。

<p>と思ったら、すまん<strong>既にいくつかブックマークコメントされてた</strong>。恐らく同じような意味。だと思う。ピンと来なくて気付かなかった。

<ul>
	<li><q cite="http://b.hatena.ne.jp/tezukam/20081126#bookmark-10988394">はてぶのお気に入りは、記事ごとにお気に入りの人がまとめられているので同じ記事が何度も出てこない</q>
	<li><q cite="http://b.hatena.ne.jp/yorihito_tanaka/20081126#bookmark-10988394">集約して表示させられる点ではRSSフィードの個別登録よりも便利</q>
</ul>

<p>で、ekken氏の言うようにそのお気に入りをRSSに登録しておけばわざわざRSSリーダーとお気に入りの双方をチェックせずに済む、と。

<p><q>まあ徒栞しか購読していないライトユーザーだから、なにか見落としているんだろう。 </q>と前回書いたけど、まさにその通りだったよ。ちなみにRSSリーダーをみてみたら、<a href="http://b.hatena.ne.jp/kits/">徒栞</a>の他にも<a href="http://b.hatena.ne.jp/smallball/">はてなブックマーク - smallball</a>が登録してあったので、購読しているのは二つだった。重複なんか起こったためしがないという。

<p>この他、「お気に入り」の特長についてコメントされていたものをまとめてみるテスト。こんなことやってる場合じゃないんだけど。

<ul>
	<li><q cite="http://b.hatena.ne.jp/namnchichi/20081126#bookmark-10988394">RSSリーダーの使い方が分からなくても使えるのが利点です</q>
	<li><q cite="http://b.hatena.ne.jp/kawacho/20081126#bookmark-10988394">RSSリーダー使わなくてすむ。複数人のブックマークがまとめてメールで届くのが便利</q>
	<li><q cite="http://b.hatena.ne.jp/hatayasan/20081126#bookmark-10988394">RSSは微妙な時間差があるので、ライブ感を楽しむならお気に入り</q>
	<li><q cite="http://b.hatena.ne.jp/smallball/20081126#bookmark-10988394">&#8220;この人はどのブックマーカーが好きなのか&#8221; , &#8220;このブックマーカーはどんなブックマーカーに好まれているのか&#8221;が分る</q>
	<li><q cite="http://b.hatena.ne.jp/sirobu/20081126#bookmark-10988394">お気に入りに入れてる人N人がブックマークしてる記事を選別できるのが便利</q>
</ul>

<hr>

<p>私は界隈のクリティカルな話題を見逃したくないから最低限<a href="http://b.hatena.ne.jp/kits/">徒栞</a>の購読で保険をかけていて、<a href="http://b.hatena.ne.jp/smallball/">はてなブックマーク - smallball</a>は、コメントがほぼ<strong>確実に</strong>楽しいから読んでいるだけで、これ以上増やしてもチェックするのが大変だ。ウェブの情報収集において、プッシュは保険で使うものであって、クリティカルなものはプルで得るのが基本だと思っている。昔から。これからも深入りせずに、プルの技を磨くことにするよ。ゴシップはほどほどに。]]>
        
    </content>
</entry>

<entry>
    <title>日経ビジネスオンラインの「Web文章」</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/web-3.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1324</id>

    <published>2008-11-26T06:09:58Z</published>
    <updated>2008-11-26T06:19:30Z</updated>

    <summary>「プロらしさ」を生むWeb文章校正の５大鉄則（business.nikkeibp...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="意見交換, 批判等" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<ul><li><a href="http://business.nikkeibp.co.jp/article/nmg/20081119/177743/">「プロらしさ」を生むWeb文章校正の５大鉄則（business.nikkeibp.co.jp）</a></ul>


<blockquote cite="http://business.nikkeibp.co.jp/article/nmg/20081119/177743/"><p>原稿というのは、不思議なもので、書き上げたばかりのものよりも、寝かせて見直して、手直しを入れたもののほうが、はるかに出来がよくなります。</blockquote>
<p>別に不思議じゃないし、読点が多すぎて不自然で「プロ」らしくない。何だか初っ端から香ばしいんだけど。

<blockquote cite="http://business.nikkeibp.co.jp/article/nmg/20081119/177743/"><p>　文章というのは線状です。一行目は二行目のためにあり、二行目は三行目のためにあります。時間的、とでもいいましょうか。AとBを完全に同時に表現することはできず、必ずどちらかが先になります。
<p>　もつれたり、立体的であったりする考えを、一本の線にしていく行為が書くという行為です。実際に書いてみると、何が足りないのか、どこをもっとあつく書かなければいけないのか、なども見えてきます。 </blockquote>
<p>たしかテーマは「Web文章校正」だった筈。ハイパーテキストが直線的とは限らないことくらい考慮に入れて話してほしいところ。あと、ウェブの文章作法としては字下げを全角空白でやるのは大きなお世話。というかこれ、ただの文章作法でWeb文章作法じゃないじゃん。続きは会員だけが読めるらしいぞ。

<p><q>ご登録(無料)やログインの方法は次ページをご覧ください。</q>というからその「次ページ」に進んだら、「無料会員登録」とかいうボタンが現れた。それを押したらこんどは注意書きが現れやがった。で条件分岐させてようやくフォーム。今回は「斬る」目的でクリックしたが、まあ普段なら登録などしないでさっさと他の記事を読みにいくだろう。私なら記事が読めなくなった最初のページにいきなり会員登録用のフォームを用意するよ。もちろん利用規約の同意を入力させるUI込みで。ページを遷移させる必然性が何もない。そもそも会員制になどしないだろうけど、それは別の話か。

<hr>

<p>というかこんなことをしている場合じゃないんだよな。私の場合「リアル」とやらが極度に忙しくなると、逆にウェブ関係の更新頻度が上がることがある。]]>
        
    </content>
</entry>

<entry>
    <title>はてなブックマークの「お気に入り」って何？ </title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/post-436.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1323</id>

    <published>2008-11-25T17:56:56Z</published>
    <updated>2008-11-29T00:26:56Z</updated>

    <summary>なんか自分でも恥ずかしいくらい今更な話なんだけど、はてなブックマークのお気に入り...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="misc" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<p>なんか自分でも恥ずかしいくらい今更な話なんだけど、はてなブックマークの<a href="http://b.hatena.ne.jp/help/favorite">お気に入り機能</a>って何なんだ？

<blockquote cite="http://b.hatena.ne.jp/help/favorite">
<p>お気に入りページでは、お気に入りに加えたユーザーのブックマークを新着順にまとめて閲覧することができます。
</blockquote>

<p>RSSリーダーに登録しておけばまとめて読めるのに、お気に入り機能を使う理由が分からない。

<blockquote cite="http://b.hatena.ne.jp/help/favorite">
<p>お気に入りユーザーがブックマークにつけたコメントも合わせてみることができるので、あなたにとって<strong>価値の高い情報</strong>だけを凝縮して閲覧することができます。
</blockquote>
<p>強調Jintrick。「都合のいい情報」の間違いでは？そんな薄気味の悪い情報収集をしていると目が腐るぞ。いや腐っているから云々というべきか。

<p>お気に入りゼロの状態でお気に入りページを開くと、こんな誘い文句が踊る。

<blockquote>
<p>気になるユーザーの新着ブックマークをまとめて一覧できる「お気に入り機能」を活用すれば、はてなブックマークが自分だけのネットサーフィンガイドブックになります！
<p>また、趣味・嗜好に合ったユーザーのブックマークを追いかけることで、自分だけでは集めきれない興味のある情報が得られ、更には今まで出会うことのなかった新しい世界をも見つけることができるでしょう。</blockquote>
<p>やっぱりRSSリーダーに登録しておけば事足りる。某JN先生はこの「！」が嫌いなんだよな、どうでもいいけど。

<p>RSSリーダーでは駄目な理由って何かあるのかなあ。まあ<a href="http://b.hatena.ne.jp/kits/">徒栞</a>しか購読していないライトユーザーだから、なにか見落としているんだろう。

<ins datetime="2008-11-29T09:26+09:00"><p><a href="http://jintrick.net/agenda/2008/11/post-437.html">はてなブックマークの「お気に入り」って何？ の続き (agenda)</a>に続く</ins>]]>
        
    </content>
</entry>

<entry>
    <title>代替テキストで悩む瞬間 </title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/post-435.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1322</id>

    <published>2008-11-24T16:51:32Z</published>
    <updated>2008-11-24T17:00:39Z</updated>

    <summary> IMGのalt属性・title属性について考える（後編） ｜ HiGash.N...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="HTML" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<ul>
<li><a href="http://higash.net/20081120/alternate-2.html">IMGのalt属性・title属性について考える（後編） ｜ HiGash.Net</a>
</ul>

<p>なんとなく面白そうだが、実際無縁な話だなと思った。

<ul>
	<li>装飾のための画像を一切入れないから、「CSSかIMGか」で迷うことがない
	<li>代替テキストが空だからといって、それが気持ち悪いとは思わない
</ul>

<p>私の場合代替テキストを空にすべきか考える事例そのものが少ないような。覚えているのは自分を紹介する文書で、顔写真を使ったときくらいか。このときは久しぶりに代替テキストをどうしようか考えたが、適切なものが頭に浮かばなかったので空にした。別に気持ち悪くもなんともない。

<p>画像を利用できないシチュエーションを<strong>想像</strong>して、情報の伝達に支障が出るなら、そこをテキストで補う。想像力がないなら、画像を非表示にしてみて、文書を（「眺める」のではなく）きちんと読んでみる。それでちゃんと伝わるならカラでも何でもいいだろう。

<p>良く考えてみると、問題は空では補えなかったり、そもそもテキストでは補えなかったりする事例なんだよ。意味不明で無関係な子供の写真など一々問題視すべきではないよ。

<p>何かについて文章で詳細に説明をしたとする。そして、そのさらなる理解を補助する目的で参考画像を挿入し、その参照を促す文章が参考画像とリンクしているとする。さて代替テキストはどうするんだ? 私はこういう事例結構あるぞ良く考えてみると。特に論文で画像を用いるのは絶対にこのパターンだ。すでに詳細な説明は文章で済ましてあるので、画像の代替テキストにもう一回詳細な説明を入れるのは冗長以外の何物でもあるまい。longdesc属性も同様だ。言い換えると、文章では伝え切れなかったプラスアルファを表現するために画像を用いたわけだから、適切な代替テキストなどあろうはずがない。そう考えると空が適切なのかもしれない。しかし、その画像の参照を促す文章があることを思い出してくれ。画像を利用できないユーザが、参照を促されたオブジェクトから何の情報も得られないと知ったとき、非常に残念に思うのではないだろうか。

<p>これを解決するためには、画像を利用できる「media」とできない「media」でスタイルシートを別々に用意し、参照を促す文章の部分の表示非表示を切り替えるしかないのではないか。だがそこまで面倒なことをする製作者はいないよな。もっとも、伝えるべきものは伝えているのだから、残念でもなんでもいいやと割り切ってもいいと思う。完璧主義みたいなのは勘弁願いたいものだ。

<hr>

<p>まったく関係ない話でアレだけど、完璧主義で思い出したので書いておく。先日www.jintrick.netを抹消した。リダイレクトとか面倒くさいんだもの。理想は理想。完璧に理想を追求するなんて堅苦しいのは勘弁願いたい。でも迷惑を被っている人がいたら、本当に申し訳ないとしか言いようがないけど。]]>
        
    </content>
</entry>

<entry>
    <title>Re: 誰が為にブログを書くか</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/11/re-38.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1321</id>

    <published>2008-11-13T16:37:47Z</published>
    <updated>2008-11-13T16:43:52Z</updated>

    <summary>誰が為にブログを書くか（TexTsiTe） どこかの誰かが書いたものがオレの助け...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="agendaについて" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<ul><li><a href="http://blog.livedoor.jp/text_site/archives/50636213.html">誰が為にブログを書くか（TexTsiTe）</a></ul>
<p><q cite="http://blog.livedoor.jp/text_site/archives/50636213.html">どこかの誰かが書いたものがオレの助けになったお礼に、どこかの誰かがいつか読む日の為にオレは書いている</q>、について。
<p>かなり私の考えに近い感じなのだけれど、決定的に違うのが、「書いている」という点。私の場合、書くという行為は、個人的なもろもろの事情によるもの、平たくいえば「自分のため」のものなのだが、それがウェブ上に公開しても問題ないものであるとき、その時に限り公開する。
<p>この「オレは書いている」と「オレは公開している」の違いの本質は何か。それは「見返りを求めないで済むか否か」だ。誰かの為に自分の何かを犠牲にすると、必ず何らかの見返りを求める結果となる。自分に何の損もなければ見返りを求めずに済むのだ。
<p>で、なぜ見返りを求めてはいけないか、について以前書いたものを公開してみる。簡単に言えば、これは単なる自分のなかの<strong>教義に過ぎず</strong>、全く取るに足らない。Jintrickに特別興味のない人が読むべき内容ではないことを断わっておく。今ではニュアンスに微妙に違和感があるので引用の形にしておこう。

<blockquote>
<p>昔は<abbr title="Tim Berners-Lee">TBL</abbr>、というか<abbr title="World Wide Web">WWW</abbr>そのものへの謝意があり、そして様々な情報を無償で、ほとんど何の見返りも求めずに公開してくれている偉大な先人たちへの謝意があり、ささやかながら何か自分も、という気持ちがあった。しかし今は違う。TBLを尊敬する気持ちは別に変っていないとしてもだ。ほとんどの人が「ぶろぐ」という形で情報を公開して、必ずといっていいほど、露骨にといってもいいほど、見返りを求めている。それ自体は歯車を回すために必要なことでもあり、むしろ健全であるとさえいえるだろう。しかし、アフィリエイトやコメント欄がなかった昔だって、それらがあれば誰もが利用していただろうよ。つまり私は<strong>騙されていた</strong>わけだな。蓋を開けてみれば自己満足ブログパーツや報酬コメント蘭、報酬トラックバック機能、小遣い稼ぎリンク等々であふれかえっていて、コンテンツなんかおまけ程度というか、ハナっからそれらの報酬を目的とした<strong>手段</strong>扱いだ。

<p>怪しい自己分析をすると、どうやらそのあたりのコンプレックスで「ウェブで見返りを求めることが許せない」が自分の中でドグマ化したらしい。実際には単にブログを管理するためのソフトウェアが、デフォルトでそういった報酬系の機能を搭載しているというだけ、つまり表面上そう見えるだけで、今も昔もたいして変わらないのだろう。だがとにかく教義と化してしまったんだよ。
</blockquote>

<p>そしてこの教義から導き出されて、「自分のために書き」、「もったいないなら公開する」という態度が生まれたわけだ。正直に書くというのは恐ろしいことだな。
]]>
        
    </content>
</entry>

<entry>
    <title>Multicol Google Search更新 / 使用上の注意事項</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/10/multicol-google-search-2.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1320</id>

    <published>2008-10-16T04:22:54Z</published>
    <updated>2008-10-23T03:26:50Z</updated>

    <summary> Google検索結果のスキーマ改定に伴い、Multicol Google Se...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="Google" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="リキッドマルチカラム" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[
<p>Google検索結果のスキーマ改定に伴い、Multicol Google Searchを粛々と更新。

<ul>
<li><a href="http://jintrick.net/script/2008/1023/multicol_google_search.user.js">Multicol Google Search 2008-10-23 (GMScript本体)</a>
</ul>

<p>現在のページ数を表わすspan要素のncというid属性が消え、その親要素のtd要素にcurというclass属性がついただけ。XPathを一つ書き換えた。DOM Inspectorで行う構造の手動解析含めて3分で終了。この小さな変更は何なんだ。

<p>拍子抜けしてしまったから、Multicol Google Searchについて少し説明を加えておこう。――と思ったけど以前書いていたのでリンクで済まそう。

<ul>
<li><a href="http://jintrick.net/agenda/2008/03/googlegreasemonkey.html" title="agendaの記事">Multicol Google Search基本コンセプト（この記事を書いたときはまだスクリプトに名前なし）</a>
<li><a href="http://jintrick.net/agenda/2008/08/multicol-google-search.html" title="agendaの記事">Multicol Google Searchスクリーンショット及びユースケース</a>
</ul>

<h2>Multicol Google Search 使用上の注意</h2>

<p>今回は注意事項を加えておこう。残念な思いをしている人が出てきているみたいだし。

<ol>
<li>www.google.comでしか動作しない（※）。Greasemonkeyの設定で対象をwww.google.co.jpに拡大も可能だが、その場合履歴機能が動作しないし、そのほかの不具合にも私自身関心がないので要注意。
<li>他のユーザースクリプト（Greasemonkey等）でGoogle検索結果の文書ツリーに変更を加えていると動作しない。
<li>他のユーザースクリプト（Greasemonkey等）でGoogle検索結果に対してAjax等を用いていると動作しない場合がある。
<li>他のユーザースクリプト（Greasemonkey等）でGoogle検索結果に対してビューの変更を行っている場合、それらは無効になる場合がある。
<li>他のユーザースクリプト（Greasemonkey等）でGoogle検索結果の文書ツリー内のノードに対してイベントリスナーを登録していると、それらは全て無効になる（はず）。
</ol>

<p><small>※ www.google.com上のウェブアプリケーション群で使用している「hstory hack」を流用している為</small>

<p>私自身、このスクリプトへの依存度が高いので更新は速いよ。
]]>
        
    </content>
</entry>

<entry>
    <title>「HTML原理主義者」を笑い飛ばせ</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/10/html-17.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1319</id>

    <published>2008-10-14T12:29:02Z</published>
    <updated>2008-10-14T12:30:47Z</updated>

    <summary>ちょっと一休み（謎）。いつだったか「HTML原理主義者」という言葉を笑い飛ばすた...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="珈琲ブレイク" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<p>ちょっと一休み（謎）。いつだったか「HTML原理主義者」という<strong>言葉</strong>を笑い飛ばすために、軽く文章を書いたので、推敲して公開しておく。

<ul><li><a href="http://www.itarchitect.jp/xml/-/10907-1.html">XMLボキャブラリのアンチ・パターン　第4回：「原理主義」、「奇妙な名前、謎の名前」 - ITアーキテクト [IT Architect]</a></ul>

<p>なんだこの気味の悪い二人は。

<p>そもそもそれ、HTMLではないローカルなMSHTMLアプリケーションの類だろう。そのローカルなMSHTMLアプリケーションにHTMLの文法を持ち込もうとしたこの「T君」こそ、正しい意味でHTML原理主義者と言えるわな。<q>過激ではない</q>とあるが、私に言わせればこのT君こそが超過激なHTML原理主義者だよ。何故ウェブページの例ではなく、講義で使うMSHTMLアプリケーションなんかを例に取ったんだろう。絶対わざとだろ。

<h2>世にいう「HTML原理主義者」の不思議</h2>
<p>しかしふと思ったのだが、世にいう「HTML原理主義者」はどうも異色だよな。Pという言語があって、P原理主義者と言ったとき、それは「Pの文法を守れ」と説教する人のことか? 違うだろう。「Pで書け」風なことを言う人達のことだろう。あるいは、Pの思想で他の言語を批判する人たちのことだろう。それはプログラム言語とマークアップ言語の違いかなと思ったが、マークアップ言語Xがあったとして、X原理主義者というのはやっぱり、「Xで書け」と主張する奴だよ。「これからはXの時代だ」とか言ってな。でも「Xで書くならXの文法を守れ」と主張する奴をX原理主義者とは呼ばない。でもHTML原理主義者だけは全然違う。文法を守れという奴がそう呼ばれる。言葉を用いるセンスが幼稚という問題は置いておいて、これは何を意味しているのだろう。

<h2>実は世間にはHTMLが沢山あるのでは</h2>
<p>以上のような疑問は、ある仮説を立てるとうまく説明できる。つまり、HTMLの文法にうるさい人を「HTML原理主義者」と揶揄して笑っている人たちは、ウェブページをHTMLで書いていないのだ。仮にそれらの一見HTMLな非HTMLを総称してFMLと名づけよう。FはFusigiのF、FantasyのF、FreeのF、なんでもいい。FMLインスタンスを書いていたのに、それは「HTMLで書くべきだ」「HTMLの文法に違反している」と言われたとしたら? それは確かにHTML原理主義者と揶揄する理由として、もっともなものだ。

<h2>「原理主義者」って言いたいだけ（略）</h2>
<p>だがちょっと待てよ。FMLには文法がないし、かつ要素名等がHTMLに酷似しているんだよ。しばしばtext/htmlでserveされるし、保存しようとすると「HTMLのみ」とかいう選択肢も出てくることもしばしば。これをHTMLだと誤解しない奴がいるかと。そして前節はFMLという言語があるという仮定があってこそのものだ。もちろん実際にはそんなものは存在しない、いや正確に言うとFMLを書く人間の脳内にのみ、FMLは存在している。多くの場合、「IE」でうまく表示できるかどうかがその文法にかなっているかを判別する方法だ。
<p>――全く取るに足らないな。なんか、イケナイ言葉を覚えたてで使ってみた中学生とか、そういうレベル。]]>
        
    </content>
</entry>

<entry>
    <title>このサイトの文章が横長で「読みづらい」理由</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/10/post-434.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1318</id>

    <published>2008-10-14T12:04:54Z</published>
    <updated>2008-10-14T12:14:48Z</updated>

    <summary>常連の方は読み飛ばし可。 このサイトの文章を横長で「読みづらい」と感じ、 滑稽に...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="agendaについて" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<p>常連の方は読み飛ばし可。

<p>このサイトの文章を横長で「読みづらい」と感じ、<br>
滑稽に思ったり文句を言いたくて仕方ないとすれば、<br>
それは次の理由による。

<ul>
<li>あなたが、横長で「読みづらい」文章レイアウトの利点をさっぱり理解しておらず
<li>かつ、私が、<em>このサイトでは</em>そのような閲覧者を相手にしていないため
</ul>

<p>もっとひどい場合、段落中に改行を入れて読みやすくしろという要求もたまに見られる。<br>
一つの段落中で、一個の主張が完結していないのにもかかわらず、<br>
論理的に訳のわからない「読みやすい」なる位置で強制的に改行が行われた文章。<br>
こういった文章を読みやすいと思ってしまうのは、あまり本を読まないからだ。<br>
<p>本読まぬ人語るに足らず、とまでは言わないが、<br>
本を読まない人のために、本を読む人が読みやすいと思う文章作法を放棄する気は毛頭ない。<br>
何故ならここにあるのはほぼ全て、「残す」ための「文章」であって、<br>
女子高生同士が意思疎通を行うための記号ではないのだから。

<p>本日は特に考慮して、強制改行つきでお送りしております。なお、Firefoxユーザには関係のない話。
]]>
        
    </content>
</entry>

<entry>
    <title>再びウェブ・マルチカラムに対する疑問等に応える</title>
    <link rel="alternate" type="text/html" href="http://jintrick.net/agenda/2008/10/post-433.html" />
    <id>tag:jintrick.net,2008:/agenda//1.1317</id>

    <published>2008-10-13T22:30:40Z</published>
    <updated>2008-10-13T22:31:27Z</updated>

    <summary>ヘルプにも書いて居る通り、640 × 480 を想定して居るうちのサイトではマル...</summary>
    <author>
        <name>Jintrick</name>
        <uri>http://www.jintrick.net/</uri>
    </author>
    
        <category term="ウェブデザイン" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="リキッドマルチカラム" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="意見交換, 批判等" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://jintrick.net/agenda/">
        <![CDATA[<blockquote cite="http://ryus.s21.xrea.com/w/item/1112"><p><a href="http://ryus.s21.xrea.com/w/at/help" title="Help - Appendix - Weblog">ヘルプ</a>にも書いて居る通り、640 × 480 を想定して居るうちのサイトではマルチカラムは採用出来ないなあ。</blockquote>
<p class="append"><cite><a href="http://ryus.s21.xrea.com/w/item/1112">制作者の決断 - Weblog</a></cite>より
<p><a href="http://jintrick.net/agenda/2008/10/post-430.html">マルチカラムとウェブ・ユーザビリティ (agenda)</a>を読んだだけだとしたらある意味誤解も仕方ないのだが、私が採用を検討しているのはリキッドマルチカラムであり、解像度に応じて適当にカラム数が変化するものだ。単純化して説明すると、たとえばカラムの幅を40emに指定したとしよう。ryu氏のいうVGA（640 × 480px）という解像度では、40emの幅をもつカラムを二列並べることができない（※）ため、自動的にシングルカラムになる。こういった性質がある。逆に40emの幅を持つカラムを3つ並べることのできる画面解像度であったなら、3カラムになりうる。


<p>※ 文字サイズにもよる

<hr>

<p>それはさておき、VGA以下のようなマルチカラムに適さない環境でも無理やりマルチカラムになってしまったら、幅固定のフローズンレイアウトと何ら違いはなく、そんなものウェブデザインとは言えないよ。floatプロパティを使った疑似段組だって、みんな他に適当な方法がなかったから仕方なくやっているだけだろう? 違うのか? 私は昔から嫌々使っていたよ。floatさせる要素には幅を明示しなければならない。「なんだそりゃ」と。display: inline-block等を利用した疑似段組、つまりブロック（カラム）が折り返される疑似段組みの方が遥かに柔軟性の高いレイアウトだ。floatを用いた方法は、明らかに不適切な幅であっても、その不適切なレイアウトを維持してしまう。偶々現在、<a href="http://jintrick.net/agenda/">agendaのホームページ</a>ではその二つの疑似段組を使っている。Opera9.xやFirefox2/3、safariなんかで見てみるといい。ウィンドウ幅をどんどん縮めていったとき、それぞれのカラムがどんな風に変化するかを比較できるだろう。「最新記事一覧」と「人気記事一覧」の二つはfloatを使っているからウィンドウ幅が狭くなってもいつまでも不適切にレイアウトを保持するのに対し、下部の「月別アーカイブ」は、各カラムがウィンドウ幅に応じて適切に折り返される。さらにFirefox2/3なら中段の「カテゴリ別アーカイブ」の部分にリキッドマルチカラムも使っているので、色々なリキッドレイアウトの挙動を比較することができるようになっている。

<blockquote cite="http://d.hatena.ne.jp/amateru/20081012/1223805612"><p>どちらかといふと、マルチカラム*1の様なユーザインターフェイス*2的な仕組みは、制作者が提供する物ではないと思ふ。</blockquote>
<p class="append"><cite><a href="http://d.hatena.ne.jp/amateru/20081012/1223805612">気に入ったインターフェイスを使ひ回せれば一番なのに - 雑念雑記はてな出張所</a></cite>より
<p>正直、言いたいことは分かるのだが、ユーザーインターフェイス（UI）というのはユーザの入力に対して何らかの出力があったとき、その架け橋となるものだろう。私はUIという言葉をそのような意味で使っていて、ハイパーテキストにおけるGUIについて否定的な意見を述べたりしているので、この単語を正しく使うことは極めて重要だ。揚げ足取りだとは分かっているが、看過できない。インターフェイスについても同様。
<p>風呂敷を小さくして「コンテンツの読ませ方」「コンテンツのレイアウト」あるいは、それより少し風呂敷を広げて「コンテンツのデザイン」としてみよう。結論だけ述べれば、コンテンツのデザインはまず、そのコンテンツをよく知る<strong>製作者が提供すべき</strong>。そしてそれを上書き可能な形でユーザースタイルシートやユーザースクリプト、あるいはブラウザによる設定変更等が存在して良い。この順序が一ミリでも狂ったら、ウェブは最悪に味気ないものと化す。
<p>実際にウェブでマルチカラム（疑似段組ではなく、CSS3 multicolのようなカラムボックスをコンテンツが跨ぐもの）をやってみると分かると思うが、マルチカラムに適したコンテンツと、全く適さないコンテンツがある。カラム幅を何emに指定すればよいかなど細かい部分もあり、デザインの適切な選択ができるのは、そのコンテンツをよく知る人間である。
<p>繰り返しになるが、HTMLのコンテンツというのは文章だけではない。マルチメディアコンテンツかも知れない。仮に文章であったとしてもだよ。ちゃんとひとつづりの読み物になっているのかさえ<strong>不明</strong>なんだよ。私は自分の想像力が足りていないことを知っている。本当はまだまだコンテンツは多様性に富んでいる筈だ。コンテンツのデザインは、そのコンテンツがなんであるかを知っている人間にしかできないものだ。だからリキッドマルチカラムを採用するかその他のリキッドレイアウトを採用するかというのは、コンテンツの性質をよく知るデザイナの判断で決めるべきことだ。その上で、ユーザスタイルシートなり、なんなりがある。

<h2>参考文献等</h2>

<p>私の<em title="理解せよといっているわけじゃないよ">意図を正しく理解したい</em>と思って下さる方は、先日<a href="http://jintrick.net/agenda/cat22/">リキッドマルチカラムというカテゴリ</a>を新たに設けたので、目を通してもらいたい。それと<a href="http://www.w3.org/TR/2007/WD-css3-multicol-20070606/">CSS3 module: Multi-column layout</a>はW3C草案だが、一通り目を通しておかないと訳が分からないと思う。英語が嫌なら私が自分のために訳したもの（<a href="http://jintrick.net/document/2007/0901/css3_multi-column.html">CSS3 モジュール： マルチカラムレイアウト仕様書邦訳</a>）があるので、参考程度にはできるだろう。さすがに訳してはいないが<a href="http://lists.w3.org/Archives/Public/www-style/">www-style@w3.org Mail Archives</a>でタイトルに[css3-multicol]を含むポストも参考になる。


]]>
        
    </content>
</entry>

</feed>
