とっぷぺーじ
ねこめしにっき
2002/02/中旬
2002/03/上旬
何枚にもわたってスタイルシートを分離する利点って何だろう？ネスケ4.x対策ならそんなに分離する必要性は無いですよね。
逆に、一つ（若しくは二つ）のスタイルシートでは、大きくなってしまう方が弊害が大きいのだろうか？
[ gobbledygook/debris+Diary (2002/02/28) より ]
えらい人
ではありませんが。（紋切型応答）
すみけんたろう氏の著書「スタイルシート Web デザイン」 (6.5.2 「特定の文書への対応」と「一般性確保」のジレンマ (p.186)) にもありますが、「ある特定の文書に最適のスタイルシート」を追い求めることと「一般性のあるシート」を追い求めることは、基本的には両立できません。
そこで、「一般性のある指定」から「特殊ニッチ部分への指定」へ段階的に小分けしてくと、シートの再利用性は高まります。
「一般性シート」をどう捉えるかは、サイト制作者の嗜好によってちがうと思います。ウチのサイトでは、サイト全体に対して共通に使えるという程度のモノを用意してるです。それを、各コーナー別の「特殊シート」が取り込む形態。制作者によっては、世の中のどんな Strict HTML にかぶせても OK なもの、というもっと強い「一般性指定」をさらに分離しておく人も多いです。
モジュールモジュール〜♪てな感じで、プロパティ種別ごと・用途傾向ごとに小分けする人もいます。モジュールごとに注意深く分割されてるのは、再利用時の扱いやすさでポイント高いです。
しかし、多くのブラウザは、必要とされる外部 CSS を全部読み込まないことには、ページ内容を何も表示できませぬ。そして、 HTTP 的には、合計のファイルサイズが同じなら、細かいファイルに分かれてるほどレスポンス的に不利。なじぇなら、たくさんのコネクションをイチイチ張らなきゃいかん分のロスがあるから。
ちっともデータが来ないという「ババ」を引く確率が純粋に増えますから。
いくら外部 CSS はキャッシュされるとゆーても、初訪問やシサシブシのサイトだとキャッシュがあるわけもなく。（数が）大量の外部 CSS 読み込みにかかる時間ロスが、 Strict HTML によるソース減量効果を帳消しにしてマイナスに大きくめり込む場合もアリ。まさに巨大なページ全体を巨大なテーブルで囲って、 10 秒くらい何も表示されないで待ちぼーけ、ってゆーあの腹立たしさと同様の状態。そゆ CSS サイトは実はけっこう多い…。これは CSS 推進者立場的にマズイなーとか思ったり。
んだからまぁー CSS の小分けってのも、ナニゴトも、過ぎたるは及ばざるが如し、ってところでわないのでしょーか。こんな言葉を遺した昔の人って偉大だなぁ。
2002/03/01 付にっき「外部 CSS の小分け (2) 」につづく
こうしてみると、いかにテレビ版がヘボかったかよく分かる。DVD版に向けての作業には、さぞかし大変なものがあったのだろう。静止画で見ると、アラがよく見えてくるのだなぁ。
[ 湾岸日記 より ]
いやーでも、 TV 版のほうが絵的に好みに感じるものが多い気がするなり。たしかにヘボいものはヘボいのだけど。絵柄的好みって、絵の上手い下手にはそれほど左右されない、と常日頃。
つか、ヲタ絵描く人だと（いや、そうでなくても）自明だけど、やっぱし自分の絵柄に近い絵柄を好む傾向がハッキリあるんスよね。…てことわ、ぼくの絵も世間的には「ヘボ系」所属ってことか〜。わら。ヘボ系というか、アカ抜けないヤボったいのが好きというか。そんな次第なのです。
つか、修正後 DVD 版の絵はどっちかというと「カッチリ系」かつ「濃ゆい系」で、そゆのはいまいち好みじゃないと言いたいだけだったりしますが、何か？
つか、いーかげん絵の一枚でも描いて UP しなさいアリミカサン。
ミニさとみかんをページホルダに入れて違和感なく使うためのユーザスタイル定義。Mac IE5専用スタイル。IE5のアプリケーションフォルダの中のヘルプ/Images内のアイコンを使えばもっと忠実に再現できるハズなんですが、何故か画像が出ませんでした。だから画像は使いませんでした。
[ TEXT_015:[CSS]違和柑無小里蜜柑 より ]
たぶん、 OSX の Carbon IE 5.1.3 なら file:///Applications/Internet%20Explorer.app/Contents/Resources/English.lproj/Help/Images/triangle.gif にあるこの三角マークを使いたかったのだろーなと予測。マカの以心伝心味心。手元でもためしてみたのだけど、どーも MacIE5 は、画像ファイル呼び出し系のプロパティをユーザー CSS に書いても反映しないくさい。ちぇ。
関係ないですけど、picoBBSの書き込みのボタンってば、「取り消し」が右側にあるので、「書き込み」のつもりで押しちまって、内容がパーになることがあるのです。マカは注意。
[ カナかな団の躁鬱 より ]
「取り消し」ボタンなんて、世の中のたいがいの掲示板フォームでは不要とおもわれ。消しちゃえばいーのでわ。ウチの掲示板にはそんな無駄ボタンはありません。まぁ、どっかの某バグヂラみたいな必要以上にゴチャゴチャしたフォームだと、リセットボタンは必要かもしれないがー。
実質上すべてのリセットボタンを取り除くことで、ウェブはずいぶんと快適な場所になるだろう。このボタンがユーザの役に立ったためしはほとんどない。そればかりか、彼らを傷つけることもまれではない。
[ Alertbox: リセットとキャンセルボタン より ]
ところで、けいじばんや検索ましーんの submit ボタンを（ CSS 適用環境では）右下に配置してるのは、やっぱマカゆえに。わらい。左上から右下へ進む言語下で、操作実行ボタンはいつも右下にある、ってのは目立つわけだし。ボタンテキストを読む必要もないし。よくできてる（できてた）よマクの UI わ。 JTerminal の各種ダイアログは、 Mac アプリとしてのこの基本をまるで守ってないもんだから、Interface Builder でボタン配置を修正して、 Return のキー割り当てを追加してからビルドしてたり。
北村さんのサイト「曉に死す」、 70000 ヒット記念企画「篆書バナー作ります3」に応募してみた。
もち「娘娘飯店」でお願いしたです。漢字四文字だと企画にベリィフィットな気分がしまくったので〜。
続報は 2002/03/05 付にっき「篆書バナー (2) 」にて。
MacOSX ではもう金輪際使えないと思ってた、ウチの SCSI 接続のスキャナ GT-5500 。ところが今日この VueScan ちう物の存在を知ったです。試してみたらばっちりスキャンできるしー。うおおおおお。…しかしシェアウェア。金払うまではスキャンした画像に格子模様が入るみたい。 $40 也かぁ…。きつい。
あ、 SCSI インタフェイスはゴサマー G3 標準装備のオンボード SCSI す。
週末は三重県方面に行っておりました。やっぱし朝のラッシュにモロぶち当たる時間帯の移動は、よした方がよかった。フツーだと 2 時間半の道のり（約 100km ）に 4 時間かかるんだもんあぁぁぁ。つか、年度末の予算消化工事がムカツクんじゃボケ。土建国家日本バンザイだよまったく。
どうでもいいけど、 Mac は "Mac" なのであって、 "MAC" だとか "ＭＡＣ" だとか "mac" でわないのですよ。非マカがそのコダワリをつゆ知らずなのは仕方ないけど、マカ自身が Mac の事をＭＡＣとか書いてるのを見ると、もうね。あぁ〜マカマカ。
こっちは最新の話だけを定期的に入れ換えて流すタイプ。ほとんど見逃しちゃってる…。先日 21 日まで過去分の再放送をしてたみたいだけど、それさえ見逃した。つか、各話オンデマンド放送にしてくれない理由は何。営業戦略的モンがからんでるなら仕方ないけど。そーじゃないくだらない理由、たとえばオンデマンド配信がネットの利点ちうのを理解しとらんとか、旧来の TV 放送の様式に思考を縛られてるとか、だったらげんなりんぐ。
いやぁ Windows Media Player の OSX ネイチブ版があってよかったね、って感じ。のどかな山あいのアップル牧場から一歩でたらそこは、 Windows Media か Real Media ばかりのストリーミング世界ゆえ。 Classic 環境上で見る Real Media のストリーミングは、辛すぎるものがあるゆえ。実写エロ動画系サイトが好きな御仁的には、この状況はつらいですなぁ。心中お察ししますっって誰に言ってるんだ（わら）。つか、 WMP はなぜか OSX ネイチブ版のがパホーマンスも品質もいいという。
で、ヒロイン娘ちゃんのアイちゃん。視線をひきつける深みをその瞳に宿す者。いいなぁこゆ絵。おめめじうやう。
ネタバレ気味なのでアレなのだけど、かまわず書く。ラスト、ありゃ天国の花畑ですか（笑）なんか薄暗いけど。つか、ふたりはいいよ。愛の逃避行完了で。特殊能力のおかげでふたりだけは安全だし。でも、人類の危機はなーんも解決しとらんでわー。そゆ舞台背景方面の問題解決をほっぽり出したまま幕引きしちゃう系は、どーもスッキリできんのです。舞台背景が主人公たちの劇的欲求を生むのなら、主人公たちが至った結論とその過程の行為は、舞台背景にも結論を与えるものであって欲すぃー。
CSS3 草案 box-sizing プロパティ
（大幅に略）
もじら組のスタッフの方から、注意書きが不順分とのメールを頂きました。
MozillaはあくまでWeb標準、つまりW3Cの勧告に準拠したブラウザとして開発が進められています。しかし、指摘される通り-moz-*に代表される独自拡張が存在します。これはIEのような先行実装や勝手な独自拡張ではなく、CSS3の実験目的、もしくはUIを構成しているXULのための拡張です。これらは当然、Webページで使用されるべきものではありません。
- Mozillaの独自拡張は一般のWebサイト作者のためのものではない。
- また、これらをWebサイトで使うべきではない。
- これらの機能は予告無く削除、仕様変更が発生する。
[ CSS Reference 視覚整形 より ]
XUL のためのものなら、「通常のページ」では効かないように作るだけの話でわないのか、と。「通常のページ」にも適用できちゃう事実をもってしてみれば、勝手な独自拡張
以外の何物でも無いのでわん。W3Cの勧告に準拠したブラウザ
であるのなら、 -moz- 系セレクタ・プロパティは XUL の外で使えてしまってはいかんとおもう。CSS3 の実験であるとしてもしかり。
たしかに Mozilla の -moz-box-sizing と MacIE5 の先行実装 box-sizing はチョー便利です。 WinIE が width 計算において問題児でありつづけるかぎり、これなくしてマトモな CSS デザインはできません。ぼくも使いまくりです。
もち、勝手な独自拡張
モノである以上（断言/笑）、予告無く削除、仕様変更が発生する
かもしれないとゆーリスクは、折り込み済みで使ってますけど。当然 CSS Validator も通らないス。けども、「ピュアなる潔癖主義」立場をほんのわずか取り崩すだけで絶大な実利が得られるなら、そっちの方を取るとゆー「メンタル Transitional 人間」ですからぼくわ〜。
OSX システム環境設定にて日本語を優先言語にしてる環境下で、 Carbon IE5.1 の JavaScript エラーダイアログがハゲしく文字化けして、エラーの内容表示がイミフメイなの、なんとかならんのかいな。
英語を優先言語にセットしてから IE 起動したらば、ちゃんと読めるダイアログが出るのにはマイッタ。ダイアログのフォントを欧文系で決めうちしてるだろっっ！ばかああああ。
それはそーと、そふぃあさんの agenda ページを表示すると、ウチの MacIE5.1.3 (for OSX / Carbon) は JavaScript エラーのダイアログが出るです。んで、構わず他のサイトの巡回を続けてると、だいたい 10 分後までにクラッシュしちゃうです…。
原因をさぐるため、agenda の HTML とそこへ取り込まれてる外部 JavaScript とをローカルに取り寄せて開いてみると、症状はもっと深刻。ジャバスクエラーが出たあとウィンドウを閉じてみるだけで 100% 落ちる。これは前に日記ネタにした「MacIE5.1 Carbon : AppleScript からの DOM いぢりでクラッシュ」と同じでわ、と。
var nTextInput = d.createElement('INPUT'); with(nTextInput){ size='20'; type='text'; name='q'; value=''; } var nHiddenInput = d.createElement('INPUT'); nHiddenInput.type = 'hidden'; nHiddenInput.name = 'sitesearch'; nHiddenInput.value = 'members.jcom.home.ne.jp'; var nHiddenInput2 = d.createElement('INPUT'); nHiddenInput2.type = 'hidden'; nHiddenInput2.name = 'as_epq'; nHiddenInput2.value = idWords;
[ Jintrick.js (line 191-202) より ]
どうやら、input 要素を createElement して type プロパティを与えようとすると（上記引用の強調部分）、
Object doesn't support this property or method
と言い出してる始末。なんじゃそりゃって気分びしばし。で、ここでエラーが発生するもんだから、生成された input 要素はどこにも使われず宙をさまよい、 Carbon IE5 クラッシュの引き金となってる模様…。
うーむ。ぼくには innerHTML でシコシコ…っていうダサい方法しか回避策が思い付きません先生！鍛えてプリーズ。
ちなみに、OS9 版の IE5 は「さまよい生成要素でクラッシュ」への耐性はそこそこあると思いますす。 OSX 版みたいにヨワくない。
2002/02/21 付にっき「フレーム強制排除 (1)」について。
同人界といえば無断リンク禁止発祥の地（偏見?）。フレーム内に表示するなど以ての外という風潮があるのではないでしょうか。
[ agenda より ]
その偏見はアタリです。もう断言しちゃう（笑） しかし、フレーム内に表示するなど以ての外という風潮
の方は、それほどは感じない事実が…。フレームを破棄してリンク先を表示させる方法（やそうすべき理由）がワカラン人なんてゴロゴロしてるから、他人にも強く言わないとか。マジ偏見。まぁ、ウザフレームの話は別に同人系サイトに限った話じゃなく、世間に均一に蔓延してるモノですがが。
外部へのリンク時にフレーム破棄しないブザマなパゲ
も多いけど、なぜか新規窓でリンク先を開いちゃうっていうブザマケースもやたら多いし。 target 属性を使いこなせないなら、フレームなんて使うのやめてしまえ。自分のページから出ていって欲しくないから外部リンクは新規窓に開く、なんて人は Web から消えてください。自分がヤられてウザイと思う事は人にもやらない、これ鉄則。
.
説得
かぁ…。「情報共有原理主義」「ユザビリチ原理主義」系のステロタイプな説得なんて、ただただ自分のページを自己中に彩りたいだけの人には何の意味も持たないんだおなぁ。うまい演説をブチ挙げられる人が降臨しないかな。
（フレーム強制排除スクリプトには）弊害もあります。例えばLycosのPreviewを使って複数のウェブページをインラインフレーム内に読み込んでいて、あるウェブページによって突然フレームを解除された場合、それまでのダウンロードが全てパーになるのです。
ですから、もし、フレーム内に表示させられるのを防ぐスクリプトを書くのであれば、例えばこんな風にするのがより良いのではないかと。
location.hrefプロパティの書き換えではなく、window.open()メソッドを使う。- フレーム内に表示させられたものには、
body{ display : none }等のCSSルールを追加（意地悪な例）。
う〜む。ごく僅かに存在する、そういう有意義なフレームの使用法をやってるトコの利用者にメーワクかかるのは、ちとアレっすね…。
ってのに心惹かれるモノを感じまくってみましたし（笑）そのうち試すかも〜。…ためさないかも〜…（ぉbody{ displey : none }なんて、滅多に使う機会ありませんよ
あと、すっごく不思議なのが、<ruby>要素って勸告されたのがxhtml1.1からと聞いていますが、何故にIE5.0でも表示できるのか。 IE5.0が最初に出たのって大体９８〜９９年頃何じゃないかと思ったりするんですが、その頃に已に<ruby>の構想は在ったんでしょうか。 何故に予想も出來無い要素を適応出来るんだろう。
[ おかし日記 (2002/02/21) より ]
ruby 要素はモトモト IE の独自拡張だったかと。つか、標準仕様としての提案をしつつ、正式採用なんて待たず見切り発車でサッサと IE に搭載してた…ってトコだっだけ。
Microsoft はなんだかんだ、独自拡張モノでもとりあえず標準仕様案して提案するトコがえらいというか、計算高いというか、エゴまるだしというか。んで結果的に採用されちゃう事もしばしばあったりして。
フレーム内表示を解除するスクリプトを仕込んでいるサイトが存在しますので。
[ agenda より ]
ウチのことですか先生！（笑）
同人系サイトってやたらフレーム好きだし、それはいいとして外部へのリンク時にフレーム破棄しないブザマなパゲが多いし、そゆとこからリンクされる事多いし。
「フレーム強制排除 (2)」に続く。
ねこめしにっきヘッドライン
Mail to Alimika Satomi
Site search
About copyrights