Coolの広告がポップアップに変わった(怒)。
何でも第二部が終わって/0が始まったのは七月のウルトラマンコスモス開始に併せての事だったらしい。
その所為か、ここ最近アニメゾイドファンの間で「ウルトラマン憎し」の雰囲気が拡がっている。どうしようもなく悲しい。
自分も自転車の篭にライガー・ゼロやシュナイダーユニットのパッケージを放り込んでで街行く人間だからどうとは言えないのだが、今日部屋に帰る時に、篭に入り切らないほど大きなプラモデルの箱をハンドルに括りつけた自転車とすれ違った。恐くガンダム。詳しくないので本当かどうか、パッケージに描かれていたのは赤くて一つ目だったので多分シャア専用機。こう、カジキの口みたいなのが頭の上に延びていた気もするけど。
転けたら大変だろうな。
text-decoration:inherit
やfont-size:inherit
は理解するのに、font-style:inherit
やfont-weight:inherit
は理解してくれない。
N6ではちゃんとなるため記方は間違っていない様子。僕的には嫌なのだがこう言う細かいバグに付合うのも面倒だし閲覧には支障が無いため放置。
今の今までIE5:macは子供セレクタや隣接セレクタには未対応だとばかり思っていたのだが、どうも対応しているらしい。
これは使える。
「汎用性」を考えて設計し始めると、頭が痛くなって来た。自分が無意識の内に使っているローカルルールがDTDやWAIのガイドライン上では全く意味を成さないからだ。
例えば、見出し要素内のstrong
。Mosaic系のデフォルトスタイルシートでは見出しそのものがstrong
と同じbold
で表示されるので見出しをstrong
で括る人は少ないと思うが、アクセスキー等の為に含める人はいるかも知れない。こう言った組み合わせが無限にあって、入れ子関係等も含めてあらゆる状態を定義しなければならない。
あと、ユーザースタイルシートで一体どのような指定をしているかも全く予測不可能で困る。例えば最近のMozillaはabbr
、acronym
にdotted
を使ったborder
を指定しているのだが、僕はこの手のインライン要素に指定されたborder
が嫌いだったのでLavenderでは一々消していた。このように、実際に記述するCSSファイルはどうしてもブラウザに依存する。
大抵の HTML 文書で問題なく使えます。
と言う事は、ユーザースタイルシートとして自由に使っても構わないと言う事でしょうか?
自分の書いたスタイルシートがどのくらい汎用的なのかをテストしてみた。殆どのW3Cの仕様書はstyleディレクトリの"default.css"と言うファイルを読むように出来ているので、それを書き換えて自分の好きなファイルを読み込ませる。テストしたのはHTML4仕様書とCSS1、2仕様書、どちらも邦訳。
デフォルトのBlackboardをはじめPastel、Lavender、Lemonchiffon、Bluetoneと、やはりレイアウトそのものをdiv
に頼っているために殆どがぐちゃぐちゃ。div
で幅を狭め、マイナスマージンで色々やっているBlackboard、Lavender、Lemonchiffon見出し部分がはみ出す事があり読めない。PastelとBluetoneはマイナスマージンが少ないため読もうと思えば何とか読める。(関係ないが、W3Cの仕様書には必ず末尾にaddress
が付いている。ウチのサイトのbody内のナビゲーションを書き換える次いでにやってみるか?)
ちょっと反省して制作中のスタイルシートを書き直す。div
に頼らずレイアウトするために葉っぱ要素のmargin
を大きく取ったりするのだが、これが入れ子になった時の為にいちいち定義し直さなければならないのでかなり面倒な作業。div
で括る方式がいかに簡単かを実感。同時にセクション分けを標準でDOM実装していないW3Cの規格に私怨増し。子孫セレクタを使わず">"を用いた子供セレクタで定義すればいいのかも知れないが、それではブラウザがMozillaに限られてしまう。
……あ?
:before
を使う前にmedia
はscreen
であるblock
である。以上の事が当て嵌まる場合、list-style-image
を使う方が対応ブラウザが多い。更に、CSSファイルが多少複雑になるのが構わないのであればbackground
を使う手もある。
So, far away! Just far away!
遠くまで。これまでのDo As Infinityとイメージがちょっと違うけど、僕はこう言う風のが好きだ。
関西出身の阪神ファンで、六甲おろしもカバーしているらしい。
次の開発途上テスト版(非公開)でこれの修正が入るみたいっす。
いえ、非公開
じゃどうしようもないんですが……公開バージョンのリリースは何時なんでしょう?
IE5:macで、background-attachment
をscroll
にして、background-position
を50%
程度にした文書にスクロールバーが表れる時面白い効果が得られる。
Geckoブラウザで、position:fixed
をロクに扱ってくれないのは以前書いた。N6はこの記述より前にposition:absolute
としてやるとこれが有効になる。つまり、IE5:macではposition:fixed
として、N6ではposition:absolute
として扱われる。
で、IE5:macはposition:absolute
のtop
の%値を文書の高さに対する%として扱うのだが、N6はウインドウの高さに対する%として扱う。だが、CSS2仕様書には
コンテナブロックの幅('left'と'right')あるいは高さ('top'と'bottom')に対する割合で指定する。 'top'と'bottom'については、コンテナブロックの高さが明確でなく内容量に依存する場合、パーセント値をすべて'auto'として扱う。
と書かれておりつまりこの場合IE5:macの挙動もN6の挙動も不正。
CSSにしても、小手先のテクニックに変わりは無く、見た目を本気でどうでもよいと思うなら、オーサースタイルシートを書くはずが無い。
オーサースタイルシートを書くのは、そこにHTMLでは記述出来ない情報を詰め込む為だ。
そう言えば、イェーガーユニットを買いに行かなきゃ。
HTMLファイルの見出しの数が一定以上を超えた時、一部のショートカットコマンドで何故か特定の見出しに飛ぶようになる。
更にある限界を超えた時、ショートカットコマンドが全く効かなくなり、コマンドキー+任意のキーでフリーズするようになる。アプリケーションを強制終了するだけで済むのでお行儀はいいのだとは思うが、コマンドキー+S等の標準のショートカットコマンドでさえフリーズの要因になるので迂闊にコマンドキーを押せない。
実は今現在の状態がそうなんだが、こうなってくるとツールバーが便利(違)。
耐熱ガラスと書かれたガラス容器の値札シールに感熱紙(真っ黒)。
高校の英語教師が、ある日こんな話をしていた。
彼がまだ小さい頃、高速道路を建設する公共事業が立ち上がった。事業はある程度まで進み、橋桁まで完成した。だが、その時点で突然事業が打ち切られ、郷里には道路の無い橋桁だけが残った。
今も橋桁の列が残っている。世の中こんな無駄だらけなんだ、とその教師は憤慨していた。けれど、僕はその話を聞いた時に妙に懐かしい印象を受けた。
淡い夕日を受けてただ立ち続ける橋桁。そよぐ風、ゆれるすすき、遠くに聞こえる蜩。
勿論、僕の想像の産物でしかない。
blockquote
とcite
cite
要素をblockquote
要素の中に記述すると、cite
要素を書いたのは引用者ではなく引用元の著者であると言う意味にならないのか?
……等と何も知らずに書いていたら、何時の間にか某方面で話題になっている。結局、これと言った結論は出ていない様なんだけど。
赤いブレードライガー。速度が三倍等と言うネタがもっぱらだが、ブレードライガーそのものがライガー・ゼロと同じくかなりのレアゾイドなのでそう言う仮定はかなり無理。
赤くなるとセイバータイガーと重なる、と思えるが、チーム・タイガースのセイバータイガーが既に黄色なのであまり気にならず。あっさり強くなっていくビットがかえって彼らしく見える。あれだけ、「強い」事が嫌みにならない作風が好感を持てる。
見てます。ウチWOMBAT会員です。CATV利用者です。ZAQ入ってます(泣)。
問題は.exeファイルですか?……家族全員揃ってMacなウチは大丈夫か(安堵)。
伝わってない。……全然伝わってない(泣)。メールでかなり詳細なサンプルを渡したと言うに、何でこんな事になる(号泣)。
やっぱり字が小さい。
PVの……あれは……モスラの卵ッ!
食人に関する話を三つも見る羽目に陥ってしまった。
気分が悪い。気が狂いそうだ。
僕はここ最近人を描く時に必ず骨組みから描く様にしているのだが、大体肉付けが終わった時点でバランスが悪いので拡大、縮小機能を使って調整している。
あんまりいい事のような気がしない。
僕の聞き間違いで無ければ、「ゲルググ」と言うロックバンドがあるらしい。
……リーダーの服は赤いのだろうか?
学校のSolarisは古いのでMozillaをダウンロードする訳にも行かず、仕方なくN4.06[ja]を使っているんだが、初期のバージョンなのでCSS実装も他に較べて格段に悪く、下手するとロクに閲覧出来ないのでオフにしている。
大体、WAIに沿ったサイトであれば問題なく閲覧出来るし、普段見ないから素の状態を見るとそのサイトの芯だけが見えて面白い。で、ふとウチのサイトを見たんだが、
何がやりたいんだ(泣)?
2001-03-05でも触れたが、Sidebarは使い難い。そこでIE5:macのエクスプローラ バーと比較して何がいけないのか検討してみよう。
先ず、畳まれたSidebarを開くアクション。総ピクセル数にするとかなりの面積を占領しているにも関わらず、クリックして反応するのは全体の1/4ほど。さらに数ピクセルと狭いためにクリックしづらい。エクスプローラ バーではどうかと言うと、面積は大きくなるが後述のタブデザインと融合させているためにかえって使いやすくなっている。もっとも、この方法はXULをCSSでレンダリングさせている現状ではGeckoに縦書きが出来ない事も有るし、何よりSidebarの拡張性をスポイルする。だが、Sidebarの折り畳みボタンをSidebarに置かなければならない法は無い。例えば、ユーザー設定ツールバーやタスクバーにいらないメニューを載っけるよりSidebarの折り畳みボタンを置いて欲しいものだ。
さて、次に項目を選ぶためのタブデザインなのだが、どうもIE:winのエクスプローラ バーを強く意識しているらしく、にも拘らずパクったのを隠したいのかモダンテーマでは無理矢理タブの形状にしている。だが、通常のタブデザインとは法則が全く異なるためかえって分かり辛い。通常のタブデザインはメインペインの辺に対して横に貼り付くように並記されたそれぞれのタブをクリックする事でその項目を使用する。だが、Sidebarの場合はそのタブが辺に対して並記される事は無く、見た目ではただ四角いのが平行に並んでいるだけだ。(分かりにくければ、例えばWebページの画面を左右にフレームで分割し、左フレームにメニューリストを置いた状態を想像して欲しい。これが普通のタブデザイン。だが、Sidebarは左フレームに置いていたメニューリストをそのまま、上下に分割したフレームの上の部分に置いた状態なのだ。)特に、クリッカブルな項目が上と下に分割される事に最大の問題が有る。正直、拡張性等を考えるとポップアップメニューから直接項目を選ぶ方がいいのだが、どうしてもこのクリッカブルな状態を保ちたいのであれば、例えば履歴の様に最後に使った順に下から表示させれば上下に分割されない。
さて、ここからはSidebarに載っている機能では履歴しか使わないのでその話になるが、先ずドメイン毎に分けるのは余計だ。開発者の人達は独自ドメインを持っているサイトしか知らないのか?個人サイト等になると別の無料サーバーにそれぞれのコンテンツを置いている事が多いので、面倒な事この上ない。そして、「今日」のフォルダはいらない。今日閲覧した事等端から分かっている。そのままダイレクトに表示して欲しい。それから、これが一番コンピュータの理屈を感じさせる事なのだが、「24時間経ったら昨日」はやめて欲しい。普通、「昨日」と言えば日付けの事を言うのであり、夕方閲覧した項目が翌日の朝になってもまだ「今日」のフォルダに入っているのは変だ。
総合的に言えば、「IE5:macみたいにしろ」となる。勿論、他に良い方法が有るのであればそちらで構わない。だが、今現在の状態では使い難くてしょうがない。Sidebarに限らず、Mozillaはクロスプラットフォームを標榜しながらIE:winしか他のブラウザを知らないかのような実装が目立つ。例えばLynxにはlink
要素のナビゲーションをメニュー化する機能があるのに、N6には無いしMozillaも実装する気配すら無い。いらないメニューをユーザー設定ツールバーやタスクバーに置かずにこう言った機能をちゃんと実装してもらいたい。
……ひょっとして、未だに「二大ブラウザメーカー」の自負なんて感じてるんでは無かろうな。
DTDのパラメータエンティティのような変数定義が欲しいと思ってみたり。
取り敢えずトップの注意書きをいくつか移動したけど、あと名前と何書けばいいんだ?
やっぱりシークレット・アバウトボックスはいるよな。
リステリンの広告で禿げたあの人(マグワイアだっけ、ソーサーだっけ?)が関西弁を喋っている。地方に因って違うのかな?
近くのローソンの入り口なのだが、夜になると必ず猫がいる。
その入り口は扉が観音開きになる形で、僕が最初に見た時は座っている側の扉が開かれる度に寒そうに背を丸めながら隣へ移動していた。春だから風邪をひくなんて事はないのかな?と思ったりしていた。
二回目に見た時僕は声を掛けた。撫でたら口を開くのだが鳴こうとしない。暫く耳の辺りを掻いていたら、か細い音が聞こえて来た。猫は鳴いてる。だが、風邪なのか怪我なのか喉を傷めていて声が出ないのだ。
猫は僕に興味を失ったらしく、再び扉のガラスから店内を覗くようになった。僕はどうする事も出来ずそこを後にした。
今日もあのローソンの入り口には猫が座っている。
というのでGeoCitiesのバナーを調べてみたのですが、XHTMLどころかいかなるHTMLのバージョンにも適合しないものとなっています。
img
要素にalt
属性が無い(HTML 4では禁止)table
要素にheight
属性が指定されている(Mozilla, MSIEの独自拡張:HTML4/3.2には無い)table
要素直下にtd
要素を書いている(いかなるHTMLのバージョンでも不可)ていうかGeoCitiesのバナーの仕様が間違っているというのは駄目ですか。
2001-02-21と2001-02-27と2001-03-25を参照して頂きたいのですが、僕が二十数個のサンプルを調べた時にtable
へのheight
の指定とtable
直下のtd
と言う状況に会った事は無かったので、ひょっとしてジオガイドライトではなく昔のジオガイドの事かと思って調べましたがそれでもその状況には遭遇せず、GeoCities Japanのホームページとプレイタウンのホームページと電影通りのホームページとを調べましたが見つからず、ひょっとしたら僕が見逃しているだけかも知れませんが出来ればその状況の存在するリソースを教えて頂けませんか?
2001-03-25にも書きましたがimg
にalt
が無い場合と有る場合があり、有った時は問題無くW3CのValidatorを通ります。で、GeoCitiesのバナーの仕様が間違っているというの
はそれを理由にXMLパーサで処理出来ない文書をXMLだと偽ってWebに公開する事を是とするのでなければ全面的にOKです。て言うか僕もそう思います。
はWordPerfectと間違える人がいるかも知れません。WP
ところで頭文字DのDって何のイニシャルだろ?
alternate stylesheet
もしやと思いW3C Core StylesをHTMLファイルから直接参照せず一度相対パスで指定出来るウチのサイト内を指定してそこからhttpで参照する様にしてみる。……Geckoはしっかり落ちてくれた(泣)。だがこの方法であればダミーファイルを置けばGeckoでも問題なく表示確認出来る。
けれど、やっぱEZじゃ全ファイルを置き換えるのは滅茶苦茶面倒なので日曜日まではこのまま。更新する付近は変える。
確かに(笑)。あの線を唇の合わさる輪郭だと仮定すればガボラの頭部装甲……分かりにくければ先カンブリア最強のアノマロカリスのそれ……もっと一般的に言えば古くはスタートレックやシービュー号、新しくはTNGやシークエストみたいな冒険SFモノによく出てくる謎の巨大環状生物のそれ……もっと具体的に言えば魔獣戦士ルナ・ヴァルガー(小説版)のクロスサーペントナーガのそれみたいな構造になる訳で、そんなおぞましい光景は見たくもないです。
なんて、こんなモノを描いている時は露程も思わなかったのですが(笑)。
「アニメも一つのキュービズム。」「ピカソにアニメ絵の文法を持ち込むと?」なんて下らない考察の結果。こう言う事はまず元をマスターしてからやるべきと言う教訓。
しかし、これを描いて初めてケムール人がキュービズムである事を実感。
時々、GeoCitiesでこのサイトは XHTML 1.0 Strict 及び CSS Lv.2 で記述されています。(GeoGuide を除く)
と言う類いの記述を見かける。だがこんな事を書く人達はXHTMLを使う事の意味を全く理解していない。単にW3Cに追随したいだけだ。
XHTMLの存在する意味は、「既存のブラウザでもほとんど問題無く閲覧可能であり、尚且つXMLパーサを使っても処理可能である」事にある。
ジオガイドがXHTMLに適合出来ない一番の理由はarea
を閉じていない事にある。要素を閉じていない場合はXMLでは必ずエラー。ここで、XMLパーサはエラーに遭遇するとそのまま止まる場合もある、事を考慮しなければならない。つまり、XMLパーサは閉じていない要素を発見したとたんに止まり、DOMを返さず、DOMを得られないブラウザは結果的に何も表示する事が出来なくなる。
勿論、XHTMLをXMLとして処理しない既存のブラウザでは問題無く閲覧可能だ。だが、それではXHTMLである必要は全く無い。HTML4で充分だ。逆にxml:lang
等を一々並記しなければならない分全く無駄。
font-family
Lavender、Lemonchiffon、Blackboardのfont-family
を全て削除した。
上の三つのスタイルシートは文字サイズを全て1em
にしていた。これは、文字を目立たせる手段は大小以外にもいっぱいあるし、良くも悪くも閲覧者が見慣れているフォントサイズの文字を見て貰った方が負担が少ないと思ったからだった。
そして、今回font-family
を除いたのは、下手にフォントを指定して慣れない文字を追って貰うよりもいつものフォントで見てもらおうと思ったからだ。Lavender/Lemonchiffonは、イルカのシルエットとゴシック体が良く似合うと思っていた。Blackboardは、僕がPastelの見出しに明朝体を使っていた流れでそのまま見出しが明朝体、それに併せて本文がゴシック体だった。ただ、それだとWinの場合等にビットマップを使わずTrueTypeのベクターラインを無理矢理使ったりする傾向があったので、特に1em
付近のフォントは下手なものになると解読が困難になる事がある。
僕がサイズを1em
にしていたのはもう一つ理由がある。それは、文字の相対的な大きさのキーワードによる指定がCSS2では1レベルづつしか行えない事だった。larger
、smaller
がそれなんだが、これだと階層の深さ一つに対して1レベルの大きさ変更しか効かないから、h1
は3レベル大きく、h2
は2レベル大きくと言う指定が出来ない事になる。xx-large
等はブラウザに対しては相対的だが文書に対しては絶対的だ。
こんな事を言うのは、見易い文字の大きさがプラットフォームによってまちまちだからだ。1レベル大きくするのに関してもem
指定では1.2em
かも知れないし1.1em
かも知れない、1.4em
かも知れない。CSS2仕様書は1.2em
がいいとしているが、これは用意されているビットマップフォントによるから、どれとは言えないのだ。
何だかIE4:winに関して嘘ばっかり書いてる。学校のマシンだからなかなか確認出来ないんだよなぁ……
例のテストスイートで確認した所IE4:winが読まない@import
は@import "云々"
の型式のみ。他は全部問題無し。
ところで、以前書いたようにCSS1仕様書には@import
に関する総括的な記述は全く無い。サンプルソースは@import url(云々)
と書いているのと@import "云々"
と書いてあるのが混在している。これじゃ実装のしようがないって。N4が実装を見送ったのも分かる。
N6はソースを表示させると現在表示しているページのソースをそのまま参照するのではなく再び読み込んで表示するらしい。
お蔭でアクア=エリアスの継続登録情報をバックアップし損なった。
現在の世の中はマルチスキャンモニタが主流ですから、モニタのサイズ( 17 インチモニタだとか)と選択した画面解像度( 1024x768 とか)によって、今現在表示中の画面における dpi 値はころころ変わるですよ。 dpi は「インチあたりのピクセル(ドット)数」ですからして。 Mac の場合はシステムが 72dpi 運用なので、使用してるモニタの物理的画面サイズにおいて表示画面が 72dpi に最も近くなる画面解像度を適切に選択するひつようがあるとゆーか。
ぼくのは 17 インチディスプレィですが、 832x624 表示にしたときに最も 72dpi にちかくなるようです。さらに、アプリ内で 10cm の四角形を描いて、それを実際に画面に定規あててホントに 10cm になるよーにモニタの縦横幅調整ツマミで微調整するです。この状態にして初めて、画面上での大きさと実際に印刷される大きさが一致するです。逆にいうと、印刷された時の大きさを画面上で把握したいときに、画面解像度を 832x624 に下げて作業してます。
ところで、 1pt = 1/72 inch でありますから、 Mac において 72pt の文字は 1inch の大きさで表示されます。厳密に 72dpi に調整されたモニタ上では、 72 ピクセル大。 Windows では通常 96dpi 運用なので、 72pt の文字はおなじ 1inch だけども、 96dpi に調整された画面上は 96 ピクセルの大きさになる。つまり、おなじ pt 数の文字でも Win では Mac より文字が大きく見える、というカラクリはここにあるのですね。
「 Web パゲにおいて CSS などの手段でフォントサイズを絶対値固定決め打ちするのは悪だ」ちうのは CSS コミュニチや原理主義 HTML/CSS においてはジョーシキだけども、よのなかはそんなに甘くないわけで(笑)。「 Win の人が自分のモニタ表示を信じてフォントサイズを pt 数絶対値決め打ち指定したページが、 Mac では米粒になっちゃってる」というよくある現象を回避するために、 MacIE5 では標準状態で「みなし 96dpi 運用」になってるのだとおもいます。
いや、PowerBookなんですからマルチスキャン流の高度な技を求められても出来る筈も無く、なのですが何故か1024*768のLCDを800*600扱いしたり640*480扱いしたり(アンチエイリアス処理までしてくれます)と言う一体何のためだか解んない機能が付いてるんですが、これでも現実に72dpiとする事は出来ません。
で、72dpi上の72pxも96dpi上の96pxも同じ1inchですから、Win では Mac より文字が大きく見える
のは人間の目がピクセルを定規ににモニタの物体をを見ているのか、あるいはどちらかのdpi数がおかしいからではないでしょうか?例えば、ウチのPowerBookがIEの定規を信じて91dpiだとすれば、1inchで指定したものの72dpiとして処理されるので72pxとなり、結果的に(72/91)inch、約0.8inchの大きさで表示される事になります。似た様な問題がWin側にも存在するとすれば、この差は更に大きくなります。場合によっては縮まるかも知れませんが。
Win の人が自分のモニタ表示を信じてフォントサイズを pt 数絶対値決め打ち指定したページが、 Mac では米粒になっちゃってる
のとは逆に「Mac の人が自分のモニタ表示を信じてフォントサイズを px 数絶対値決め打ち指定したページが、 Win では米粒になっちゃってる」こともありますね。たしか2ちゃんねるでそんな話題がありました。
ところで、スクラップブックに保存したねこめしにっきのレイアウトと言うか素材画像の位置というか微妙に変なんですがありみかさんの所では変わりありませんか?オフラインモードでキャッシュを読む時はそんな事無いんですが。
noscript
ウチのIE5:macはスクリプトをOnにしており、それをセキュリティ・ゾーン設定で制限を掛けている訳なんだが、プロンプトでスクリプトを許可しなかった場合でもnoscript
内を無視すると言う不思議な設計になっている。どうもWeb コンテンツのスクリプトOn/Offだけで無視する/読むを決めているらしい。プロンプトで嫌って言ったんだからnoscript
くらい表示してよ。
だから秋桜って変換するなっての(笑)。
青いティガ/ガイアタイプのルナモードに、赤いダイナ/アグルタイプのコロナモード。ティガ/ダイナ/ガイアのプロテクターを見慣れているお蔭でナイスと同じ銀と色の面積がほとんど同じシンプルなライン構成や、そのわりにどんどんモールドが派手になってる頭部が若干違和感を感じるが、まぁこれは慣れの問題だろう。
テーマは「慈愛」らしい。優しさがあれば、強くもなれる
とは、平成モスラの守るために戦う
と同じベクトル。ただ、シリーズを重ねたモスラやティガ、ダイナ、ガイア、またはゴジラ×メガギラスが「破滅」や「脅威」に対抗するために「前向き」を志向していたのに対し、初めから柔らかい態度で望むコスモスがどのように展開していくのかが楽しみ。
Apple システム・プロフィールによるとウチのPowerBookの解像度は72dpi。だがIE5:macの初期設定パネルで使える定規で測った所91dpi前後だった。この是非はともかくとして、取り敢えずシステムが72dpiだと言うんだから72dpiだとしよう。
ところがIE5:macもN6も標準状態で96dpiとなっている。ここまで来るとぐちゃぐちゃだ。実質上91dpiなのにシステムは72dpiであると主張し、その上ブラウザは96dpiとして処理する。もはや考えるのも嫌だ。
で、この所為なのかどうかは分からないが、N6で解像度を72dpiとしてやるとモダンテーマで文字が潰れる程小さくなってしまう。おそらくCSS上でサイズをpt指定している為にこう言う妙な事になると思われるのだが、処理される環境が全く特定出来ないただのサイトであればともかく、処理するのはGecko、プラットフォームはMac、と有り難いまでに特定されているN6のユーザーインターフェイス部分でpt等に拠る相対指定(解像度に対する、と言う意味)を行うのは変だ。クロスプラットフォームを言いたいのであれば何でemにしなかったんだ?
なんか、女性陣て爆弾系のリノンとマリーを除けばナオミ/フーマ/ピアスとか一匹狼系が多いな。サイクスの二人もタイガースみたいに和気藹々とした雰囲気でも無いし。逆に男性陣はシリアスからギャグまで、ダンディからショタまで幅広く押さえている。昨今のアニメ業界はオタクな男性よりもオタクな女性によって支えられているのでは無いかと言う兼ねてからの僕の推論を裏付ける根拠には……ちょっと薄いかな。
またも間違い。CSS2仕様書には
URI値の形式では、「url()」という関数の括弧内にURIをを記述する。 括弧内のURIは一重あるいは二重引用符で括ってもよく、URIの前後(括弧のすぐ内側)には自由に空白類文字を挿入してよい。
と書かれている。URNまでurl(云々)
と言う型式で書く辺り妙だが、この仕様を読む限りurl(云々)
、url("云々")
、url( 云々 )
、url( "云々" )
と、どの場合もOK。まとめると、
@import
を読もうとしない。@import url("云々")
しか読めない(半角スペースの類いは未確認)。その他のブラウザは未確認。自分用にテストスイートを用意。
code
、kbd
、samp、var
を明確に使い分けながら全てを使用している人ってどのくらいいるんだろ?
僕の場合、HTMLのタグ名を書くためにcode
ばっかり使ってる。HTML4仕様書ではsamp
になってたけど、どちらかというとコンピュータが理解するためのコードと言った感があるからcode
にしてる。テキストエディタで素書きしている人にしてみればkbd
だろうし、ここら辺もうちょっと明確な使い分けのガイドラインとか無いのか?
それに、これだけいっぱいありながら、この手のブロック要素が皆無なのは何故?pre
は違うし。
おいおい、コンテクスチュアルメニューやポップアップメニューがWindowsライクになっちゃってるよ。て、何で設定パネルのOKボタンを押しただけで落ちる(泣)。
さらに、本体は消しても書類フォルダの"Mozilla"フォルダと初期設定フォルダのファイルを消し忘れてN6を起動したらSidebarにHistoryが表れて吃驚した(笑)。もっとXPIを抽象化させてJARで括られたコンポーネントをフォルダにぽんと置くだけで拡張出来る様にとか出来無いんだろうか?アンインストールしたいのにさ……
やっぱり、"ZOID"ではシマらない(何が?)。
パンツァーはまだか(笑)!とどめのバスタースラッシュ(ひょっとしてあれはシールドも展開したファイブレード・ストーム?)はまるでデスザウラーを潰したグラビティカノン発射台による無茶射出ブレードライガーとにかくなんでも全開状態。カスタマイズされたホエールキングすらもぶち抜く偉力にも拘らず何事も無かったかのように着地する辺り凄すぎ。あのホエールキングは一体高度何mを飛んでたんだ?
って、やたらに可愛い御買い物ガンスナイパー。あんな重装備の上に買い物篭(しかもゾイドサイズ)を提げてスキップしている(爆)!入っていたリンゴもゾイドに較べれば小さいが人間が食うには大きすぎ。そう言えば、あの後ラオン博士の研究所から救出してやったのか?
いやはや、/0は一部二部に無かった遊びが多くて楽しい。ゾイドの動きもどんどん良くなってるし。出来ればこのまま続けて欲しいんだが、どうやら7月からウルトラマンコスモス(誤変換:秋桜)に置き換わるようで嬉しいやら寂しいやら複雑な気分。夏休みの企画とかで朝の再放送とかやってくれないかな?
決めました。残念ながらIE5:winにはIE4:winの夢を見てもらいます。
マイナスマージンを多用するBlackboardにとってIE5:winの「横幅%はウィンドウに対する%ッ!」と言う欠陥は致命的。
そりゃ大分後になってから出たN6や未だに開発中のMozillaにはCSS2、CSS3レベルでの実装では全体的に見て負けるよバグもなんだか多いしでも背景の位置だとかborderの取り扱いだとか疑似要素の複数指定だとかその程度のCSSであればちゃんと表示してくれるんだからIE5:macはなのにJavaScriptをOffにしているからってだけでv3扱いしてはじくのはやめて貰えませんか>スタイルシート切り換えスクリプト搭載サイト様。てゆーかNetscape6から標準で付いている切り換え機能すら使えないのは何で?alternateぐらい指定したって罰は当たらないのに……
こんなナビゲーションパレットはヤダ(泣)。頼むからこんなもんを持ち込まんでくれよ、WebRing Japan。
IE5:macはページホルダにページを登録してやるとリンクだけを抜き出してくれる機能があります。
トレードオフと云ふ見出しがあるので、先刻承知の事なのでせうが、タグ一つで色んなスタイルが指定出来て、それを文章のあちこちにちりばめられると言う表現の幅が魅力的に思えるのならば、何も無理して代替スタイルシートに拘はらないでもよろしいのではないでせうか。「物理マークアップ」の「ホームページ」を基準に考へると、「論理構造と見映えの分離」なんてやつてゐられませんよ。infoseekがリニューアルする度に、泣きながらkotobaseekの記述を書換へてゐる私が言ふのですから、間違ひはありません。
無秩序で場當り的な表現には「物理マークアップ」は有效です。一方、サイト全體で一貫した表現を行ひたい場合、Cascading Style Sheetsによるスタイルの共用は有效です。そのどちらに
魅力を感ずるかは個人の資質に據るのでせうが、今の時代、無秩序の方が好まれるのでせうかねえ。「無秩序こそが自由」と云ふ勘違ひが「常識」と化してゐますからねえ。
現実に僕が代替スタイルシートに拘は
っている事を見てもらえば、僕がどちらをより好んでるかは明白だと思いますが。
もし本当に論理構造と見映えの分離
が出来るのであれば、何も野嵜さんが泣
く程の苦労をしなくてもinfoseekのリニューアルにkotobaseekを追随させる事は出来ます。ただ、現在のHTML/CSSにそのパワーが無いだけで。
確認の為に前回を見直す。やっぱり冒頭のガンスナイパーは装備がおとなしい事からリノンでは無いと判断。声も違うし(ただしエンディングテロップには流れず)。風呂に行ったリノンを追うハリーをビット、ジェミー、バラッドが三人掛かりで止めていたが、あれはむしろハリーをリノンの暴力から守るためではないか(笑)?
XHTML1.1とModularization of XHTMLの関係ってどうなってるんだ?
2001-03-22のCSSに関する記述に間違い。IE4:winが読まない@import
はurl(云々)
ではなくurl("云々")
。これはIE4:winに限らず不正。IE5:macは読んでくれるが。
lang
例えば、ウチのサイトのトップに置いてあるメニューの様に要素内を英語で書き、title
属性に日本語の説明をつけている場合は一体どう言うlang
をつければいんだろう?
ほかにも、XML
みたいな場合なんか。
HTML4Strictに沿った書き方をしていれば</p>
は殆どが必要無いと思う。例外はins
とdel
くらいか。html
とhead
とbody
はまず必要無いし。
alternate stylesheet
でhttp
から始まるURLを指定したローカルのHTMLファイルをオフライン状態で読み込ませたMacのGeckoブラウザは例外なく落ちる。
そんな事やるのは僕だけだろうけど。
講義中にアメリカ現大統領はブッシュ大統領。その前はクリントン、その前は親爺のブッシュ、さてその前は?
とかイギリスの現首相はブレア首相。その前はメイジャー。さてその前は?
とかマイクロソフトを創立したのはビル・ゲイツと誰?
とかの質問には答えられなかったのに、アップルを創立したのはスティーブ・ジョブズと誰?
と言う質問にはビル・アトキンソンかスティーブ・ウォズニアック
と勘違いしながら即答した僕はやっぱり変?
XHTML1.1が普及し出すと、このページはXHTML1.1を使ってます。対応している××か○◎で御覧下さい。
とかのメッセージがあちこちで見られるようになるんだろうか?
table
普通Mozilla系のブラウザはデフォルトでtable
の外側のborder
をoutset
、セルのborder
をinset
で表示するもんだと思っていたが、ひょっとしてM0.81はこれを逆、つまり外側をinset
、セルをoutset
で表示するようになっているのか?
未確認なんだが。
アクア=エリアスの冒険結果をmac.comに残す為にHTML3.2ベースのHTMLファイルをHTML4Strict相当のモノに書き換えるPerlスクリプトを書いた。もともとプログラムの書出したものだから解析して書き換えるのにそんなに労力は必要無い。font
やb
、i
の組み合わせに従ってli
にclass
付けしていく。
その作業をしながら思ったのだが、時々日記等で色やサイズを好き勝手に変えて表現している所があるのがなんだか羨ましかった。代換スタイルシートを指定しているとどうしてもem
やらstrong
やらclass
やらに縛られた表現しか出来なくなる。その場で思い付くままにスタイルを指定してしまうとスタイルシート間で互換性がとれないからだ。互換性を保ったままでそう言う表現をしようとすれば一つ一つにid
をつけてスタイルシート毎に適した指定をする必要がある。それはかなり面倒臭い作業だ。
スタイルシート間での互換性は無くなるが、タグ一つで色んなスタイルが指定出来て、それを文章のあちこちにちりばめられると言う表現の幅が、僕には魅力的に思える。
deegg君によるとDHTML系の人達がN6でDHTMLが動かないと文句を言っているらしい。HTML内部構造へのスクリプト言語を使ったアクセスと上書きが既にHTML仕様の範囲ではなくDOMで定義されている事を何処にも明示してないのが原因。
……DHTMLをDynamic HTMLの略ではなくDOM & HTMLの略だと言ってみたらどうだろう?
HTML4仕様書はclass
の中身をcdata-list
とか言う訳の分からない定義をしている。そして、CSS2仕様書はクラスセレクタを[class~=云々]
と同じであるとし、[云々~=云々]
は指定された属性の値がスペースで区切られた単語のリストになっており、そのリスト内に指定された値を含んでいる要素にマッチする
としている。ここに文字列を制限する記述は一切見当たらない。
……僕の記憶が確かならXHTML1.0ではclass
の中身がNMTOKENS
として定義されていたとか、XHTML1.1では何故かNMTOKEN
になっていたとか(半角スペースで区切ったリストは不正。何で?)、つまり何らかの文字の制限がある事になる。が、XMLのNMTOKENに漢字はOK。
と、言う事は、class
に漢字を書いてもイイと言う事だ。なのに、一頃XMLで漢字を使ったマークアップが流行った様にclass
を漢字で書く人がいないのは、やっぱり実際に漢字でやるのはIMの切り換え等めんどくさくてしょうがないからだと思う。
あんまり関係ないが、IE5:macはクラス並記の処理に問題がある。詳しくは調べてないが、後のクラス名が前のクラス名を上書きしてしまうとかそんなだった。HTMLの解析エンジンに問題があるのかCSSの解析エンジンに問題があるのかレンダリングエンジンに問題があるのかあるいは解析エンジンとレンダリングエンジンの間のイベント処理に問題があるのかどうかは不明。多分一番最後。
一時期、SunはJavaを標準化しようとしてISOやECMAに掛け合っていた。が、最初にISOから蹴られ、意欲を示していたECMAとも折り合いが付かず結局Javaの標準化が成る事はなかった(今現在どうかはよく知らない)。仕様の策定が一番の争点だった。
ISOもECMAも結局は一企業に過ぎないSunに仕様の決定権を委ねる事を問題にした。一企業の利益の為に標準規格が振り回される事を恐れたのだ。だが、Sunは標準化団体の仕様策定方式が技術の停滞を招くと見ていた。
個人的に、HTMLの現状を鑑みるとSunの意向が痛い程理解出来る。開発者と仕様策定者のコンセンサスが取れていれば、いやむしろ(XTとXSLTの様に)開発者が仕様策定者であればいいのだが、HTML4の様に開発者と仕様策定者との間にすれ違いばかりでは結局エンドユーザーが不利益を被る。
XMLNSの現状まで考えると、開発者同士ですらコンセンサスがとれない事もあり得る。ひょっとすると、一企業の中にあって現状で最良のモノをつくり出す事を命題とする開発者が練り上げたJavaには、これが理想なんだ!
と言えるものを最後の最後まで突き詰めて考えようとする標準化団体の方式は馴染まないのかも知れない。
そして、既存のスタイル付きテキストとの相互変換を可能とし、尚且つプラットフォームに依存しない論理的な構造
と言う初めから矛盾を抱えた要求仕様を何とか実装した、SGMLですらなかったHTMLを無理矢理SGMLに引っ張り込み、挙げ句にXMLにまで引き摺って理想の仕様を標準化しようとするからあちこちで矛盾するのではないか?
BlackboardをBBS上で調節していて気が付いたんだが、DOCTYPEでHTML4を宣言したHTMLファイルから呼び出されたCSSファイルのbox-sizing
初期値はcontent-box
で、宣言して無いHTMLファイルからの呼び出しでbox-sizing
初期値はborder-box
になるらしい。
他のDOCTYPEでは試してない。
IE5:macはlangに併せて表示フォントを変えてくれる。下の記事のWell-formed
はlang="en"
指定しており、その部分だけ僕が設定したGenevaで表示している。ところが、妙な事に同じ段落内のlang
指定無し、つまり実質的にlang="ja"
のアルファベットまでGenevaで表示してくれる。別に閲覧に支障は無いんだが、変だ。
……あー、上の段落では
までがGeneva表示で、後はOsakaになっている。何らかの兄弟要素が表れるか、或は親要素が終わるまでGeneva表示が続くらしい。……重ねて言うが、閲覧に支障はない。lang="en"
……えーと、しつこいけどこの上の段落では……重ねて言うが
の……
がGeneva表示されていて、下付きで表示されている。つまり一バイト文字のGenevaは2バイト文字の…
を知っている(!)。繰返すが、閲覧に支障はない。
僕はてっきりXHTMLのモジュール化はXMLNS等を利用したエレガントなものになるのだとばかり思っていたのだが、どうも仕様書を読む限りではDOCTYPE
を技巧的に組み合わせたものになるみたいだ。邪推だが、SGML周辺がゴネたんではないか?
XMLの最大の利点はSGMLであることだ。だが、XMLの最大の問題はSGMLであることだ。そもそも何でXMLが作られたのかと言うと、SGMLの仕様が巨大な割にインターネットにおける汎用性と言う意味ではDTDの構造に無理が来ていたからで、だからこそWell-formedとか言う訳の分からない型式が認められているのだ。HTMLのモジュール化にXMLがSGMLとは大きく違う部分である所のXMLNSを使わないんであれば、モジュール化されたHTMLがXHTMLである必要は無い。
尤も、XMLNSも包括する標準スキーマ言語であるXML Schemaが何時まで経っても定まらない状態では仕方ないと言えば仕方ないが。
普通に扱われるwww.geocities.co.jpと、何故かゲストブック2以外出て来ないeToolsで使われるtools.geocities.co.jpが一般に見られるドメイン。そしてサイトマスターがFTPに使うftp.geocities.co.jp、この三つでGeoCities Japanの全てのサービスにアクセスする事が出来る。
ところが、これはdeegg君に聞いた話なのだが、GeoCities Japanにはもう一つ謎のドメインが存在する。vvv.geocities.co.jpだ。
内容はwwwと全く同じ。只単にパイプの役割しか果たしてない様に思われるが、その意図は全く不明。ディレクトリを指定するとリダイレクトせずにパイプしてくれるので、ウチのサイトも全て未読状態で閲覧する事が出来る(笑)。
font
要素がインライン要素である必然性無い。font
はあくまで見かけを定義するもので、構造的な意味は持ち合わせていない。ins
やdel
がそうである様に、font
の内容もまた%flow;
にするべきであった。
FTPのlatestディレクトリにmac-xpi
なるディレクトリが作られている。何だこれ?
冒頭の絶叫リノンらしき人物は棊子麺頭ではなかったのでリノンではないと思うんだが、誰なんだろうか?ビットの「主(人公)役だから」は唐突。その内いきなり視聴者に語りかけて来るかも知れない。冒頭第二シーンの馬鹿笑いリノンの声がわざとらしくって川澄綾子さんは馬鹿笑いが苦手なのかと思ったりしたが、どうやらあれは馬鹿笑いの演技をしている演技だったらしい。
シュナイダーユニット、イエーガーユニットがCMに登場。パンツァーユニットは何時お目見えするんだろう?
最近のZOIDSは色んな接頭辞、接尾辞が付いていて分かりにくい。そこで少し整理。
取り敢えず、ハッキリとした呼称が判明しているのは以上である。アニメゾイド第一部、二部は、オープニングタイトルではゾイド
と言うロゴしか無かったのに、新聞の番組表には頻繁にメカ生命体
だとかメカ生体戦記
だとかの接尾辞が付けられていた。ところが、メカ生命体
だとかの呼び方は旧シリーズと区別が付き難い為に単にアニメゾイドと呼ばれる事の方が多い。アニメゾイド第二部は、第一部の世界観を引き継いではいるものの機獣新世紀ZOIDSとは全く別のストーリーとして描かれている。
先程メカ生命体
の呼称が旧シリーズとかぶると言ったのだが、今ではほとんどこの言い方もせずにバトストと呼ばれる事の方が多い。敢えて新機獣世紀ZOIDSとの区別をつける時はバトスト・旧大戦時等と呼ばれる。
そろそろこのサイトを立ち上げて一年になるらしい。そんな訳で今回はちょっとした想い出話を。
僕がサイトを始めた当初、アクセシビリティなんてモノは知らなかった。だが、HTMLで構造、CSSで見かけを記述する
と言う思想は既に持ち合わせていた。当初、インターネットを初めて一年ばかり。別にW3C信者な友人がいた訳では無かった(Netscape教徒はいたけど)。
多分、僕がHTMLに初めて触れたのは……名前忘れたけど、緑色の新書だった。鳩丸倶楽部でトンデモ本にあげられていたものだったと思う。その時、自分でHTMLファイルを手書きし、雑誌附録のNetscapeNavigator3.0に表示させた。まだインターネットに接続すらしていなかった時期だった。
本格的にHTMLを勉強し出したのは、恐くMacworld Japanに載っていた連載記事が切っ掛けだったと思う。その記事の内容に従って僕はHTMLの知識を貯えて行った。フレームの記事があればフレームを覚えた(すぐに見切りが付いたんだけど)。その記事の記者は、アクセシビリティとは言わないまでもユーザービリティを重視していて、1Kでも小さなファイルを
と書いていた。中には、
と言う怪し気な記述も混じっていたのだが。layer
を知らないブラウザの為にnolayer
を
そして、CSSの記事もあった。僕は当初「一々font
指定をせずに済む」と言うのもあったが、line-height
の指定に因っては行間がマイナスになる面白い表示も可能だと言う事に一番惹かれた。直ぐ記事の示すURLを当時既にインターネットに繋いでいたdeegg君にダウンロードしてもらった。CSSの仕様書である。
ところがそれは英語。読めない事も無いが、当時の僕には解読するのは至難の業だった。deegg君に愚痴った所、日本語版ありますよ
。そう言う事は最初に言いなさい。
と言う訳で貰った圧縮ファイルを解凍すると、何とおまけでHTML4の仕様書(邦訳)が付いていた。だが、当時未だ邦訳は完璧では無く、ところどころに穴が開いていた。しょうがないので原語版も貰い、HTMLとCSSを本格的に勉強する環境はこれで整ったのだった。当然、インターネットには繋いでいない。
話は遡るが、僕がパソコンを買ってもらったのは、「CGを描きたい」のが第一目的だった。与えられたのはLCIIIとSuperPaint。コンピューターに慣れた人ならともかく、当時の僕は人体を描く技術すら持ち合わせておらず、登録されていたパターンを組み合わせてサイケデリックな落描きを生成するのが精々だった。マウスはあくまでポインティングデバイスでありドローイングデバイスではない為、マウスを使ったペイントレイヤーの作業は僕には馴染まなかった。
そこで主に覚えたのはドローレイヤーの扱い方。(これは今でも引き摺っており、最近の絵はPainterのシェイプを多用している。)だが何の技術も無い人間がマウスとドローレイヤーを使って出来る事なんかほとんど無い。鉛筆を使った落描きのようなモノすら描けないのだ。僕の絵に対する興味は薄れていった。そんなある日、僕は一冊の本を手にした。CGネットワーカーズ自薦作品集VI。この本を立ち読みしている内にもくもくと描きたい気持ちが膨れ上がり、数日後それを購入した。目的は絵だった。だが、この本にはCG作家のためのWebページ作成講座と言う記事が載っていた。僕はHTMLではなくWebサイトに興味を持ちはじめる。
いやホントに歌うのが居たらしい。
見るの忘れた(泣)。何故か公式紹介ページは無し。勇者シリーズが云々って事は、グリッドマンに近い形なのかな?
Day after day DAMEとねこめしにっきでの話題なんですが、僕が見ていた限りで"Light style" の本文ブロックが左寄せされちゃていた
事はありませんでした。失礼ながら当該要素を調べましたが、table
要素もdisplay:table
も使われていません。バグについての記事の見出し部分に明記されていたはずですが、margin
の一括指定に問題があるのはtable
だけの話で、ただのdivでは問題ありません。ですから記述を元に戻して貰って結構です。
大抵のWISIWIGタイプのHTML生成ソフトは、新規ファイルのtitle
が「名称未設定」とか"Untitled"とか「新規ページ」とか言う名前になっていて、時々それを変更せずにそのままWebに置いてあるのを見かけるのだが、GoLive CyberStudio にようこそ
と言うタイトルバーは初めて見た。……あんまり凝ったインターフェイスって言うのは考えものだな。
@support
規則
@support [ [ "+" | "-" ] 属性名 [ : 属性値 , ]+ ; ]+
@support
規則は、後に続く中括弧内の一連の規則が対象とする、あるいはしない(1つ以上の)ユーザーエージェントを、サポートする属性名と属性値によって指定する。 これによって1枚のスタイルシートでサポート状況の違うユーザーエージェントに対する規則を記述できる。@support + position : fixed ; { position: fixed; top: 50%; } @support - box-sizing { padding: 1em; }
以上はフィクションです。こんな仕様は実在しません。
ユーザーエージェントのサポートする/しないの自由度を持たせるのであればちゃんとこう言ったエスケープシンタックスも考えて欲しい。もうブラウザのバグを追跡しながら別々のスタイルシートを書くのは嫌だ。
確か、HTMLは最初どこかのソフトが勝手に使っていた型式だったと記憶している。それを、IETF/RFCがデファクトスタンダードだと言う理由だけで標準型式として採用した事に諸悪の根源があるんじゃないか?
RFCは実装例が少なくとも二つ無いと正式採用されないと言う話を聞いた事が有る。なら、HTML2.0策定当時は少なくともHTML2.0に完全に準拠した実装系が有った事になる。そしてHTML3.2はNNとIEの実装の後を追う様に策定された。ここまではいい。
だが、その後W3CはNetscapeとMicrosoftの意向に全くそぐわない形でHTML4を策定した。NetscapeやMicrosoftがDHTML、HTML-TIME等を提示していたという事は、それを完全に実装する自信があったからに違いない。それを無視してまでW3Cが極めて抽象化された部分だけを取り出して厳しい仕様にしたのは、恐くHTML3.2までの流れがインターネットの一番の利点であるクロスプラットフォーム性を損なうと判断したからだろう。その意向は理解出来る。だが、HTML4以降のW3Cのやり方はまるでNetscapeに主導権を握られていた頃の鬱憤を晴すかの様だ。今では完全に仕様が一人歩きしている。
実装の伴わない仕様は絵に描いた餅だ。煮ても焼いても醤油垂らしてもきな粉振り掛けても不味い紙の味しかしない。名人がどんなに精魂込めて作る餅だと説明したところで食べる人にはその旨さも唇に引っ付いて困る面も認識出来ない。
W3Cの仕様の最大の問題はそれだ。CSS1等は5年かかってやっと完全準拠の実装系が一つだけ現われた。
それでも尚、W3Cの正当性を説明するのによく「二大ブラウザの開発元であるMicrosoftもNetscapeもW3Cに参加している」と言われる。だが、それでは何故IE、特にWin版はああなんだ?いくら国連でPKO派遣を決定してもアメリカが拒否権を発動すれば何の意味もない。
僕はW3Cの意向には基本的に合意する。だが、国連は国連で国連直属の部隊を持たなければならないと思う。それも強力なやつを。さて、僕みたいな小市民が大国アメリカに抗議する方法が有るとすれば?影響は極めて小さいが、アメリカ製品を買わない事だ。ならMicrosoftに抗議するには?
「Windows版IE5では御覧にならないで下さい」と書いてやろうか?だが、何も知らない訪問者に罪が有る訳ではない。……BlackboardのIE5:win向けの調整をしてやるべきかやらざるべきか……
サイトの背景に使う横長縦1pxグラデーションを作っていて気がついたのだが、面白い事にこの場合256色に減色して保存するよりフルカラーのままで保存した方がPNGでは軽くなる。あ、フィルターは自動設定。色にもよるが大体半分になる。前に四代目バナーを作った時にえらく小さくなった理由もこれで分かった。
2001-03-25にlangと引用符の関係を書いたが、自分でやってみてあれだけでは意味が無い事に気がついた。[lang=言語コード] タグ名, タグ名[lang=言語コード]
の方法で指定すると、後に書かれたセレクタに上書きされてしまう。
例えば、[lang|=en] q, q[lang|=en]
の後に[lang|=ja] q, q[lang|=ja]
を指定してそれぞれ引用符を指定していたとする。html lang="ja"
内のlang
無しのq
はちゃんと表示される。だがhtml lang="ja"
内のq lang="en"
は日本語の引用符付きで表示されてしまう。
CSS2仕様書に従って、セレクタの優先順位を計算してみよう。[lang=言語コード] タグ名
の優先順位は011、タグ名[lang=言語コード]
も011。優先順位は全く同じ。だから、q[lang|=en]
の後に[lang|=ja] q
があればいくらq lang="en"
を指定しても日本語の引用符が付けられてしまう。
この場合順番を変えれば解決しない事も無いが、根本的な解決になってない。セレクタを並記せずに別指定とし、タグ名[lang=言語コード]
を後に持ってくればいいのだが、それでは一つの言語コードに対して二つのの指定をしなければならない。現状ではこの方法しかないのだが、CSS3の属性セレクタには「属性が存在しない場合」を追加してもらいたい。
例えば、Mozillaのタスクバーの右側にある変なメニュー。あれはブックマークか、さもなくばSidebarに収納するべき機能だ。
HTML4には標準でh1
からh6
までのDOMに依存しないツリー構造を持っている。なのに、例えばDOMツリーにアクセスする様に見出しのツリーにアクセスするようなハッシュ機能を持たず、アンカーとして別に指定させなければならないのは気に喰わない。XPointerならそれも出来るのだろうが、果たして普及するのは何時になるのやら。
こう言う機能やデータの重複は嫌いだ。だから、今まで僕は日記にアンカーを付けなかった。けど、ここ最近あちこちから引用されるにつけ、僕自身不便を感じたのでアンカーを付ける事にした。
ちょっとした事情で詳しくは言えないが、試験的にある場所で段落毎のアンカーを付けてみた。ただ、これを相手が理解して活用してくれるかどうかが非常に不安。
ただ、アンカーを付けるPerlスクリプトを書いていてふと思ったのだが、ひょっとしてハイパーリンクの概念って言うのは聖書が元になってるんじゃないか?僕の知る限り、現在出版されている聖書には全て行毎に番号が振ってあり、それを引用したりする時に引用元を非常に楽に示せるし楽に捜せる。頭から順番に番号が振ってある所等、XPathであれば簡単に実装出来そうだ。ただ、この一からの番号方式と言うのはそれこそ聖書のごとくスタティックな文書にしか適用出来ない。
特に半角の場合、空白文字以外をデミリタとして認識しようとしない。現在僕がAlternationで使用しているW3Cの日付け記法は長いので、ブロックの幅が狭い場合にはみ出す。span
で括ったりコメントを差し挟んだりで強制的にラップさせられるが、スマートでない。
XML的に考えればIDで参照されたリソースに必要なモノはその要素内にすべて入っている。データはその要素内だけ所得すればよい。が、HTML的に考えるとIDで参照されたリソースに必要なのはその要素から最後までかも知れない。兄弟要素全てかも知れない。同じタグ名を持つ要素の一つ手前までの兄弟要素かも知れない。これはHTMLのツリーがDOM上ではフラットに展開される事に原因がある。
HTMLのXMLアプリケーションとしての欠陥がここにある。例えば、引用する時等にIDを指定してそこだけインライン表示させると言った方法がとれないのだ。ISOはこれを認識していたのか、ISO-HTMLでは見出し要素が表れると自動的にそのレベルに応じたdiv1
等で覆ってくれるようだ。だが如何せん普及していない。
だが問題はHTMLとDOM、XMLの関係にあるのではない。HTMLのツリーにアクセスする為の標準インターフェイスがあればよいのだ。……W3Cにもはやその気は無いようだが。
匿名ボックス、DOM的に言う所のTextノードへのセレクタによるアクセス。
例えば、h1
指定したテキストの周りに線を引きたい時等、現行のCSS2ではspan
で括るしか方法が無い。
どうやらフロートに関わらずIE5:winはwidth
の%
を完全にウインドウに対するものと看做すらしい。
変な対応するなら読み込んでくれなくていい。@ua
規則みたいなものが本気で欲しくなった。