善いことをして、惡く言はれるのが、王者といふものだ、なる古人の言葉とか、廣場で朝から晩まで忙しく働いてゐるペリクレスに一日中誹謗や非難の文句を浴びせかけた
たちのよくない男の話とか、が書かれてゐるのを目にしたけれども、俺は何うにも王者やペリクレスにはなれさうにない。
この春、朝日新聞社で座談會があつたとき、司会者の岩上順一先生が、私にかう云つた。私の小説「花妖」の妖の字は今度の漢字制限には無くなつた字であるが、それをなぜ使ふか理由をききたい、といふのである。
そこで私はバカバカしくて言ふまでもないことだけれども、仕方がないから、文部省が新カナヅカヒや漢字制限をしたからと云つて、なぜ我々が無批判にそれに從はなければならぬのか。それに對して批判を加へるのが我々文學者の義務ではないか。役人のつくつた天下りの新文法に盲從しなければならないといふアナタの考へが妙ではないか。私はかう答へた。
民主主義だの何だのといひ廻る岩上先生はかういふバカなことを言ふ先生なので、いつたいに左翼的な人たちはみんな役人型であり、ファッショ型だと思へば間違ひがない。
現在弊社に対しまして、Opera Software ASAおよびライブドア社より以下の点に関して書面による正式な通知を受けていないことをお知らせいたします。
- Opera国内販売契約の解除
- Opera社とライブドア社との間で独占販売契約が結ばれた旨
また、ライブドア社よりサポート引継ぎに関する発表がありましたが、現在弊社に対してライブドア社およびOpera Software ASA.よりサポート移管及びその日程に関する連絡はございません。
私はIEユーザーに対する「合法的」嫌がらせには大賛成。
ウェブ標準化プロジェクトの公式サイトを作成する際には気の利いた嫌がらせを考えてみたい。
「イヤガラセ」の中身を問いただすのではなく、「イヤガラセ」という単語に条件反射する意見ばかりだったのには正直うんざりした。
「気の利いた嫌がらせ」という言葉でイメージしていたのはその程度のことだ。
嫌がらせではなく
合法的の方を鉤括弧で括つたら、それは「誤解」されるよ――と言ふか、それは誤解ではない。
萌えキャラで埋め尽くされた日本地図とか言つてゐるが。
もじら組サイトのデザインは過去に何度か変更されている。そのたびに、どのWeb標準を採用するか(HTMLかXHTMLか)、個々のブラウザにどの程度まで配慮するか、などといった論点で激論が起こる。それで嫌気がさしてもじら組から離れてしまった人も何人かいるほどだ。どういうわけか、ウェブデザインの分野には他人の意見を尊重することができない人が多い。今回の騒動もその一例となった。今回の場合、組長が最初から感情的で、もじら組からの脱退までほのめかしたのには困った。あぶなくて反論することもできなかった。
吉田健一(一般・弁護士)……自衛隊のイラク派遣など憲法に従って政治が行われていない中で憲法「改正」すればそれが正されるのか。戦争への道進む憲法改正は認めるわけにいかぬ。平和主義が危うくなれば人権保障も危うい。前文や十三条をもとに権利の救済を求めてきたが改憲を口にする人はこうした救済に対して寧ろ足を引っ張っている。
今日は憲法記念日。今や国民の過半数が憲法を改正すべきだと考えているようで(日経4月世論調査)、今朝の日経社説も「憲法改正の機は熟しつつある」というもの。たしかに文章がおかしな憲法ではある。前文が長ったらしいのは特にカッコウが悪い。でも冷静に解釈すれば特に不都合がある部分があるとは思えない。解釈をきちんとすれば何ら支障はない内容である。また借金や連帯保証を頼まれた時に断る際によく使われる「それは親父の遺言でダメなんだ」という口実のような便利な使い方もできる。
Some people consider skipping heading levels to be bad practice. They accept H1 H2 H1 while they do not accept H1 H3 H1 since the heading level H2 is skipped.とあります。これは飽くまで「こんな考へ方をする人もゐるよ」と云ふ參考意見への言及でしかありません。
明らかに div 要素として存在しているものだから div 要素として明示すべきだ、と述べているのです。と書いた事があります。しかし、この意見は受容れられません。
明らかに、と石川氏は書きましたが、divの所在は誰の目にも明かなものではありません。そもそも、divは單なる汎用ブロック要素であり、必然的な存在となる事はありません。仕樣書にも、
offer a generic mechanism for adding structure to documentsとあるのみで、「要求する」の類の文言はありません。
Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.
adding structure to documentsのstructureは「文書構造」の意味ではないやうに思はれます。また、
We might use the TABLE element as follows to structure the information:と、mightと云ふ表現を使つてゐるのを見ると、この種のdivの使用を仕樣策定者が好ましからざるものと思つてゐる可能性があります。もちろん、tableの使用についてさう考へてゐる、と讀む方が良いかも知れませんが、この邊はニュアンスの問題になりますから、嚴密な話の根據として斷定的な結論を引出すのに利用するには不適切と言へるでせう。あーここで「知れませんが」式の書き方をまたやつてゐますね俺。
僕は「解析しようとすれば解析出來るやうになつてゐる」という主張が JIS X 4151-1992 14 にそぐわないものだと申しているのです。
そぐわないのか、さつぱり解らないのです。
そのような意図ならば、せめて「その爲」ではなく「その爲には」という条件付きの文として記述していただかないと、誤解を招くと思います。
というか、仮に XHTML 文書の文書型宣言を HTML 4.01 のものに書き換えても、その場合の / は NESTC と見なされるので文法上正しいはずですけれども (/ に続く > は、内容モデルの関係上 Transitional や Frameset でないとエラーになりますが)。
僕が否定したのは「SGML 文書に対する非 SGML 的な機械処理」なのですが。<hr />
を<hr></hr>
と解析するのは SGML 的な機械処理でしょう。
HTML4.01 Transitional では空要素タグを `<HR />` と書くことはできません。と云ふ警告を出した。解説には
XHTML以外では、空要素タグを /> で閉じることはできません。とある。AHLのバグと云ふ事?
この要素って一般に罫線が表示されますが、これって区切りを表す論理要素じゃないんですか?
問題は如何なる見栄えかではなく、如何なる論理構造か、なのではないのですか。論理構造はhr要素なしに明示できるし、むしろそちらのほうが好ましいのではないかと思う。
hr要素は視覺系のUAに水平線をレンダリングさせる、とそれだけです。
hrが出現するのは、brの次くらゐ珍しいはずですが。といふのは、このやうに考へればhrの使ふ余地は見出しにかからない文字列を対象とした場合で、それは野嵜氏の闇黒日記のやうな、dl-dt-dd型マークアップゆゑに日附の区別をつけなければならないやうな場合と、h1要素が出現する前にある文字列に区別をつける(例へばパン屑リストとサイトコンテンツを区別するやうな)場合くらゐしか私は思ひつきません。
dl-dt-dd型マークアップ――と言ふより、ただのテキストの羅列をマーク附けしただけなので、hrは別に要らんのですが、見てくれの調整の爲に入れてゐます。誰も入れてはいけないと言つてゐないので。
余談ですが、XHTML Basic には hr がありません、とか、XHTML 2.0 でも hr はなくそうかとか、名前を変えようかとか言った話が出てます、とか。ご参考まで。
ご参考までなのだらう。
ISO/IEC 15445:2000 も当然この主張を踏襲しているからこそ、Pre-HTML の機構についてと述べてゐて、石川氏はISO-HTMLに問題が無い事は解つてゐる筈だ。問題がないのに何を問題であるかのやうに石川氏は言つてゐるのだらう。which is not a part of this International StandardとかValidating systems are required to support these techniques, but conforming systems are not.とかand conforming systems are not required to support such a constructionなどと注記しているのです。
もし、この「要素」 ― すなわち「見出しを含む div」 ― をマーク付けせず、しかもそれでなお「見出しから見出しまでの範囲 (例えば div1 疑似要素のような)」を扱うことを期待するのであれば、それは最早 SGML などではないと書いたのか、いまだに俺にはわからない。俺は何も期待してゐない。俺はただ「解析しようとすれば解析出來るやうになつてゐる」と述べたし、述べてゐるに過ぎない。
ISO-HTML の仕様では DTD の制約上、できあがる文書(データ)の構造が特殊なものになるから問題にしているのです。なんて嘘を書いてゐるし。ISO-HTMLの文書はW3CのHTML 4.01に準據した正しい文書になるのだし、そもそも文書の構造について何も定義してゐないW3CのHTML 4.01の觀點から
文書(データ)の構造が特殊なものになる等と云ふ批判を行ふ事が不可能である。
機械的に処理できればよいと言うものではありません、なんて言ふのならば石川氏、hrやimgやbrを含むXHTMLのデータはHTMLのパーサで常にエラーになるのだから不可、と言はなければならない筈。「<hr />の/はHTMLのパーサではエラーとして無視される」と言ふのを石川氏は認めてゐるらしいのだが。と言ふか、「<hr />」を「<hr ></hr>」と機械的に處理する事について、石川氏は辯解するなり、謝罪するなり、した方が良くないですか。
仕様に記載のない (しかも、もしそのような記載があれば仕様が破綻してしまうような) 事柄を、恰も仕様が要求しているかのように述べていらっしゃることが問題だと言っているのです。
僕は "見出しレヴェルに據つて文書の内容をツリー状に構造として解析する事がパーサに要求されます" という記述を、「ISO/IEC 15445:2000 は SGML 構文解析系に対し、h1-h6 に対応する div1-div6 的なコンテナ要素を付加して文書の構造を解析するよう要求している」という主張として解釈したのですが、この解釈が間違っているのでしょうか。
ISO/IEC 15445:2000では、W3CのHTMLが定める以外の要素は追加しない方針をとつた爲、解釋に依つてベーシックなマーク附けから文書の論理構造を解析出來るやうに定められてゐます。その爲、見出しレヴェルに據つて文書の内容をツリー状に構造として解析する事がパーサに要求されますが、と俺は書いてゐます。飽くまで「解釋したいパーサは解釋出來る」と書いてゐるのであつて、「SGMLパーサは常に××しなければならない」とは書いてゐません。ISO-HTMLの仕様書もさう云ふ事を言つてゐるに過ぎないのではないですか。だから前から「暗示」「示唆」と書いてゐるのですし、今も「解釋出來る」と書いて「解釋しなければならない」と書かないでゐるのですが、それを「機械的な處理を期待し、暗示を常に讀取つて貰はうとしてゐる」等と解釋されても困ります。
これを受けてbtmさん(誰)が、全然楽しくないイヤガラセ計画、そしてもじら組の総意という発言を行っている。
btmさん(誰)と書いてゐる。もしいわい氏がbtm氏の事を知らないからこんな風に
(誰)を連發してゐるのだとしたら、それはそれで問題だと思ふ。
(誰)を連發して面白がつてゐるのだとしたら、小池氏が面白がつて「嫌がらせ」云々と言つてゐるのと同樣、不快なものであると言つて良い。
これから立ち上げる予定らしいのだが、どんなものになるのやら。
もじら組のWeb標準普及プロジェクトではありません。と小池氏は「kazhik.mozilla.blog:Web標準化プロジェクト≠Web標準普及プロジェクト」で述べてゐるが、Mozilla JLP :: トピックを表示 - 共同ウェブ標準化プロジェクト(仮称)準備委員会の發言を見ると、中野氏とMoonstone氏とは、既存のWeb標準普及プロジェクトとopen the web -MoonStone'S Laboratory-とを引繼ぐのが「Web標準化プロジェクト」であると認識してゐる。
しかし、例えば僕などは日記をみてもらえれば判るようにキリキリ監督に尋常ではないレベルの妬み・嫉み・恨みを抱いているが、それとこれとは別で、「CASSHERN」という映画じたいは素晴らしく面白い!と手放しで絶賛してるし、云々。
嫌がらせが許される筈もない。と、日頃、天誅の名の下に惡質な嫌がらせを受け續けてゐる俺は言ひたい。
文字化けするのはエンコードしていないからではなくてcharsetが合ってないからです。
observation of or practical acquaintance with facts or events.といつた解釋が載せられてゐて、「見聞」「見聞きする(した)事」をも意味する。
ブラウザを選ばないWebサイトを作ろう!
<a href="http://ja.wikipedia.org/wiki/富山ライトレール">[[富山ライトレール]]</a>
と云ふ書き方をしてゐる。この時、Operaでジャンプすると、目指す「富山ライトレール」には辿り着けず、文字化けしたタイトルの「存在しない記事」に行つてしまふ。でも共通して言えることは、「使いやすいものは使いやすく、使いにくいものは使いにくい」ということであって、「標準的なインターフェースが一番使いやすい」ということではないと思います。
ユーザーの環境なんてWebページ以上に想像がつかない訳ですから、 独自インターフェースと共に標準のインターフェースも併設しておく必要があるのです。
このような理由から独自コントロールが作られたりします。
ただ、そのような非標準なインターフェースでできることは標準的なインターフェースからもできるようになっているべきで、 選択の余地は残されているべきです。
ゲームはコンシューマは仕方ないと思うのですが、PCゲームはどうなんでしょう。