フラットな文書を構造化 (agenda)
agendaを試験的に構造化。agenda.xmlをagenda.xslで（構造化されたdivだらけの）HTMLに変換。ただ、XSLファイルを書いていて面倒臭くなってしまったので、h6要素を脳内から抹殺。使ったことないし、これからも使わないだろう。たぶん。で、実利は……今のところほとんどないだろう。でもXSLTが面白くてしかたないんです（手段の目的化）。というのは半分冗談。 agenda.xmlは基本的にフラットでリニアであり、何の変哲もないテキストエディタで作成、編集する。脳内スキーマに基づいた、いい加減な代物だ。つまり構造を「暗示」しているXML文書だって「アリ」だと、そう言いたいわけで。「暗示」をタブーにしてしまったら、マークアップは際限がなくなる。そしてマークアップは、人間も、直接行うことができるように考えられたものだ。特別なツールがなくともリソースを作成できるのがメリットの一つで
ナビゲーションとは何か、そしてそれは「分離」すべきなのか (agenda)
WWWの文脈においてナビゲーションという言葉の意味を考えるとき、浮かんでくるのはやはり一人一人のユーザーの姿である。それぞれのユーザーの目的地（目標）に導いてやるためのインターフェイスというのがナビゲーションのエッセンスだ。 文書製作者側が提供できるナビゲーション しかしながら、製作者側はユーザーの目的を正確に知ることができない。知っているのはユーザーがそのハイパーテキストノードを閲覧しているという事実だけであり、そこから目的地を推測するしかない。この時推測される目的地は、正にそのハイパーテキストノードと深く関係しているはずだ。そして、そのようなリソースへのリンクを提供することは、ハイパーテキストシステムにおける各ノードの主要な役割である。真のナビゲーションに接近する方法として、製作者側が取れる、あるいは取るべき手段は、そのハイパーテキストノードを中心としたリンクを提供してやることだけであ
var要素をプログラムコードではない通常の文章に使う (agenda)
きちんとしたPNG画像で「作品」を公開したところ、GIF画像しか読めないソフトウェアで閲覧しようとして失敗した事実を突き付けられ、「馬鹿には見えない作品なのですか？」と、とぼけられたり、駄目ソフトウェアがクラッシュした事実を突きつけられ、「観れないどころの騒ぎじゃないですね。もしかして、あなたのいう『作品』というのは『正しいPNG画像フォーマットで書かれたアプリケーションクラッシャー』のことを指しているのですか？ そう仮定するなら、なるほど、なんとも素敵な作品です。天才的なセンスを感じます。」とか皮肉られたので、画像ビューワの実装が悪い、とお決まりの反論しておいた。この画像ビューワ、何百、何千と種類があってしかも、その多くはPNG画像を表示できて無料なのに。自分は何か間違っているのでしょうか。云々。例文終わり。 私はこのようなvar要素を「散文的変数」と呼んで愛用している。 というか、ウェ
ウェブブラウザなんかに気を遣わなくてもいい理由 (agenda)
いつの間にか2009年になってしまった。 IE6に気を使わなくてもいい理由とか「そういう系」 の話を聞くと、なんで非営利個人サイトが自分の嫌いなウェブブラウザなんかに一々気を遣わなきゃならないんだとか思う。もちろん気を遣うのには色々理由があるだろう。だが「気を遣わなくてもいい理由」というのもあっていいんじゃないか。そう思ってだらだらと悪文を書いてみた。本当に悪文だからまとまりはないよ。 相手にしていられないほど膨大な種類の「ウェブブラウザ」 この文脈においてはウェブブラウザではなく、所謂レイアウトエンジンやHTMLパーサの種類を把握すべきだろう。たとえばSleipnirもfubも、同じMSHTML.dllを利用しているなら一つとしてカウントできる。 ウェブページのレイアウトエンジン レイアウトエンジン等の名称主なバージョン（2009年1月現在）応用しているプロダクト他
p要素の終了タグを省略する際の注意点 (agenda)
HTML4.01ではp要素の終了タグ「</p>」は省略することができるようになっている。数ある省略可能なタグの中で、最も気を付けなければならないのがこの「</p>」。 DTDの再確認 まずスキーマを見てみる。p要素の内容モデルを確認するのに必要なのは次の箇所： <!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body --> <!ELEMENT P - O (%inline;)* -- paragraph --> <!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;"> <!ENTITY % fontstyle "TT | I | B | BIG | SMALL"> <!ENTITY % phrase "EM | STR
マルチカラムとウェブ・ユーザビリティ (agenda)
ウェブページの文章を読むときは「上から下へリニアに」というスタイルが一般的というか、恐らく99.9％がそうだと思う。マルチカラムで読んだ人がその慣性から引き剥がされて不快感を覚えたとしても不思議はない。視線を下への移動だけでなく上にも移動させるという、いつもと違うことをしなければならないというのは、それだけでユーザビリティ的に問題を引き起こす要因となり得るだろう。しかし、必要な「技術」は視線を移動させることだけだ。スクロールは必要ないし、マウス操作も必要ない。マルチカラムに関して生じているウェブ・ユーザビリティ的問題は、結局のところ主観的満足度の低下だけだと私は想像している。私が主観的満足度よりも重視しているのは視線の移動を失敗したりせずに「内容をきちんと読めたか」、そして「どのくらいのスピードで読めたか」。この2点。もともとスクロールが発生しないほどの短い文章ではマルチカラムが敗北するが
サイトのナビゲーションとしてサイドバーを採用すべきでない理由 (agenda)
サイドバーとは左側に位置するウェブサイトのナビゲーションのことである、とここでは定義する。擬似段組などによって主に左側に配置される。何年か前にも一度批判したことがあるが、当時は疑いを述べたにとどまっている（段組の利点 - 3つの情報ブロックがある場合 (agenda)）。その5年越しの「続き記事」といってもいいかもしれない。 第一に、サイドバーがナビゲーションバー（サイトロゴの下部に配置され、インライン方向に伸びるナビゲーション）と決定的に違うのは、それがナビゲーションかどうか分からないことである。サイドバーは今流行りの「ブログパーツ」かもしれないし、広告の塊かもしれない。自分のサイト内のコンテンツの宣伝である場合もしばしばだし、コンテンツに密接に関連した他サイトの記事へのリンクかもしれない。仮にナビゲーションであったとしよう。この時、サブカテゴリ内のリンクになっているケースもあればグロー
position:fixed大嫌い
「ウェブアプリケーションのGUI以外にposition:fixedを使わないよーに。」 ウェブログにおいて記事が主役である限り、ナビゲーションにposition:fixedを使うのはreasonableとは言い難い。馬鹿げた縦幅を持つサイトロゴ部分＋ナビゲーション部分をスクロールで消して記事を読もうとしたら、そいつらがくっついてくる。こいつは本当に頭に来る。かといってそういうサイトをブラウザデフォルトのスタイルシートで閲覧すると、ナビゲーション用の画像がリストとしてズラズラならんでしまって、さらに記事に辿り着くのが面倒になるんだ。まあ仕方ないんだけど、あの「ナビゲーションバー」のどこがUL要素なんだよって言いたくなることがある。 ユーザにとってウェブログはハイパーテキストアプリケーションの一種だ。それを操作するためのグラフィカルなインターフェイスは、ブラウザのボタンなりメニューなりに集約さ
HTML5の役割：ゴミ捨て場：agenda
私がHTMLを使用しているのは、互換性の問題がある為であり、また、2008年現在まともなハイパーテキストを出力してくれるソフトウェアがこの世に存在しない為である。つまりはただの妥協。本来私はXHTML派というか超右寄りのXHTML2.0派だ。これは一度書いておいた方が紛らわしくなくて良い気がした。勧告され、ちゃんとした編集環境があって、誰もが閲覧可能なら今すぐにでも移行したいと思うだろう。リンク関係のモジュール等を組み入れたりすることでハイパーテキストとしてもそれなりに強力になる。 HTML5はどうか。私のユースケースでは単に互換性が低くなるだけなので使わないが、ブログサービスがHTML5に移行するのは個人的には大歓迎だ。ユーザースタイルシートで余計なものを消すのが容易になる。ユーザースクリプトで必要な時だけ「ブログパーツ」を利用できるようにするのも容易くなるだろう。何よりそのようなスタイ
正しいHTML：agenda
今、「正しいHTML」を反省するのは個人的に非常に興味深いことだ。 HTMLだと「仕樣的に正しくないエラー」の部分はユーザエージェントが適當に訂正するので、最終的に處理されるのは「正しい状態の文書」である筈。 闇黒日記（平成二十年八月十日）より 理想的にはそうあって欲しいものの、実際にはレガシーな記述に対応するため、あるいは後方互換性のために訂正後の「状態」がHTMLのスキーマに対して妥当にならない場合がある。 見出し要素（hn要素; n=1,2,3,4,5,6）。これはHTMLの暗黒時代に字の大きさを変更するために使われていた為か、事実上ブロック要素を子に持てることになってしまっている。 <h2>見出し<p>本文は大きな文字に――</p> ここに仕様的な誤りがあるが、これを正しく訂正するならp要素の開始タグの前にh2の終了タグが補われるべきであることはHTML4.01 のDTDを読めば自
XHTMLのメリット (agenda)
XHTMLのメリットって何？ : 雑記帳 : der Gegenwart 私も全く分からんようになってしまった。一時XHTMLを採用していて色々なXML応用によって色々便利な活用をしたりもした。だが、それはより良いハイパーテキストを公開することとは何の関係もない。 それで飯を食っているなら、たとえ制作者側のメリットが大きくてもユーザ側のメリットも併せて考えるだろうし、その結果としてHTMLが選ばれることがあるのは特に不思議でもない。「X」HTMLであることを利用できるユーザは殆どいないだろうし、HTMLのほうが互換性が高く、より多くの媒体を通じて閲覧できる。ユーザの視点なく、制作者側のメリットの大小のみを比較して文書型を選択するプロは、はっきり言ってプロ失格だよ。 しかも制作者側の「メリット」の中にも怪しいものがある。タグの省略や禁止を覚えずにマークアップできるのがXHTMLのメリットだと
id属性をランダムな文字列に (agenda)
class や id に指定する文字列が，特定の自然言語において有意味である必要はない。 div：Wind Report - AOLダイアリーより この一文を読んで思い出したのでメモ。（classはともかく）idはむしろその性質上、全く無意味な文字列にしておいた方が良い場合も多い。idはユニークであることが求められるのだから、できる限りバッティングしないように名づけてやるとその性質を保ちやすい。 例えば、脚注にidをつけて記事内でリンクする場合など。このとき記事内の登場順にfootnote1, footnote2, ..などという安易なidをつけてしまうと、文書を結合したときに簡単にバッティングしてしまう。私は昔章立ての書籍をハイパーテキスト化したときにこの罠に嵌ったことがあるが、ウェブ日記などの場合も注意が必要だ。各記事が色々な属性で連結されてしまう。まあ連結した時点でパースしてチェック
Re: フォームのmaxlength属性 (agenda)
また、Ajaxを利用したWebサービスの登録フォームにおいて、入力可能な文字数のチェックを常に行うものや、「入力可能な文字数をオーバーしています」などのメッセージを表示させるものが増えています。このようなフィードバックを行う仕組みが、ブラウザにも標準的に導入されるべきなのかもしれません。 フォームのmaxlength属性 | Web標準Blog | ミツエーリンクスより 私の想像力が足りていないのかなあ。入力可能な文字数をサーバに再度問い合わせる必要性が分からないんだけど。Ajaxでやってるのってどこ? 私は思うにそれくらい十分標準的な方法で実現できる。DOMがそれ。しかもLevel1 HTMLで十分なレベルだ。DOM Level1 HTMLを実装しているブラウザは多い。 それともJavascriptに依存しないことがミツエーリンクスにとっての「標準的」なのだとすれば、ブラウザにも標準的に
LINK要素で二重にリンクする必要はない (agenda)
ナビゲーションをLINK要素として記述して閲覧者から隠蔽することに、一体どんな意味があるだろうか。閲覧者が直接見ても利益があるなら、A要素にすべきだ。それがハイパーテキストなら、隠すべきではない。そしてそのA要素に適切なrel属性を記述したのなら、もうLINK要素として再度リンクする必要はないだろう。ユーザーエージェントがサイトナビゲーションバーとして利用するというなら、A要素だって利用できる。rel属性を見れば良いのだから。nextというリンクタイプを見て先行読み込みをするというのなら、A要素だって利用できる。rel属性を見れば良いのだから。多くのLINK要素は無駄だ。こんな時代だからこそ、外面も中身も贅肉をそぎ落としておきたい。 サイトナビゲーションバーの理念的にはA要素で文書内に登場したナビゲーションは邪魔なのだろうが、じゃあLINK要素だけでナビゲーションを構築したサイトがあるかと
Re: マウスのホイールによる入力エラーの可能性 (ユーザビリティ実践メモ) (agenda)
マウスのホイールによる入力エラーの可能性 (ユーザビリティ実践メモ) プルダウンメニュー（select要素）がフォーカスされている時にページをスクロールさせるつもりでマウスホイールを回転させると、選択項目（option要素）が変化してしまう危険があるらしい（Firefox使いには関係ない）。 be-bitは二つの解決策を呈示している。プルダウンを使わず、ラジオボタンによる選択とするという解決策は、選択肢が多い場合などあり必ずしも適切ではない。また<select ～ onchange="window.focus()"> のようにonchange属性を追加することで、プルダウン項目を選択した時点で自動的にフォーカスが解除されるようにするという方法も、Javascript依存であり十分ではないし、そもそもユーザーの予期しないオブジェクト（be bitの例ではwindow.focus()）にフォー
マークアップ言語の設計のgoalとその利用のgoal（Re: H.O.D. 2007/12） (agenda)
暗黙的な構造では意味がないというのは以前から言っている訳で（H.O.D. 2007/12）を読んで少し考えた。 先に結論を述べる。「セクションのマークアップはやって当たり前である」という結論は、HTMLの設計目的から導かれるものではない。（これが言いたかったのに中々言葉が出てこなくて、反応がやたら遅れてしまった） HTML でマークアップする目的は文書構造の明確化であり、ソフトウェアによる論理解釈を助けるためです。 暗黙的な構造では意味がないというのは以前から言っている訳で（H.O.D. 2007/12）より 文書構造を明確化しソフトウェアによる論理解釈を助ける、というのは、HTMLの設計のgoalである。マークアップする目的は利用のgoalであり、両者は同一ではない。 div 要素と span 要素は HTML の中でブロック/インラインレベルでの文書構造を明確化するための汎用的な機構を
HTMLの採用について (agenda)
「統一病」につける藥 - 闇黒日記2.0 - Yahoo!ブログに出てくるAncient Libraryの何とかさんやXHTML原理主義者あたりの話はISO-HTMLとXHTMLに関する議論リンク集 - 徒委記で読める。 私はこの論争に参加してアンチHTMLと思われるのも、アンチXHTMLと思われるのも嫌だったので、書きたいことはあったけれども控えていたのを覚えている。 先に結論だけを乱暴に書くと、HTMLのほうが現時点で互換性に優れていて、エラー補完するソフトウェアが多く安心だから、agendaでは基本的にHTMLを採用している、ということだ。採用したからには恩恵たるタグの省略を目一杯利用して、ソースを簡潔に仕上げて編集しやすくしている。XML的に処理したいならHTML TIDYか何かを通して欲しい。 XHTML派の一部は「SGML応用のHTML」と認識しているらしいが、「XMLパーサと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
