agenda 2002-04(下旬) にっき。

段組の必要性4月29日

公開
2002年4月29日

多くの広告を表示しなければならない営利サイトは、右や左に本文以外のスペースを設けなければならない

広告を表示する必要が無いなら、真似る必要も無い筈。なんで真似るの?

真似る側の立場で考えれば、アレがイイのは、ブラウザのウィンドウを横幅一杯にした時。で、そういうときには、左右のスペースの少ないウチのようなサイトは見づらいわけだ。不本意だねえ。

要するに迷惑。多くのアクセス数を稼ぐ営利サイトのおかげで、ユーザーはウィンドウ幅をかなりの程度広げる癖をつけている。本来ならば各ユーザーがそれぞれに最適な幅で閲覧するのが一番なのだが、そうしたサイトの存在が、自由を奪っていると言える。ウィンドウ幅は80%くらいで、さらにサイドバーの類を表示させたい私にとっては、頼むから止めてもらいたいところなのだ。外部CSSなら良い。しかしテーブルレイアウトともなると、Operaでも使わない限りこちら側の対処は現実的でない(何度も足掻いた)。Operaを使ったとて、W3Cのようなテーブルの使い方でないとアウト。

どうせユーザーはウィンドウの幅を広げているのだから、それに適応したレイアウトを組もう、と考えるのも自然であると言えよう。なんともやるせない話だ。

そこで考えたのが以下。

真・ふわふわレイアウト4月29日

公開
2002年4月29日
body{
 margin-left : expression(
  document.body.clientWidth * 20 / screen.width + '%'
 ) ;
 margin-right : expression(
  document.body.clientWidth * 20 / screen.width + '%'
 ) ;
}

注:bodyセレクタ等文書中一つしかないようなものでないと使い物になりません(複数のセレクタに適用すると計算等に時間がかかる為)。Internet Explorer5 later限定。

特徴は例示すると次のようになる:

ウィンドウ幅最大化時
左右のマージンは約20%
ウィンドウ幅50%時
左右のマージンは約10%

要はマージンの相対値が、ウィンドウ幅に比例してさらに相対的に変化するというもの。

800あるいは640ピクセルの場合にはもっと小さい数字であることが望ましい。つまりこう。左右マージンの値は:

  1. ウィンドウ幅
  2. 最大ウィンドウ幅
  3. ウィンドウ幅 ÷ 最大ウィンドウ幅

これら全てに対して相対的に変化するべき。

この、「ウィンドウ最大化時左右マージン20%」という数字が、screen.width = 1024 の時に最適な数字であるとすれば:

body{
 margin-left : expression(
  document.body.clientWidth * screen.width / 50 / screen.width + '%'
 ) ;
 margin-right : expression(
  document.body.clientWidth * screen.width / 50 / screen.width + '%'
 ) ;
}

こうすると、例えば640*480の解像度の場合、左右のマージンは最大約12%ということになる。……多すぎか。もっと極端なカーブを描かないと駄目だな。

他、本文を一つのdiv要素にして、max-widthをemで指定するというのを考えた。左右マージンはautoで。だがこれは却下。余計なdivが増えるし、最適な一行文字数は決めたくない。

たぐ。4月28日

公開
2002年4月28日

idたぐ。classたぐ。いんCSS。

まあ何かこちらが勘違いしているかも知れないので投稿してみた(via form (英語))。

ハイ。溜まったストレスをぶちまけてみただけです。ごめんなさい。ああ、思い切り皮肉を入れてしまったよ。相手が日本人だったら、90%の確率で「逆切れ」を誘発しそうなやつ。でももう遅いや。

Beta Versionと明記してありかつ公にフィードバックを募っている辺りあっぱれな態度なだけに、あの皮肉はまずかった。

「叩くんならコーディング専門サイト叩きなさいよ、馬鹿(かなり意訳)」とか言われた後だっただけに、頭に血が(以下略

Thank you for contacting us. We will reply as soon as possible

鬱だ。

推奨ブラウザ4月28日

公開
2002年4月28日

見易さを追求しているつもりではいるものの、ブラウザのデフォルトより見易いとは断言できないので、見栄えの観点で何らかのブラウザを推奨することはしません。

時の影4月28日

公開
2002年4月28日

全てが満たされたなら滅びるしかないが、滅びることを知っているが故にやはり満たされることは無い。

形にするのは、滅びることへの反抗である。咆哮は畜生でもすることだ。ある種の表現は咆哮とは違う。

古いブラウザ4月27日

公開
2002年4月27日

海外で良くある「推奨ブラウザメッセージ」の恐らく出所であろうサイトを教えていただきました。

<h1 class="ahem">
This site will look much better 
in a browser that supports 
<a href="http://www.webstandards.org/upgrade/"  
title="Download a browser that 
complies with Web standards.">
web standards</a>, 
but it is accessible to any browser 
or Internet device.
</h1>

The Web Standards Project: Fighting for Standards in our Browsers より

これをdisplay:noneしてはどうか、と提案されているわけですが、pタグにした方がより良いとも書いてあります。だったら最初からベストな例を提示するが良いのです。何故しないのか。誰かから「つっこみ」を貰って追記したと考えるのが自然です。

古いブラウザはページの見栄えが寂しくて然るべきです。と、こう表現すると差別主義者かと思われるかもしれませんが、左にあらず。逆に考えれば明白です。なぜ、新しいブラウザをインストールする手間をかけた人が、古いブラウザと同じクオリティの見栄えで我慢しなければならないのか。これこそが不平等です。手間等の何らかのペイのあるなしに拘わらず、新しいブラウザを使っていることの優位性に過ぎないともいえます。ブラウザにおいて新しいとは何か。優位性を追求した結果です。

つまり古いブラウザにも同じ見栄えを提供することが「平等」であるならば、その平等は優位性を否定することになります。より良いものを追求しようという姿勢をも否定するのです。

複数のブラウザに同じ見栄えを保とうとするのは良いのです。しかし、それを追及しないことをダサいと評価するのは愚かです。しかし、さらに愚かなのは、異なる見栄えの穴埋めをユーザーにさせようとすることです。

著者が想定する「従順な閲覧者」には有益な情報かもしれません。しかしその他大多数の「気ままな閲覧者」には無意味(場合によっては、かつ不快)でしかありません。


情報を提供して下さった方にはこの場でお礼申し上げます。無駄な英文を書かずに済みました。

呪文。4月27日

公開
2002年4月27日

<html> ここから、HTMLが始まると言う呪文

Makeing Home Pages HTML1 より

……ですか。

始まれHTML! えいっ☆

<html>

反撃くる4月25日

公開
2002年4月25日

長文が来たです。ミネソタから。

以前までの流れはこのようになっています。

  1. アクセシブルでない 4月20日
  2. 問うか問われるか 4月23日

海外の個人CSSユーザーが、アクセシビリティ、ユーザビリティ周辺についてどのような考えを持っているか、その一端に触れました。

まず、<a class="within" href="#" onclick="popupImage()">this</a>。このthisは、アンカーテキストではないのだそうです。ではなんでしょう。聞いてみたいところですが、直後に "This" is the most likely word english-speaking people would use as the link、といっています。word used as a link、そういうものを私はアンカーテキスト(anchor text)と呼んでみたわけですが、意味が違うのかも知れません。

スクリプトオフの場合、画像(CSSを適用した際のサイトの画像)を見ることができませんが、それはユーザーにとって重要ではないのだそうです。どうして見ず知らずの他人のことが分かるのか。というか、面倒臭がって「明らかにベターな例」を提示するのを怠ったのは失敗でした。

最後に、なぜ、ページの最上部の「ウェブの規格に準拠したブラウザの使用を推奨するメッセージ」が、h2要素としてマークアップされているのかについて。これに関しては、興味深い「説明」を頂きました。なんと、CSS非対応環境のユーザーにfontタグを使用せずともボールド&ラージなテキストを提供するためなのだそうです。

しかし、彼女はXHTML Transitionalを選択しています。後方互換性のために間違ったマークアップをするくらいならfontタグ等を使った方が良いのですが、要するに海外では、固定観念的にfontタグをタブー視しているだけなのではないか、という疑問が生じました。

他、このサイト(名前とか)について、いちゃもんというか「アドバイス」を頂きました。Personalの方が良いそうです。でも、personnelは英語の方じゃないので的外れ。idees personneles

強制改行ふたたび4月25日

公開
2002年4月25日

> <br>を<p>に

1文字減るのとスタイルあてるのと、どっちがレンダリング的に軽いですかね。
転送量等で言えば<p>のほうが減るのは明白ですが。

htmlとか - 不具合等どうぞ より

本音を言うと、1文字少ないというのはオマケでして、ノードへのアクセス手段だとかスタイル変更の柔軟性がなくなるという意味で <br>でなく<p>の使用を提案しました。この辺りの話で過去何度かHTMLアレルギーを起こされたことがあるので理由を誤魔化してしまいましたけれども。

というわけでデータの質うんぬんではなくて、より表示の軽い方を、というアプローチでしたら……どうなんでしょう。ちと微妙すぎてどちらが良いのか分かりません。

br不要論者としては、brを1000個書いて表示速度テストをしてみるのも面白いかもしれません(やりません)。

徐々にずれてゆくスタイル(IE限定)4月24日

公開
2002年4月24日

要素の出現順で紹介した方法を使って、だんだん右にずれていくスタイルシートのルールを書いてみました。IE限定。

p
{
    position : relative;
    left     : expression(this.sourceIndex);
}

IEで、BLOCKQUOTEがだんだんずれていくアレの対策に(使えないか)。

要素の出現順(IE限定) - sourceIndex -4月24日

公開
2002年4月24日

HTML Elementがソースに出現する順番を保持しているプロパティを見つけました。工夫次第で使えそうです。

お目当ての「何番目の子か」を保持しているプロパティは見つからなかったのですが、文書構造が固定的なら、例えばparentNodeのsourceIndex値を引くなどして同じような結果が得られるかもしれません(この場合兄弟がテキストノード以外含んでいない必要がある)。

確認したところ、HTML要素が0、HEAD要素が1という値を持っています。

タグの省略など4月24日

公開
2002年4月24日

リストが面倒なので<br>で済ませた。ダメか。

fub_red 0.3.33β - 不具合等どうぞ より

<p>りすと項目
<p>りすと項目
<p>りすと項目

こうした方が、一文字少ないです。IE向けの場合、p{ padding : 0 }しないと強制改行した場合と同じになりませんけれども。

この他、HTML4.01及びMSHTMLで省略できるもの:

  • liの終了タグ
  • html, head, bodyの開始タグと終了タグ

等々。

マークアップが面倒だという場合、まずhtml、head、bodyタグなどを書くのを止めて、brで整形するのをできる限り控え、pやliの終了タグだけの省略はしない、という書き方を推奨します。

<html>

<head>
  <title></title>
</head>

<body></body>

</html>

このようなテンプレートは、楽をしたいという動機であったとしたら実は全くの無意味だったりします(XHTMLは除く)。必要なのは<title></title>だけ。IEの場合、document.documentElement.outerHTMLを覗いてみると分かりますが、勝手にhtml、head、bodyタグを補ってくれています。

以下私信っぽい。iframeの高さについて。

buttonBarの高さが不定なら、IEの独自拡張を使ったこの方法もあります。

iframe
{
  height : expression(
    document.body.clientHeight - buttonBar.offsetHeight
  )
}

expression()関数内で計算された値が、heightプロパティの値になるみたいです。

尚、buttonBarというのは、これに置き換えても多分同じです:

document.getElementById("buttonBar")

省略しているだけのように見えますが、IDに直接アクセスするのが一番効率的だとか何とかという記事を以前に見かけたので探してみました。

と、これ以外にも色々あるので、複数のSPAN要素(ハイライト用のアレ)等に同名のidを使うのはエラーの可能性を孕んでいます。idはユニークであるべきです。私はグローバル変数名を考えるような気持ちで書いています。

問うか問われるか4月23日

公開
2002年4月23日

ミネソタの庭師 (英語)から電子メールが。毎度のごとく紹介の内容について問い詰められたが、正直に答えた。

署名その他によるとウェブデザイナということらしいので、逆に問い詰めてみるという選択肢も。

風邪薬は要らない4月23日

公開
2002年4月23日

先日の風邪。頭痛については例の特効薬「オピス」で抑えることができたし、フラフラするといっても1mmくらい宙に浮いているのだと思えば、特に気分が悪いというわけでもない。体が嫌に熱いのだって、ウィルスとの戦闘によって生じているのだと考えれば、むしろ安心感となる。そういうわけで、土曜の夜10時頃に寝て、日曜の朝8時頃に起きた時には、すっかり直っていた。風邪薬は飲んでいない。

別に知識があるわけでもないが、市販の一般的な風邪薬は、風邪の症状を緩和させる薬であって、風邪を治す薬じゃあないと思う。むしろ、あれで直った気になって、無理に動き回ってしまう可能性さえある。風邪の症状(発熱等)なんて、風邪を治すのに必要だから起っているに違いないのに、緩和してどうするのか。

また、風邪薬を飲むと、直ったかどうかがはっきりしなくなってしまう。つまり、仮に市販の風邪薬に風邪を治す効果があったとしても、症状を緩和する成分は邪魔なのだ。本当に辛い、頭痛だけをなんとかすればいい。しかし複数の薬を併用するのは危険だ。従って、私は風邪薬を飲まず、頭痛薬だけを飲むのである。もちろん頭痛がなかったら何も飲まない。

環境4月22日

公開
2002年4月22日

我々の生活は人工物と自然物に取り囲まれている。さらにある意味では自然物であり、別な意味では人工物であるような人間にも取り囲まれている。その意味で、我々の生活における環境や対象は、人工物、自然物、人間の三つに分けることができるだろう。

黒須教授のUser Engineering Lecture より

人工物に対しては「使う」。自然物に対しては「共存する」。人間に対しては「協調する」という動詞を対応させて、目的に向う手段としての広義の「使う」(というより「使う」の上位概念)を認識しようという試み、と読んだ。

自分自身の肉体は、「共存する」という動詞がしっくりくるように自然物だけれども、快不快に関して錯覚を生じさせる「観念」はどれにも当てはまらない。この色眼鏡も私にとっては環境だ。「自分」には含まない。

xpointerモドキ4月20日

公開
2002年4月20日

child sequenceの形式を拝借して、xpointerモドキのURLを作成しようという試み。

function Jpointer(){
    var es = event.srcElement;
    var indexAry = [];
    var k = 0;
    while(es.parentNode.nodeName != '#document'){
        var children = es.parentNode.childNodes;
        for(var child, i=0; i<children.length; i++){
            child = children.item(i);
            if(child === es){
                indexAry[k] = i + 1;
                k++;
                break;
            }
        }
        es = es.parentNode;
    }
    var jpt = indexAry.reverse().join('/');
    var uri = document.URL.split('#')[0] + '#/' + jpt;
    alert(uri); // 実際はクリップボードにuriをコピー
}

こんな感じのを、右クリックメニューに登録しようと思ったのですが……。

どうも配列番号がずれてしまいます。何故。

風邪をひいてしまって頭がぼんやり。なんかフラフラするし。これから寝込むので、メモを残しておくです。

何がしたいかというと、長い長い文書を読んでいるとき「ここまで読んだ」というメモを残したい。しかし実際にメモを残すなら、ローカルに保存するしかないわけで。そこで、「ここまで読んだ」という情報をURLに託して、それを元にWWW上の文書の当該箇所にユーザーjsにてid属性をつけて、location.hrefで飛んでみようかと。

サクっと作れるかと思ったら躓いてしまった。苦労してまで実現したいって訳じゃないのに。そんな長い文章、滅多に読むものじゃないし。さ。

これは child sequenceを解釈するユーザーjsの方。

function Jpointer(){
    var jpt = document.URL.split('#/');
    if(!jpt[1]) return;
    var s = jpt[1].split('/');
    for(var i=0; i<s.length; i++){
        var index = s[i]-1;
        var root = (!i) ?
            document.documentElement.childNodes.item(index) :
            root.childNodes.item(index);
    }
    root.id = 'jpointed';
    location.href = jpt[0] + '#jpointed';
}

これを、window.onloadなり、IE限定ならscript要素のdefer属性なりを利用して文書読み込み後に実行。

ウィルスには細心の注意を払っているにもかかわらずこれだ。リアルな方のウィルス。日曜は一日中寝込む。

アクセシブルでない4月20日

公開
2002年4月20日

This site will look much better in a browser that fully supports web standards but it is accessible to any browser or Internet device. Upgrade your browser now for a much nicer view. Wouldn't you rather look at this?

Minnesota Gardener @ CSSオフ時 より

この文句がh2要素である。しかも最上部。良い見栄えで見てもらいたいという意思の強さを感じる。

問題は、Wouldn't you rather look at this?の、this(アンカーになっている)が、言っているそばからaccessibleでないこと。

公共の場4月15日

公開
2002年4月15日

ウェブは公共の場であり、公共の場では客觀的な意見を述べるべきです。

闇黒日記 より

ウェブは本当に公共の場だろうか。もしそうなら、公共の場で一人鍵をかけて「私有地」を作ってしまうのは反則ということになる。そもそも反則と言っても公共性を守る為の管理者がいるわけでもないのだから「極めて混沌とした場である」としか言えない。もしくは「公共の場であるべきである」と主張することはできる。

というわけで、「ウェブは公共の場であるべきである」と思っている私は、一部のサーバーサイドスクリプトが大嫌い。具体的には、管理者と名乗る人間が勝手にログを削除できる掲示板が大嫌い。折角リンクというものがあるのに、こういう不心得な「管理者」がいるものだから、各々保存しなければならなかったり、転載しなければならないこともしばしば。

余談。本屋で、「個人Webデータベースの作り方」なる本を見た。URIをパスワードにするんだそうな。

ふと、某アレを利用する手を今更思い出して、「死んだリソース」を復活させることを試みてみた。

こころのたな。氏 対 ネチケット千夜一夜氏 のリンク論争の残骸があります(8/12以降)。当時は本当に興味深く読んだものでした。)

読み返してみると、「いたろう」と名乗る投稿者の発言、態度が矛盾だらけで胃が痛くなってくる。件の最初の発言(00/08/20 17:14:33)からして、自由であるべきでしょうが結論にきている。

経験上、「自由である」を結論にする発言が正しかったことは一度としてない。「自由である」は多くの場合前提であることは何度も書いた。

と、思ったら一度だけあった。JavaScriptは犯罪幇助だ、という主張?に対して、「いや、自由でしょう」というやりとり。わらい。犯罪であるかどうかが争点であるような場合なら、あり得る。しかしある行為がナンセンスだという主張に対して「いや、自由だ」というのは完全に馬鹿にしているとしか思えない。本質的に自由だなんてことは誰だって知っているからだ。

それはともかく、それまで完全に「こころのたな。」氏の意見に賛同していたところへきて再考させられたのが、ネチケット千夜一夜氏の発言( - 00/08/22 08:41:15)だ。 中身を読む限りもっともらしくて頷ける部分も多いのだが、結局のところ、本人も書いている通り:

結論から言うと、私は『作者の希望を尊重する』というのがネチケットだと思っています。

ねちけっと掲示板2000 より

これが結論であって、全く同意できないのだ。何故なら「ウェブは公共の場であるべき」であり、福祉の方を優先すべきだからである。作者の希望とやらがそれに反している場合、そのようなものを守るのがネチケットではあるまい。それは個人的な気遣いである。


とまあ、こんな風に色々考えさせられた記念すべきリソースなのでありますよ(管理者権限で勝手にリソースを削除する行為の非に気づいたのもこの思索がきっかけ)。しかし、管理者の「個人的な気遣い」により、ログはあっさりと削除されました。そういう人が、ネチケットについて色々語っているのです。このねちけっと掲示板2000を管理している方が運営している「ネチケットを笑い飛ばせ」には、「ネットワークで嫌われない為にはどうすればよいか」が細かく書かれていますが、ネチケットとの関係は不明です。

一投稿者の事情を勝手に推測などせず、現在、将来の閲覧者のためにログを残す努力をするのは「ネチケット」と呼ばれて良い、と私は胸を張って主張します。自由な参照が簡単にできるというのは、WWWの最も重要な特徴の一つであって、それを個人的な事情で損ね、他のリンクしている運営者に迷惑をかけ、デッドリンク等々の無駄なトラフィックを生じさせる、という事実は、程度の差こそあれ、チェーンメイルと似たようなものではないですか。


読み直してから考えた命題。

リンクに対する制限を肯定する論者は、従って、「ウェブは公共の場であるべきではない」という主張をしなければならない。

話はそれから。


「リンクするな」と、「なるべくリンクはトップページにお願いします」は違うというのはネチケット千夜一夜氏の主張。確かに違う。後者のほうがある意味で悪質だ。弱者を装っているからである。そしてその「弱者のお願い」を無視された時、「マナー違反」だの「人として駄目」だの散々の悪態をつかれる恐れがある。公開されなかったとしても陰口を叩かれる恐れがある。そういう陰湿なやり方の温床を作ってしまう。だから、ナンセンスだと言うのだ。

忘るるナリ4月15日

公開
2002年4月15日

自己を習ふといふは、自己を忘るるなり

「死ね」ということか。

感傷は、創作物の源泉になり得るけれども、それを創作する際には、感傷は殺していなければならない。とは、師の言葉。自己表現も同じく、表現したい「自己」がセンチメンタルなものであるとしても、それを表現する際には死んでいなければならない。