とっぷぺーじ
ねこめしにっき
2001/10/中旬
2001/10/下旬2
ところでウェブダイバーの新エンディングのラストに出てくる、緑髪の萌え女子ロリキャラはナニモノなのでせうか。なんか囚われのお姫さまな風情がものすごく萌えちゃうのですがが。……ひょとして悪の親玉デリトロス様の正体だったり？（爆）…だってコレクターユイ（第一期）のグロッサー様も、正体はプリチィなだいだい色の iMac だったしなー。
ちうかテレ東、ウェブダイバーのページは用意してないのねん…。タカラのパゲは超合金主体だーら、萌え女子目当ての大きなお友達にはつらい（笑）
ああ、再起動後に Dock が起動しないってのは、ウチでもたま〜〜にありますよ。黙って open /System/Library/CoreServices/Dock.app してます…。そゆときは「ログイン項目」の物も起動してなかったりするしなぁ〜。なんかヘン。 なかむぅ氏が言ってた ASM の件もコレなんだなたぶん。ウチでも 2 度発生。
ML のログをまさぐって出てきた記事が参考になれば。この事例は MacOS の伝統に則って（笑）初期設定捨てを敢行。でも解決できてないみたい…。
んなことより相変わらず Classic 環境でゲロ吐きが頻発するのですがが…。 OSX 使ってるのに再起動する事が多いのはそれのせい。タスケテ〜。
UFS に OSX インストするのは、 Public Beta 時代から「アレな行為」とされてるですハイ（一子相伝の伝承（謎）。 HFS+ のが速い（らしぃ）ですナニゴトも。ものすごく必要にせまられてどーしても UFS で使わなきゃならないバヤイ以外は HFS+ が無難でせう〜。これも ML のマタギギっすが、やっぱ HFS+ のがぜんぜん新しいファイルシステムだってのもあるらしぃ…。
ウチのゴサマ〜 G3 (Rev.1) は本来 RageII+ のチップがオンボード搭載なのでつが、そんなん 旧 MacOS 時代でもハナシにならんかったので、ずっと前から RagePro の PCI カードを刺してるです。その後 OS9.2.1 に至るまで速度的不満はほとんどなくて。
しかし OSX はねー。 10.1 で動作自体は幾分速くなったとはいえ、その結果を表示する描画方面で相変わらず足ひっぱられまくってるんですわ。依然 1600 万色モードでは遅すぎて使い物にならないし、泣く泣く 32000 色で使用中。それでも画面描画はどろどろ。ところが今日、こんな記事がが…。
Accelerate Your Macintosh!に読者から寄せられている情報によれば、Mac OS X 10.1ではインストールされないATI RAGE PROドライバ（Gossamer Rev.2、iMac Rev.B〜D、Wall Street 2、Lombardなど）について、Apple Discussion Forumにインストール方法とパフォーマンスアップなどに関する情報が寄せられているそうです。
[ 力本百之世界 (2001/10/26) より ]
うむむ！でも、/System/Library/Extensions/ATIRagePro.kext は元からあるんだけどな…。なんぞが不足してて機能してなくて、それをどーにかするのかな？というわけで。
（ともに要・Apple ID ）
ほうほう。OSX 10.1 アプグレド CD からなんぞを抜き取っていれるのか…。ディスカッションを読んだところどうやら手順は以下のようなのだけど…。
※ もちろん作業は自己責任のもとでよろしく
これで合ってるのだろか。とりあえずヤった。再起動した。…。
……。…ほんのすこし速くなった気もしないでもない…でもプラセボ効果程度というか。う〜〜〜ん。ハッキシ言って劇的な変化なぞアリマセンでした（笑）。ディスカッションでも、かなり効果が出たと主張する人もいれば、まるで変化無しと言ってるひともいるし。むぅ。
っていうか、CD の private/Drivers/ppc/IONDRV.config/ の内容って、HD 上の /private/Drivers/ppc/IONDRV.config/ にあるのとまるっきり同じみたいなんだけどな。CD からコピる必要は必ずしも無いよーな。（というかアプデート掛けたときに前者の内容が後者の場所へ入ったんしょきっと）
それと、/System/Library/Extensions/ATIRagePro.kext を、 CD の System/Library/Extensions/ATIRagePro.kext で置き換える、とかいう情報もあったりした。そのココロは HD のやつはリソースが入ってないから
…って、パッケージ内容に両者の違いがまったく無いみたいだけどなぁ。なんなんだろ。玉石混交のエイゴなギロンって、読むのがすげぇタイヘンだだだだ…。
「不具合れぽーと」の続き。
そのとりあえずが最新 OS 付属の標準的 browser を撃墜する、と言う事なので修正。
[ ろばＱ日記 より ]
もうしわけないです。実は修正後もいまだ MacIE5.1 がぶっ飛びます…。もーちょっとカクジツでシンプルな再現条件を探ったところ、以下のような条件が満たされると死亡率 100% のようです。ひょとしてウチだけで起きてるのだろか…。
ねこめしにっきヘッドラインvertical-align : inherit 以外の正当な値;
任意の正当なプロパティ: inherit;…という値とプロパティの組が、任意の同一セレクタ内に記述された CSS 。（別のセレクタ内でそれぞれ別個に指定されている場合は OK ）
そのほかにいくつか質問を受けたので回答をを。
HTML 4.01 の ins や del 要素は block-level にも inline-level にも成りうる要素なんですが、MacOSX の IE 5.1 はこれでも落ちるのか
上記条件が満たされれば確実に落ちちゃうよーです。すくなくともウチの IE5.1 は。
p {text-indent:1em;} .tenseizingo p {display:inline;vertical-align:baseline;} .tenseizingo p + p:before{content:"▼";}と言う設定ではどうなるのか
天声人語スタイルの再現すね。 MacIE5.x は残念ながら :before 疑似要素や content プロパチーには未対応なので、 WinIE5.5 以上での表示とまるきり同じになりまっす。（「隣接」の文脈セレクタ "hoge + hoge" は対応してますが）
MacOSX でウィンドウシェードを実現する WindowShade X がばーじょんアプしとります〜。こないだの日記ではワリとケチョンケチョンに書いてましたが、さて。
いや〜すばらしい〜。 Cocoa アプリも「タイトルバーへ畳む」ができるよーになったス！それと、「 Dock へしまう」「タイトルバーへ畳む」「半透明シェード」それぞれの操作をどうするかの割り当ても可能に〜。これで、ぼくの望みはほぼ叶ったかもしれず〜。こりゃいーや。
残ったもんだいはといえば、旧 MacOS 等価の、 Option キーコンビネーションで「全ての窓をタイトルバーシェード」する、という操作はまだできませんね。設定の如何に関わらず OSX 標準の動作（全ての窓を Dock へ格納）になっちゃう。
しかしやっぱり、たった $7 とはいえレジストすべきかどーなのか…。近い将来、 OSX が標準でこの機能を持つ気がしてならない〜〜（笑）
（2001/10/27 追記）結局れじすとしましたー。いや〜すてきすぎる、コレ。最強。
overflow:auto/scroll/hidden (3) (2001/10/25 - 16:42)
「MacIE5 の overflow:auto/scroll/hidden (2)」の続き。
あ!これだ! html 要素に対しての overflow:hidden; 指定。コイツがイカンかったのやなー。よーし、パパこれを消しちゃうぞー。これでどうかな?ってまた見えてなければ「どうかな?」もクソもないんですが。
[ Mapleholic より ]
はい〜、やっぱりそこのようです。 http://www.mrdn.net/maple/default/style3.css が html { overflow: hidden } となってるただ今この時刻、div#main の「疑似フレーム」がスクロールできません（笑）
全構成 CSS を DL の上、手元でそこを overflow: visible へ変更したら、MacIE5 では望みどおり（推定）の「疑似フレーム」なカッチョイイぺーじになったです。でも、この変更が他のブラウザ（とくに WinIE ）でどう出るかまでは知りません〜。
MacIE5 も妙なとこで信じがたい怪現象を発揮してくれますので、ときどき油断禁物です（笑）
同じようにJavaScriptで、振り分けをしているだろう娘娘飯店しるきぃうぇぶ（違うのかな？よく分からないけど。）とりあえずUA詐称モード。変化無し。JavaScript on。画像Off。変化無し。JavaScript on。画像on。ちょこっと仕事中の画面にはふさわしくない画像が・・・。でも、CSSをほとんど解釈しない（日記とか）。
[ gobbledygook/debris+Diary (2001/10/25) より ]
完全に別物を適用する振り分け
ではなくて、 WinIE4/WinIE5/MacMozilla に追加 CSS を読ませて多少の対策・補正をかける、とゆー手法をとってます。 iCab 向けにはなにも便宜をはからない方針でつ。たくましく育っておくれ。ウチのパゲが iCab2.6 (CSS ON) でどーなってるかもしってますよー。おなじマカだもん。
あ、 NN4.x だけは専用の CSS を用意してるんで、この点だけは振り分け
でゴザイマス。
というか、iCabが、
@charset "hogehoge"; @import url( hogehoge.css );の、「hogehoge.css」を読んでくれないからか。そっか、ありみかさん所もそうだからか。なるほど。
はい、そのとーしです。
@charset
は CSS2 だし 現状 iCab は CSS1 対応までだから、これを無視して解釈を続行しなきゃイケマセン。もちろんその直後に出てくる
@import
は CSS1 なので、当然解釈してしかるべきであります。 @chaset を無くせば @import を正常に解釈するよーになるのだけど、 Mozilla とかに別の影響がでるので無くせません。
overflow:auto/scroll/hidden (2) (2001/10/25 - 15:25)
「MacIE5 の overflow:auto/scroll/hidden (1)」の続き。ちと訂正というか追加。
ul, ol への overflow: auto/scroll/hidden 指定は、項目 li がひとつ（または一行）以上あるばあいは、とりあえず内容が完全に消えるということはないみたいです。その画面ショットが以下。
MacIE5 における overflow のモンダイをまとめると、こんなトコロかと。
html, heading, p, pre, dl, blockquote, form, address の各要素に overflow: auto/scroll/hidden を指定すると、要素の内容が消えます。body, div, ul, ol への overflow は、 visible/auto/scroll/hidden/inherit すべて一応 OK です。overflow 効果で該当要素部分にスクロールバーが出るばあい、要素内容がその下に埋もれた状態になります。（ body 要素のみ正常）ul, ol は、overflow: auto かつ width/height の明示無しでも、常にスクロールバーが出ちゃいます。回避する方法はありそーな気もしますがが…overflow: scroll で常に表示されることになる縦横スクロールバーの下にも、容赦無く内容が埋もれます。スクロールすれば一応埋もれた文字は出てきます。body への overflow: scroll/hidden 効果は、その次に表示するページにもなぜか継続してるとかの怪現象も起こしたりします。…って、「疑似フレーム」をこの手法でヤってないとしたら無意味くさい記事やもしれんけど、まー覚え書きということで。
overflow:auto/scroll/hidden (1) (2001/10/25 - 10:04)
引き続き css で擬似フレーム実験。うまくいくのか。IE6 でどうなるかが今回の課題。
（略）MacIE5 でまったく表示されないらしい。悲しい。なぜかウチは Mac ユーザーの訪問者が半分くらいいるので、これを一時的とはいえ完全に無視するってのも…それでもまあいいんですけど(藁、もうちっとまともになるまでおあずけ。5分の命か…。
[ Mapleholic より ]
疑似フレームちうことは、たぶんなんぞのブロック要素のタテヨコ幅を限定して、はみだした場合のことも考えて overflow プロパティをよしなに設定したとおもうのですがが。その仮定で書きますです。
結論からいいますと、MacIE5 (含む OSX の IE5.1) の overflow 処理はちとアレゲです。 div 要素以外に auto/scroll/hidden な overflow を指定すると、要素の中身が消えます（見えなくなります）。上記の3つの値それぞれちょっとずつ消え具合がちがうですが、大筋に変化はないです。
つまり、これを回避しつつ「疑似フレーム」をデザインするならば、必要がなくてもとりあえず div 要素で囲み、それに対して overflow: auto なりを指定しなきゃダメという状態っす。すんませんが〜。…って、ぼくが謝ることでわないけど（わら
「MacIE5 の overflow:auto/scroll/hidden (2)」に続く。訂正というか追加アリ。
未実装は未実装でいいから、実装した分については人並みにマトモな解釈を行ってくだちゃいなこれだけでもいいから一票たのみます。
[ Rj's SkaaRj Page_107 より ]
でわその線でエイゴチャレンジしてみるですす。カモーン Excite 翻訳〜〜。（←情けないですアリミカさん）
ASM 2.0.1 、いいですねコレ。昨日から使いはじめたッス。
「 Classic ウィンドウモード（あるアプリをアクティブにすると、そのアプリに属するすべての窓が手前にくる）」を Finder にのみ設定〜。ほかのアプリのウィンドウ挙動は OSX の現状を維持。これが一番やりやすいな。なんか負けた気分がしますが、単なるノスタルジィで終わってないから可、としといてください。わらい。
それよりなにより、アプリごとに「 Dock を自動的に隠す」が設定できるのがイイ！これ。最強。 Classic MacOS では DragThing のプロセスドックをそーゆー挙動に設定してたので重宝重宝。
（ああちなみに OSX では「机の隅つつき」を愛用してますです。定番。 Dock にはアプリランチャの役割はさせてません。むりがありすぎ。）
ASMのClassicウィンドウ・モード、再起動したら効かなくなっちゃいました。どうしたんだ〜 ＜ ヘヘィ ベイベ〜
[ あいにまっく！ より ]
ASM の各種機能を実現してるのは、"ASM.prefPane" パッケージ内部 (ASM.prefPane/Contents/Resources/de.vercruesse.cocoa.asm/) にある常駐プロセス "ASM Controller.app" の様でして、これが背後で動いてないと、機能が効かないと思われまする。インストール時にこれが「システム環境設定→ログイン→ログイン項目」へ自動で追加されてますがが、手動で "ASM.prefPane" の位置を移動したとかの理由で起動しなかったとか。
ちうか、 OSX はココやソコに「フルパス依存性」があるのがいやすぎ。なんとかせんかいアポー。
ああ、 "ASM Controller.app" とおなじ場所に、 "ASM.menu" なるものや "Separator.menu" なるものがあったりしますねー。これがアプリメニューや仕切線の実体なのかぁ〜。考えたな〜。
MacOSX 付属の IE5.1 にて、RobaQ's WorkShop を表示しよとするとクラッシュします。手元での再現率 100% 。ちうわけで、クラッシュの原因を調査したです。発生源は simple.css の模様。
simple.css では、body, %block; , address, heading, li, table 内要素, %physical.styles; , %logical.styles; , %special; , %form.fields;
（←実体宣言の名称は ISO-HTML DTD に準拠）の全要素（セレクタ）に対して
vertical-align:baseline; text-indent:inherit;
という指定がされとりますが、これが原因みたいっす。この２つのプロパティがこの値で併存していて、 HTML 中に該当要素が出現する場合、MacIE5.1 はクラッシュする模様。
いちおう補足しときますと、
- 'vertical-align'
- Applies to:
- inline-level and 'table-cell' elements
- Inherited:
- no
vertical-align は適用先がインラインとテーブルセルであり、しかも継承しない
…ですからブロック系要素に指定しても意味ないし、
- 'text-indent'
- Applies to:
- block-level elements
- Inherited:
- yes
text-indent も適用先はブロック系
…なので、インライン系に指定しても無意味でござります。
もちろん、 CSS を解釈するブラウザはその「無意味な指定」は無視して、ナニゴトも無かったかのよーに解釈を続けなきゃなりませんので、悪いのは MacIE5.1 です。けどもしよければ善処してもらえたらシアワセっす〜。
2001/10/26 付にっき「不具合れぽーと (2)」につづく。
TinkerTool 2.0 正式版がリリスされたのでさっそく入れたなり。2.0 Preview 版からの変更は、壁紙関係の裏設定とかスクロールアローを両端両方向にするモノとかが追加されてた。
で、ぼくが MacOSX に施してる設定変更のうち、 Tinker がまだ装備してないのは以下。
最後の以外は、ちょいとシステムに深い場所の改変だったり、リソース書き換えで実現するものだったりするから困難かなぁ。
ともかく、裏設定変更ツールが乱立しまくってるのは不便だから、 TinkerTool に一本化されてほしいやね。あと可能なら例のウィンドウシェード実現化設定（？）も。目指すはやっぱり「 MacOSX の窓の手」、これだね。で、それにフリーウェア維持。これ最強。素人にもおすすめできる。まぁぼくらマカは GUI 命って事。
ちと前からマカ方面で話題だったMacではない画期的なデジタルデバイス
。…かなぁ？これって。まだ詳細わからんのだけど。
iTunes の連係もバッチリ…なんてのは既存の携帯 MP3 プレーヤでもできたとおもうし、記憶装置が FireWire HD になって大容量高速化しました、とか？数量的進歩なんてのは何もブレークスルーじゃないわけで、なんか画期的
なことが別に秘められているのだろかー。
商品単体への興味ちうより、アプルが何をしでかしたか（ or 何つまんない事やったか）がマカとしては気になるわけで、とりあえず日本語記事きぼんぬ。
当サイトへのリンク及び連絡なく無断で情報を再利用することはご遠慮下さい。
[ 新しもの好きのダウンロ〜ド より ]
この文だと、有断無断関わらずリンクは完全禁止である、と読めますな。ハイパーリンクに制限を設けるのは、有益な情報の共有を目指すインタネトの存立への重大な背信行為だから「リンク禁止」は禁止。それがいやなら、どっかの閉じた空間で運営するがよろし。その場合、そのエロサイト並みの量のバナー広告（＝それによる収益）減少と、読者からのタレコ情報量の減少（＝ページの価値低下）は免れないかと思われ。
それと、著作権法が定める範囲の正当な情報再利用（＝正当な引用）さえも「オレの承諾なければ禁止」と読めますが、こりはようするに「オレがルールブックだ」宣言であり「法治国家の法体系を軽視するぞ」宣言なわけで。もしもそうなら、ホントに不当な権利侵害に遭った時にも「法の庇護に助けを求めない」ちう「一匹オオカミ」であるべきでアリマスが、そこらへんはどうなのか。
もちろん、正当な権利は守られなければなりませぬ。しかしこーゆー超有名サイトの不見識も悪影響が多大とおもわれるので、こんな原則論をあえて今さらぶち上げ。
くだんの引用文やそのほかの併存してた条項文が、削除または修正されたもようなので、この項取り下げっす。
WindowsXPのXPを「ペケぽん」と呼ぼう
Mac OS Xも當然「ペケ」と呼ばないと。
[ 闇黒日記（平成13年10月23日） より ]
んじゃ XHTML は「ペケな HTML 」ッてトコですかね。
個人的には「窓ペケピー」「まこすばってん」で心中決まっているのですが。わらい。
[ PostPet News? (2001/10/16) 経由 ]
ちうかまずはじめに。 HEAVY METAL MUSIC のことを「ヘビメタ」言うなっっ。ナイフで腕に SLAYER の文字を切り刻んじゃうぞっっ。強制ヘッドバンギングさせて首を筋肉痛にさせるぞっっ。
ヘビーメタルのロックバンド「アンスラックス」が、英語で「炭そ菌」という意味のバンド名を変更する意志はないことを明らかにした。
そーじゃきゃスコット！（ってまだヤってるかな…（ぉぃぉぃ Spreading the Disease
かー。懐かしいなりね。ふふ。それはそーと、ANTHRAX と関係が深いコラボレーション的バンドの S.O.D のほうのがやべぇ曲がアレコレあるのだけど（ Fxxk the Mxxxxx Exxx とか（爆））…バンドの実体がなければオールオッケーか。そんなもんだ世の中。
ちうわけでただいまの BGM は S.O.D の "Live at Budokan".
ちうかいまって下旬でしたね…。このぺーじ、ずっと「10月中旬」になっていた。ヽ(´ー｀)ノ
時折、iCabのCSS実装の不完全さについて書いた記事をwebで見かけます。現状では確かにその通り不完全だし、どこがどう不完全なのか書くのはもちろん一向に構わないのですが、feedbackをせずにwebの日本語記事で「ダメぢゃん。」とか言ってるだけってのはマズいっす。MS等の巨大ベンダと違い、iCab companyははっきり言って「零細」なベンダに見えるので・・・
＃feedbackは独逸語でなく英語でOKです。簡素に書いてみましょ。
[ Rj's SkaaRj Page_107 より ]
ふむむ。「iCab Pre2.5 の CSS1 実装状況」パゲを全部エイゴに訳して送りつける、なんて不可能なので（だってエイゴなんつーのは読めても書けない聴けない喋れないモノでありまして（死）） 要点をまとめたら以下になるのかなー。
でも…
2つ目も3つ目も結局は「仕様書読んでくれ」てトコに収斂されるのか…。こんなんわざわざメルせにゃなりませんか？（笑）むーん。
気をまぎらすためにマクバッテンネタでもするかぁー。
そこで考えたんですこと。Finder上でもメニューバー上でもツールバー上でもDock上でもいいんですけど、「移動するファイル」の「わかりやすい置き場所」があって、そこへドラッグした後に、本来の移動先フォルダへドラッグするというのはどうでしょうか。
[ かふぇでっさん (2001.10.23 00:50@701) より ]
というか、伝え聞いた NeXT の Shelf とゆー機能（概念？）がまさにソレだったらしーですお。
Shelfは、FileViewerのウィンドウの上部に配置され、Drag&Dropを「ひと休み」できる場所でした。まず、送りたいファイルを一旦DragしてShelfに放り込み、次に送る先のフォルダに移動して、それからShelfに「引っ掛けて」おいたファイルを放り込む事で、1ウィンドウでもDrag&Dropによるコピーが楽にできたのです。
[ macosx-jp:06188 より ]
そういう「引っかけハンガー」方式もよいですが、 Classic Finder のフォルダナビをもちっと進化させたよーなものがほしーかも。従来のフォルダナビだと、ず〜〜っとドラッグ状態を保持しなきゃならんかったのがツラカッタわけですが、手を離してもダイジョウブな状態を作り出せるよーにして、そのときは運搬中ファイルたちがマウスカーソルにぶら下がってる風情の絵的説明をするとかー…。
なんにしても今のままじゃフベンだし、1ウィンドウオリエンテッドならばなおさら、フォルダナビなり Win 的カットペなり Shelf なり荷役マウス（仮名）なりが欲しい所存。
今日（きのう）は彼女さん含むの作家さま方と、大須練り歩きカラオケ等で遊び倒した。それはたのしかった。
帰ってきたら、ものすごくへこむ出来事が待っていた。とっても萎えた。
さう云ふCSSの使ひ方は感心しない。
[ 闇黒日記（平成13年10月20日） より ]
昨今はこのレベルまでなら平均的に到達可能なモンとなってきたですね。いまや絶滅した（例: IE3/4 ）、もしくは絶滅寸前のブラウザ（例: NN4 ）での表示まで考慮せにゃならんなどの、様々なシガラミのある商業サイトでも。ちうか昨今の IBM ほめぱげびるだーの能力なのだろけど。
モチロンこの程度では「適正な HTML/CSS である」とは到底言えないのでありますから、「適正」をめざす（あるいわ標榜する）個人運営のサイトは、これよりもっと上を目指さねばいかんス。このレベルで留まっておきながら Valid バナーを貼ってる、ちうのはそろそろアレやも、と思うしだい〜。何様なのでしょうねアリミカさんわ。
でもこのエロゲはちとキョーミをそそるなぁ〜。おっぱいが萌えるー。絵だけ欲しいなぁ…（コラコラ） ん〜、エロゲってできないカラダなんすよ。めんどくさいんす 30 分以上連続一ヶ月とかゲームやるってのはもはや。あーあ。でもまーいちおうリンクを記録しておこう、とゆーのがが本意だったりするこの日記（笑）
Mail to Alimika Satomi
Site search
About copyrights
