とっぷぺーじ
ねこめしにっき
2005/12/前半
2006/01/上旬
いろんなレイアウトの中にボタンを2つ配置して、そのどちらを「OK」あるいは「完了」だと感じるかのユーザテスト FLASH 。集計結果もそのうち出されるらしい。Windows や MacOS(X) 上のダイアログであるなら、 OK ボタンをどこに配置すべきかは自ずから分かるもの。それぞれのプラットフォームの約束事として決まっているので。
しかし Web 上のはなしとなると、リンク先にもあるように、現状はルール無きムチャクチャ。なぜならば、ボタン類の配置は主に GUI 論的な観点から決定されることは稀で、ページ全体のレイアウトの都合で配置が決定される。「レイアウトの統一によるナビゲーション行動上のユーザ学習効果の励起」とかちゃんと考えて設計されたデザインの場合でも、レイアウト全体から見たそのボタン用領域が果たして適切なものかというと、どういうわけか疑問である事も多い。
これは、常設のナビゲーションとは違って、こういった操作ボタン類はときどきしか出てこないわ、類型化しずらいわで、どうしてもレイアウト配置上の優先順位が下になりやすく、取って付けたような位置にされる事が多い。そしてたいていフォーム関連で出てくるわけだから、サーバシステムとの連携が密なページに出現しやすく、そういうページはシステム屋さんの手によるホントニ救いようのないレイアウトデザインで実装される事が多い。そして、商用サイトの場合は特に「想定ウインドウサイズのファーストビューに主要要素を収めなければならない」等の（ぼくらから言わせれば Web の特性を無視したバカバカしい）縛りから、とにかく埋まっていない空間にむりくそ収める等の不純な動機が発生しやすい。
左右に並んでいる場合は迷う。どちらかと言えば左だと思うことが多いが、これは Windows の標準的 UI に慣らされているだけという気がする。日常的に Mac を使っていたら右が OK だと思ったかもしれない。
[ [ぴ] より ]
MacOS(X) の場合、よく非マカからは上記引用のように「 OK ボタンは右だよね」と言う話を聞くけれど、正確には「ダイアログの右下」が正解。単に右下ってだけじゃなくて、右下からの位置がピクセル指定で決まってたりして。ユザはダイアログの矩形領域を認識したらば、その右下の角を見ればそこには必ず「OK」ボタンが鎮座している。ダイアログ下部にボタン 2 つあろうと 3 つあろうと、それがデフォルトボタンであろうとなかろうと（これ密かに重要）、「OK」は右下。縦横サイズが可変な矩形の図形において、その角というのは特殊な場所で、矩形が伸びたり縮んだりしても角という位置はつねに矩形の角にある（なんだそれ）。ゆえに「OK」ボタンの探索に手間はかからない。
Windows の場合、ダイアログ下部にボタン群が中寄せあるいは右寄せで配置されてて、そのうちいちばん左のボタンが「OK」というのが多い。この場合、ボタンの個数により、ダイアログ内の認識上の位置がダイアログ毎にズレる事になるので、「OK」ボタンの探索にほんの少しだけ手間がかかる。そのほんの「少しの手間」も積もり積もると、マカーはストレスを覚たりもする。
ところでボタンが縦にならぶダイアログは、 Win でも Mac でもあんまり無いなーと思う昨今、そういえば Adobe アプリにそういうダイアログが多く見られます。あれの場合、ボタン群はダイアログ右端にあって上寄せ並び、「OK」ボタンはその一番上、つまりダイアログの右上の角につねに鎮座する形。イレギュラーな配置なれど右上の角はいつだって右上の角であるので、操作感は悪くない。
右に並べたときの配置に関しては、MacOSは「利き腕に近いほうをOKにした」という話を聞いたことがあるけど本当かな。Appleが利き腕による差別をするとは思えないのでガセかも知れない。
[ ただのにっき より ]
利き腕
説は初耳だったり。なんで右下にしたのかってあたりは、昔の Human Interface Guideline とか探れば出てくるかもしれないのだけど、現行の Aqua HIG だと既成事実としてハショられていそう（憶測）。よく聞くのは、左から右の横書きする文化圏の場合、開始点である左上と終了点である右下が特に認知しやすい領域ゆえに、というもの。もちろんこれ、他言語対応とか知ったコトか的な時代の発案ゆえ、右から左のアラビア語環境とかなんて、他言語対応しまった今日日の OSX になってもちっとも考えてなさげ。
さて Web におけるボタン類の配置に話はもどりますが。
上記からわかるように、「OK」ボタンは任意の明白な矩形領域の角にある事は良い事だと信じているぼくなので、 Web においてもそうであるのが望ましいと考えます。ボタン類を必要とするコンテンツ部分があるならば、そのコンテンツ部分が象る領域の角のどれかに「OK」ボタンが来るようにしたい。かつ、ページ全体のレイアウトから見た場合でもその「角」的位置は保たれるように。そして Web は「戻る」「進む」の操作と概念が強く場を支配しており、左から右の横書き環境においては、右が進むべき方向、下も進むべき方向。総合すれば、やっぱり右下の角に「OK」を置くのがいいんじゃなかろか、と妄想はつきない。
でも、Web が利用される現場の実際は、分析や論理性や整合性や統一性による方針よりも、「慣れ」の慣性力のほうがはるかに勝る。「 Web は左が戻るで右が進む」の原則に従いサイトのナビゲーションやページングリンクを整然と配置してきて、ボタン形状のものを使った場合もページングリンクの代用的な「進む」ボタンであれば右に置いてきていたとしても、ひとたび「OK」「キャンセル」あるいは「確定」「戻る」とかって書かれたボタンを置くこととなったら、「OK」「確定」ボタンはたいてい左で、「キャンセル」「戻る」は右に置かれる。なぜなら、 Web サイト利用書の大半は Windows 環境の「左のボタンは確定ボタン」に慣れ親しんでいるのだから。 Web において「OK」と「進む」にどれほどの違いがあるのか。…って話は慣性力を無視した机上の空論扱い。「慣れ」の慣性力の話はボタンに限った話じゃない。それがさらに Web UI の混沌さを増していく。
「単なる XML 扱いだとしても XHTML 関係の DTD を参照しない Safari がやはりおかしい（？）」の続編みたいな話。
Safariの挙動がおかしいのは間違い無い(別にSafariを特別扱いするつもりは無い)。XHTML1.1として解釈していないのは間違いなく、さらにxmlns属性で参照されているはずのnamespaceを見に行っていないためエラーとなっている。言葉足らずで申し訳ない。
[ static and distribution. より ]
namespaceを見に行っていないためエラー
の意味が分かんない。いや、言わんとするところは分かるます。
あるブラウザ（というか XML プロセッサ）がある XML ドキュメントを XHTML1.1として解釈
するとは、一体どういうことを指すのか、どういう要件が満たされる事を指すのか、それはそれでいろいろと考えるところがあるかと思うわけですが。さておいて。
XML 名前空間なんてモンは所詮、とある箇所の要素や属性がナニモノであるのかを URI を目印に見分けるための単なる符号でしかなくって、文法定義や文法解釈のための機構じゃないです。後者の役目は DTD とかのスキーマの方。（ただ DTD は名前空間の取り扱いに難があるとかの諸問題があるわけだが。）
XHTML DTD で定義されている文字実体参照（が表す文字）は、結局要素ノードの中の人か属性値の中の人にしかなり得ないんだけども、それを（要素名と属性名しか守備範囲にしない）名前空間と結びつけてどうにかしてくれ、ってのは飛躍じゃないのかしら。（まぁ、名前空間 URI を元に特定の文法解釈を決め打ち処理する実装もアリかもしれんけど、本来的に名前空間にとって文法解釈なぞは知った事では無いって話。）
でもってnamespaceを見に行っていない
のトコ。通常なんのヘンテツもない XHTML1.1 文書は、ルート要素 html の xmlns 属性でデフォルト名前空間に XHTML1 を指定することで、「以降、名前空間接頭辞なき要素は（特段断りなき場合）、 XHTML1 名前空間に属するものとするのであーる」と宣言ぶちかましますやね。仮に Safari が application/xhtml+xml の XHTML1.1 を表示する際にこの事を見に行っていない
のであれば、 XHTML1.1 ソース中にたとえば <p> とかあっても、正体不明の p とかいう名前の要素であるとしか認識できないはず。なのだけど現実にはきっちり xhtml1:p だと認識していて、いかにもそれ相応のスタイルが効いている。これはどうして？
（スタイルというか CSS における XHTML1 名前空間に対する取り扱いの実装状況は、ほとんどのブラウザでナァナァ（大抵、ある要素名セレクタは HTML あるいは XHTML1 の要素を示すものである、と暗黙的にヤっている感じ）なので、ここで名前空間が効いている証拠として挙げるのはよろしくない感じではありますが、まぁ、それはそれ。）
もしくはスクリプトの力を借りて見てみるとか。どこぞの application/xhtml+xml の XHTML1.1 ページを表示して、以下をロケーションバーに叩き込んでみるとか。
ねこめしにっきヘッドラインjavascript:alert(document.documentElement.namespaceURI)
javascript:alert(document.getElementsByTagNameNS('http://www.w3.org/1999/xhtml', 'p')[0])
内部的に本質的に名前空間が活用されている実装なのかはこういうブラックボックステストでは知りようがないんだけど、 DOM インターフェイスのレベルでは名前空間のしくみを活用できる状態にあるように見えます。（ただしこの項、 Safari2.0 で検証。 Safari が XML パーサっぽい実装を内蔵したのは、 1.2 の頃でしたっけ？）
理想と現実のどこに居場所を見つけるかは、ストリクターたちの積年の悩みであって、各自それぞれ各年代、自分なりの価値判断・状況判断による解というものを持っているものだと思う。そしてストリクターたちはそれぞれの選んだ戦場でストリクト国の領土拡張の為に日夜戦っているのだ！
戦いは常に前線へ近づくほどジリ貧か負け戦だが、 MacIE5 とか Gecko とか WinIE6 とか Firefox とか Safari とか Opera とかの最新兵器が投入されるたび、インチキ SEO だのアクセシビリティ機運だのブログブームだの RSS 流行りだののイマイチ弱めのカミカゼが吹くたび、ちょっとずつ領土を拡張してきた。言えるのは、原理主義の本営はいつの時代も、最新兵器群にガッチリ固められたストリクト国の最深部であって、前線の兵士のように、正面からどんどん放たれる現実火炎放射器に焼かれそーとか、銃後の本営から精神注入ハンドアックスが飛んできたーとか、そういう心配のない、わりかし安全かもしれない場所、って事かいな。
自分のサイト（ここ）は内地に近いだけあってノンビリした戦場だが、傭兵として投入される業務案件はまさしく最前線。現実火炎放射器に作戦書を焼かれ、クライアント意向質量弾に掘りあげた塹壕実装はコナゴナ、最低限の標準堡塁を確保したのち命からがら転進したり。しかしそういう過酷な前線で、いままで試射に試射を重ねて来た最新鋭装備を試せる時など、絶頂すら覚える。
何の話だ。
「XHTML 1.0 関係者に 20 の主張 (1)」に関して。
氏が感じた私の
意図とは何だったのかについては疑問。質問想定対象は、恐らく題名にある「XHTML 1.0関係者」の事を指しているのだろうけれど、私は特に何かに対して勝利宣言する積もりはない。場合によっては勝利宣言も「出来る」だろうけど、それは私の意図ではないし、目的でもない。
[ 無為徒食日記 より ]
XHTML1.0 の選択とは、「現実を考慮・妥協してみる」という価値判断が少なからず含まれるもの。それゆえの安全牌の値ごろ感があり、それこそが XHTML1.1 ではなく 1.0 が W3C HTML 最新版である理由のひとつであり。
感じた意図
とはようするに、「現実を考慮してみた」という（純粋原理主義の立場から見れば）スネ傷を抱えている相手に対して、「オレの土俵で五体満足なオレと強さくらべしようぜ！」と言ってるようで、それはちと有利なハンデ戦を仕掛け過ぎじゃね？みたいなあたり。
またオマエわ想定外の意図を勝手に想定しやがって！とか怒られるわけだが、思ってしまうもんはしょーがないというか、こういう考えが湧くのは自身の性根の反映であるという説。
ところで真名垣さん的には、 application/xhtml+xml であるところの XHTML1.1 について、どういうあたりに魅力やら利点やらを感じて、これを選択するに至っているんですか？「XHTML 1.0関係者に20の質問」に対する、質問者自らの回答をするとすれば、そういう話になっていくだろなぁと思ったわけですが。
なんかひとりさびしく CGI いじったり日記なぞ更新しとりますが。ここに書くべきかわからんがとりあえず、妻入院中。
クリスマスイブとかドウデモイイよね。ほんと。きょうは珍しく朝早起きして、家事しまくったあとの午後は妻の病院へ行き、そのあとは寒いけど天気も良いし、昨今の懸念である iPod がチョーシ悪い件を銀座アポーストアの天才バーの天才君たちに問いただそうとか考えたのだが、よく考えれば今日の銀座なんてアータ、恋愛至上資本主義者どもの跋扈による阿鼻叫喚の地獄絵図が展開されているはずデショ！と思いとどまったのでした。既婚者だろーとしょせん基本は非モテ、街に充満する「クリスマスイブイベントを完遂せよ」とゆー強制力を伴う雰囲気はウゼェ死ねウンコ踏めー！
えーと曲のリクエストは、イブのコジャレ男女たちを祝福すべく、 Morbid Angel の Doomsday Celebration 〜 Day Of Suffering のメドレーでよろしくおながいします。
当にっきの WriteBack (コメント＋トラバ) CGI (もとは tb-standalone だったはずが、ヘタのヨコズキ的改造しまくりんぐの結果ぐっちゃんこにしたシロモノ) のスパゲティコードをさらによく絡め、自分で自分トコに発射したトラバ項目に「自作自演デアル」旨の表示を出すようにした。表示が出るのは今後トラバった分だけで、いままでの自演トラバには相変わらず何の印もつきません。
しかしあまりにテキトーすぎて何かが脆弱になったきがする。
「ほげふが関係者に n の質問」とかする質問者は、まず自身の回答を述べるべきと思った。
てかこれ、質問になってないねー？というかなんとゆーか、意図の見え透いたこの「質問」に、仮想敵質問想定対象が回答しないからって、勝利宣言するのは禁止ね。一応いっとく。
DTDが云々なんて問題では無いので、ちょっと説明。なお本文にて" 単なるXML文書"という言葉を使っているが、これは"XHTML文書では無いXML文書"とでも解釈して頂きたい。
Safariは件のリソースを単なるXML文書として認識しているようだ。XML1.0には当然
™なんて実体参照は定義されていないので、当然のようにエラーが発生している(実体参照を使わなければ問題なし)。
[ static and distribution. より ]
いやーその論はおかしいでしょう。単なるXML文書
としての XHTML だとしても、やはり XHTML1.1 DTD が DOCTYPE 宣言にて参照されている以上、 ™ の実体が定義されている事に変わりはないわけだから。やはり Safari がおかしいんでわ。
ちなみにこの日記（を含めたサイトのほぼ全部）は、周知のように（？）自家製の謎 XML を XSLT で XHTML1.1 へ変換してます。その XML を記述する際、たとえば ™ のような (X)HTML の文字実体参照が使えないのはちと不便ゆえに、 xhtml-charent-1.mod
(とその関連 DTD をローカルにパクったもの) を独自 XML のDTD として参照させとりまして (ただし独自 XML それ自身の文法定義は脳内にしか無いw) 。XSLT プロセッサの Xalan-Java は問題なくこのXML をパースして変換してくれるのだけども (ただし変換後は数値文字参照になっちまう罠…) 、 Safari みたく「単なる XML に XHTML 関係の DTD を適用しよーたってそうはいかないよ？」みたいな意味不明の意地悪をされたら、さめざめ泣く。
とっても重要なことですが、XML プロセサには妥当性を検証するプロセサとしないプロセサの二種類があります。そしてかつ、妥当性を検証しないプロセサは
文書実体以外の文書の断片を読み込む必要はないとされています。これは余計なトラフィックや処理を発生させないためです。僕の知る限り、現時点の最新版の IE も Firefox も Safari も Opera も
妥当性を検証しないプロセサです。したがって外部実体を取得する必然性はありません。Safari の解析は XML プロセサとしては至ってまっとうなものです。
[ マーク付けノート より ]
Safariが「妥当性を検証しないプロセサ」だとすると、外部DTDで定義された実体参照を展開しないのもやむをえないのかなという気はします。ただ、(application/xmlではなく)application/xhtml+xmlの文書を読めるのであれば、W3C XHTMLの文書型宣言を持つ文書に対しては、せめてXHTMLで定義されている文字実体参照を展開してほしいような。しかし仕様からは「そうしなくてはならない」とは言えないようであり、難しいところ。
[ 徒書 より ]
なるほど。 XML パーサモードで動作中の Safari が、 XHTML 文字実体参照を解釈しない（できない）のは、しかし完全な落ち度ではないと。まぁしかし、同様にして外部 DTD を参照してるわけではない HTML パーサモード時は、やはり外部 DTD で定義されている文字実体参照をこともなげに扱っているんだし、 XML モードの XHTML に対してもそのくらい便宜をはかってくれてもいいじゃないか、とかのワガママは言っておきたい。
そんなわけで、汎用性を考えるならなるべく実体は使わないことをお勧めします。そもそも UTF-8 なら直接記述できるわけですし、文字コードやツールの問題で入力不可能/困難な文字があるなら、そのときは対応する文字参照で記述する、というのが次善の策じゃないでしょうか。
[ マーク付けノート より ]
うーんしかし、文字実体参照の使用は控えよというのは、 UTF-8 の選択がまだまだ冒険であるような条件下だと、現実作業上、えらいこっちゃになりますなぁ…。
それはそれとして、真名垣氏の日頃の無意味に挑戦的な物言いは、ハタ目には若さ故の以下略というか、いつか来た道みたく映ってなんか面映いなー。その原理主義に過ぎる理想論には懐かしささえ覚えてもうガンバレ！って気分 (謎)。彼も数多いるのじたんフォロワーのひとりだろうけど、フォロワーたちの多くは、本家のもつ一種の老獪さとか独特のユーモアセンスまでは持ち合わせないのが、のじたんファンとして残念ではある。
「Safari は XML Namespace を参照しない？」に続編っぽい記事。
Mail to Alimika Satomi
Site search
About copyrights
