とっぷぺーじ
ねこめしにっき
2002/07/上旬
2002/07/下旬
恒例。
コメントがゆかいすぎ。
小学生の頃はウチにもドラえもんが押し掛けて来ないかと日々願っていましたが、おおきくなってからはもっぱら美少女が押し掛（以下略
「embed 要素を Valid にするために DTD をいぢる (3)」のつづき。外部ファイルの改造 DTD をシステム識別子とした Shift_JIS の HTML を、 W3C HTML Validation Service に掛けるとなぜかエラーが出るの件。
システム識別子の
~を%7Eとすれば Shift_JIS でも大丈夫。
[ CSSコミュニティの功罪を評価するスレ 5th Emperor の 357 版 より ]
ちなみに、システム識別子中ではオーバーライン(俗に言うチルダ)を直接記述できません。このため、../~t0040238/.. とはせず、必ず ../%7Et0040238/.. として下さい。
[ Geocities で valid な HTML を - マークの付けかた より ]
うーむ。そういう事だったのか。ばりでーたのエラー出力中、システム識別子の絶対 URI の ~ がオーバーラインに置き換わってた事で気が付くべきだったのねん。
ところで。 DTD 改造（内部書き加え式）を WinIE6 (WinMe) で表示させようとすると IE がクラッシュするのを発見。なぜ。 5.5 (Win2k) だと前にも書いたように、なぜか XML パースツリー表示にはなる問題があるにしても、クラッシュまではしないんだけどなぁ…。
WinIE6 はオカーチャンのマシン (WinMe) のヤツなのでして、頻繁自由には使えないのがツライっす。
「「前面アプリ隠し一発ボタン」が欲しい (1)」に関して。
ええとありみか氏ならすでに御存じかと思われるのですが、option＋（他のアプリのウィンドウやデスクトップを）クリックっていうのは却下だったりしますか？厳密にワンアクションと言う訳ではないですが。
[ 57th T.Green OWS -Webmaster's Room- (2002/07/19) より ]
実際のトコもっとも多用してるのがソレです。クリックの
任意のキーコンボを押してる間、半透明の iTunes リモコン窓が出るとゆーモノ。 iTunes を遠隔操作をするユーチリチはいろいろあるけれども、このタイプのは無かった気がするです。イイカモ。
ただ、キーの初期割り当てが Cmd + Space てのはイカンすぎるなり（非マカへの説明：これは日本語変換モードへの切り替えナノデス）。これだから英語圏の人わ。あともーちっと見栄えがよかったいいんだけどな。んでキーコンボしながらマウスでボタンクリックする操作なわけで、両手つかうのはやっぱり億劫。画面の角かどっかにホットスポットを設定して、それで自動表示されたらシアワセなんだけどな。
OSX で「○○（アプリ名）を隠す」の操作がうっとおしいので、メニューバーあたりに常駐する「前面アプリ隠し一発ボタン」が欲しいって、ずっと思ってるのです。
アップルメニューの隣のプルダウンメニューだと、アプリによって上からの順番が違うからうざい。てかこの仕様はハッキシ言って腐っていると思うですが、いかがお過ごしですか。 Cmd + H のキーボードショートカット操作もめんどくさい。ワンアクションのマウス操作でヤりたい。
WindowShade X を使って黄色ボタンにそれを割り当てるとゆー解決策もあるけど、それじゃウィンドウシェードまたは Dock への格納操作がマウスだけでできなくなるから、却下ー。（現在の設定は、黄色ボタンで Dock 格納、タイトルバーダブルクリックでウィンドウシェード。…なのです。）
Menu Extras で提供されるともうシアワセ。だれか作ってほすぃ。もしくはどこかにそゆものが無いかなぁ。あ、一見 Menu Extras であって実は普通のアプリという「似非 Menu Extras 」は好きくないなりん。配置が起動順依存だし、好きに動かせないから。
…ワガママ言うだけですかい。さとみちんわ。
「「前面アプリ隠し一発ボタン」が欲しい (2)」に続く。
「embed 要素を Valid にするために DTD をいぢる (2)」のつづき
DTD 外部ファイル方式のを W3C HTML Validation Service に掛けるとエラーが出るのは、どーやら HTML 自体の文字コードが Shift_JIS だとそうなる模様。 EUC-JP にしてから掛けてみたら、 No errors found!
だって。なんだかなー。
あれ? でもこれ well-formed XML としか言ってないから DTD 見てるんか謎。
[ 回顧録 より ]
EUC-JP にしてから掛けみたときに最初、 xhtml-embed-flat.dtd の文法間違いを発見してくれたので、いちおう見てるのでわないかと思うです。
「embed 要素を Valid にするために DTD をいぢる (1)」のつづき。
[ 美少女陵辱日記 より ]
ふむぅ…。
外部ファイルの方も%は%にしてくらはい。 あと、WinIE のバグは↓これで何とかなるかも知れず。 （マーク付けノート 2002/06/29 「IE に XHTML 1.1 をパージングさせる」） 試してないんで実際に動いてるかどうか分かんないですが。
[ CSSコミュニティの功罪を評価するスレ 5th Emperor の 335 番 より ]
らじゃー。
内部書き加え式の方の WinIE バグはうまいこと回避できました。でもナゼか今度は XML パースツリー表示になっちゃったです。このあたりの話、以前誰かがしてましたよねぇ確か…。
外部ファイル式の方は、依然として W3C HTML Validation Service でエラーが。 Error: cannot generate system identifier for public text "-//NyanNyanHanten//DTD XHTML with embed//JA"
て事で、勝手につけたこの公開識別子が認識されないっぽい。公開識別子を XHTML1.1 の物にすればこのエラーは消えるけど、今度は定義したハズの embed 要素が認識されないー。…なんかコンポンテキな知識が足りてないっぽい。
さとみちん作の DTD だと未定義のパラメタエンティティがうようよなのでパラメタエンティティを使わないようにしたのがふるごむ解、xhtml11-flat.dtd をいじって無理に突っ込んだのが俺の解。xhtml11.dtd の再定義してもよかったけどそれは非常に面倒なんで…。
[ 回顧録 より ]
らじゃー。
この xhtml-embed-flat.dtd は、オリジナルの xhtml11-flat.dtd をコピって、その定義の流れになじむ（と自分なりに思った）場所へ embed 要素用の各種定義を突っ込んでみた版。上と同じエラーが出ちゃった。なぜー。もちろん、にゃおりんのパッチを素直に適用した版でもやってみたけど、同じくだめでした。なぜー。
「SVG を作ってみた (2)」の続き。 object 要素で埋め込んだ SVG が WinIE で上手く表示されないの件。
んー、
xml:hrefに絶対URIで書けばobject要素でも表示されるっぽいですよ? あまりカコイイとは思えないですが。 どうもXML Baseは認識されないらしい……。
[ ぷろじぇくと、みすじら。 より ]
うげぇ…。ほんとうだー。
WinIE でのこの現象のためにいつもいつも絶対 URI で書かなきゃならんとなると、メンテで泣きそう。できればやりたく無いトコ。やっぱ DTD をいぢって何とか embed 要素を Valid にする事で当座はしのぐハメになるのかいなー。
「SVG を作ってみた (2)」の関連。
WinIE はどうやら、 W3C HTML 文法には無い謎の <embed> とかいう要素を使わないと、 SVG を上手く表示できない
ケースがある。（「SVG を作ってみた (3)」を参照の事）
くさい。たしか FLASH もそんな気が。ああモチロン、 MacIE5 や Mozilla や iCab ならそんな事は無くて、正当に <object> 要素で埋め込んでもまるで問題無いのですがー。
WinIE のキョーレツなシェアは無視できるはずもないワケで、 Strict 野郎が FLASH や SVG を HTML に埋め込みたくなった時はどうしたら。 Valid HTML とやりたい事の間にジレンマ発生の危機デスヨ。
ああそれならば、 <embed> とかいう謎要素を正当に使えるように、DTD で定義しちゃえばいいのでわ、と思った次第なのです。モジュール化 XHTML ならカンタンにできる…とみんなが言うので…そんな気がした…のですがが。
内部書き加え式のほうを WinIE5.5 で表示させてみたら、 XML エラーが出てページをまったく表示できなかった。W3C HTML Validation Service に掛けてみても Valid だって出るのに。原因とおぼしきモノは 2001/12/18 分 bubble hour の 5 項目に書かれてる事のようだけど、対処がわかりませんー。タスケテ。
外部ファイル式のほうは表示面は問題が無さげではあるけど、同じく W3C HTML Validation Service に掛けるとエラーびしばし。これまたどうすればいいのかわかりませんー。ケテスタ。
「SVG を作ってみた (1)」のつづき。
なんだかおかしいですよ?(svg.png; image/png; 40,428bytes)。 ちなみに両方ともAdobeのViewer。
[ ぷろじぇくと、みすじら。 より ]
あららら。確認のためにようやく Win2k マシンにも SVG Viewer 入れたですよ。んで WinIE5.5 で見てみたところ、やっぱりというか何というか <object> 要素で埋め込むのは NG らしいフンイキ。ウチでは、背景のふじ色市松模様しか出なかった。でも <embed> とかいう HTML 文法には無い謎の要素を使えば OK とゆー。う〜ん困ったなコリャ…。
いやー。待った待った。これでアレやコレやのエロ動画が…ゲフンゲフン！！
はじめての SVG 。手書き。
こんなんでもすげぇ苦労したなりん。いくらテキストな XML
だからエディタ
で書けるとはいっても、コリャ手書きはキツイと思った。あ、 DTI の Web 鯖も SVG の MIME タイプが "text/plain" になってるから、 .htaccess で "image/svg+xml" に変更。
以下、仕様書かんけー。
「SVG を作ってみた (2)」につづく。
mi 用の SVG モードの設定ファイルとかツールとかを作り始めたのだけど、「対応文字列入力」機能で閉じタグ自動挿入するための設定に苦戦。 mi の同機能は、単純に設定された開始文字列を探してそれに対応する文字列を挿入するだけのモノ。んだから、 XML の空要素閉じ短縮記法 "/>" で要素を閉じてる箇所があったとしても、その事を感知できない。
これが HTML/XHTML なら、 空要素になる要素は決まり切ってるし、ブラウザ実装との互換のモンダイで閉じ短縮記法のできる要素も限られてるワケで。そういったモノを「対応文字列」一覧に入れなければいいだけのハナシだったけど。
やっぱしこの手の記述補助機能は、 DTD なりのスキーマを利用して実行されるモノだとカンペキになるんだけどなぁ…。たったひとりで開発してるフリーソフトの汎用エディタに、そこまで望むのは負担が大きすぎるかな。
「SVG の Mime-Type (1)」のつづき。
MIME タイプを正しく付けるのが本義とわいえ、相手の対応待ちではハナシにならんワケで。でわ、自分の側で対処できるものなのか、どーなのか。
MacIE5 の「環境設定」項目の多くは、システムの共通設定（「インターネット設定」）を反映または変更するモノです。「ファイルヘルパー」の項もそうだと思う。その SVG 関連項目は SVG Viewer をインストしたときに自動的に設定されたワケですけども、 MacIE5 も Moz も iCab もそれに従って SVG ファイルを処理してるんだとおもわれ。
その設定情報によると、拡張子 ".svg", ".svgz" について、正式な "image/svg+xml" の他に、 "image/svg-xml", "image/vnd.adobe.svg+xml" も受け付ける模様。（ gzip 圧縮された .svgz ファイルの場合、MacIE5.2.x だけは送出 MIME タイプが "text/plain" であってもナゼか単体表示できちゃうんだけど。徹底しなさいってば（笑）
試しに MacIE5 のファイルヘルパー設定ペインにて、「拡張子 ".svg", MIME タイプ "text/plain" → プラグインで表示 "NPSVG3Carbon" (=SVG Viewer)」ってな項目を追加してみたけど、うまくいかず。
てことわ、毎度おなじみの Proxomitron に頼るしかない状況かいな。マクオンリーな人にとってはまるで参考にならないハナシをまたしても書き散らす結果に。嗚呼。
HTTP ヘッダフィルタ "Content-Type: Fix MIME types (In)" の IN 側を有効にして、 MIME Fix List.txt に以下を追加。 svgz のほうを先にもってこないと、うまいこと Fix が効かないっぽい。（なおウチの Proxomitron は Version Naoko 4.1 です。ちと古いナ…。）
ねこめしにっきヘッドラインsvgz $SET(0=image/svg+xml)
svg $SET(0=image/svg+xml)"text/plain" のまま SVG を公開してるパゲが多いということはキット、 WinIE は例によって MIME タイプなぞ見てなくてカクチョーシだけで判断してて、 WinIE ユザな人々は MIME タイプがおかしいことに気づいてない、って事なんでしょーかねぃ。ぼかー Win のブラウザには SVG のプラグインはまだ入れてないからオクソクなんですが。
Nishino さん作の SVG ファイルの殿堂。
見ての通り、 SVG ファイルを単体で表示させるようにファイル自体へのリンクが張られてるです。しかし OSX の MacIE 5.2.1, Mozilla 1.1a, iCab Pre 2.8.1 でコレを見ようとすると、MacIE5 は XML 解析モードに行ったあげくおなじみの解析エラー（メモリが足りません
とか）が出て表示できないし、 Moz や iCab は SVG のソースがそのまま表示されちゃう。これは NIshino さんトコにかぎらず、 SVG を展示してるパゲの多くでこうなっちゃう。
もち Adobe SVG Viewer プラグインはちゃんと入れてるし、 HTML 中にオブジェクトとして埋め込まれた SVG なら正常に表示するし、何故だろうと思っていた次第。
答えはカンタンだった。 MIME タイプのモンダイ。 SVG ファイルの MIME タイプが "text/plain" に設定されてるサーバだとダメ。正式な MIME タイプ "image/svg+xml" を付けて送ってくるサーバ相手なら、上記どのブラウザでも単体表示が出来マシタ。（一応書いておくと、 "image/svg-xml" でも OK 。正式じゃない MIME タイプだけども。）
特定ブラウザの設定や挙動とは無関係に、 Web サーバはファイルの送出時、その形式にふさわしい MIME タイプをつけるべきなのであります。 SVG, SVGZ (gzip 圧縮済み SVG) のバヤイは "image/svg+xml" が付くよう設定スベキなのです。サーバそのもの、あるいわユーザ側で .htaccess をよしなに書くなりして。
あ、 SVG そのものについては以下など参考に。
「SVG の Mime-Type (2)」につづく。
OSX Finder のウィンドウ位置やサイズを動かす AppleScript の書き方がワカランかったので、ここにあるヤツを参考にしてみた。
Finder 関連のアレコレを自動化する AppleScript のアプレットをツールバーに置いておくってアイデアは、 AppleScript をちろっと程度以上書ける人なら誰でも考えるですやね。実際その手の小ネタアプレトをいろんな人が出してるし。んでも OSX 10.1.5 の現状でもいまだ、そーいう小ネタで使うにはアプレットの起動が遅くてストレス感。アプリ起動の高速化も Jaguar に期待できるんでしたけ？？
MacIE5 べんりセットのよーに、「コンパイル済みスクリプト」にして Script Menu で使えばいいんだけど、メニューバーって遠いし。自分自身のフルパスを基準にアレコレできるとゆーアプレット形式ならでわの特典も消えるし。
つか、 Finder 表示オプションの「このウィンドウのみ」と「システム標準」を AppleScript で切り替える方法って、無いのかなぁ。 OS9 上で作ったフォルダがことごとく「このウィンドウのみ」に設定されてて、そりを何とかしたいのでありますがー。
Web 経由でお中元を頂くなどという、ひと夏の初経験を致しました。それはそれはご丁寧なあいさつ状と共に届いたのですが、私は大学中退の世間知らずの身の上、まともな返礼状さえ書けないアリサマです。断腸の思いでこんなものに頼ってしまいました。非礼の数々をお許し下さい。
…つか、ご丁寧なあいさつ状ってネタにご丁寧な返礼文で応えるとゆー、アリガチなリアクションをしよーかと思ったら、そもそもそゆ文章を書く知識が素で無かったというオチ。人としてダメダコリャ。
「OSX の Terminal.app と ssh-agent (1)」に関して。
ssh-agentの起動に困ったら keychainがおすすめです。動いてなかったら自動的に起動して、さらに鍵の登録もできます。
[ ふが日記 より ]
助言ありまとーです。 keychain デスカ。 MacOS9 や OSX に搭載されてる "Keychain Access" とはベツモノですよね（←アタリメだ！）。検索検索。「dW : Linux : 共通テーマ: OpenSSHキー(鍵)の管理 第2回」で言及されてるのを発見ー。 keychain の最新版を取り寄せて指示通りインスト。あ…いや、 /usr/bin じゃなくて /usr/local/bin に入れマシタ。
でもって、「keychainの導入」の章に~/.bash_profileから起動
するやり方が書かれてるけど、 Terminal を tcsh で使ってる身としてわこのまんまじゃダメなわけでして、 ~/Library/init/tcsh/login.mine にこう書いたです。
# start ssh-agent via keychain
keychain ~/.ssh/id_rsa ~/.ssh/id_dsa ~/.ssh/identity
source ~/.ssh-agent-csh-miyu > /dev/null
.ssh-agent-csh-miyu は csh 用に作られるファイルで、同時に作られる bash 用 の .ssh-agent-miyu でわなくコッチじゃないと環境変数が設定されない。ケツの "-miyu" は、 /etc/hostconfig を勝手に書き換えて HOSTNAME=miyu とかしてる関係で付くみたい。 keychain のスクリプトを見るとそんなフンイキ。ともかくこれでラクチンになれまちた。
さてさて、上記 IBM サイトの記事や keychain に関して苦言というかツッコミというか…を入れてる「〇〇とssh-agentは使いよう」なる記事も見つけてたです。うーん。ssh-agentの子プロセスとしてシェル(なりなんなり)を起動してやれば良い
のは分かるんだけど、 OSX の Teminal.app だとイロイロと特殊事情がですね。あのその。いや、ぼくがスキルナシなのがいかんのですね。そうですね。
事の発端であるトコロの「 ssh-agent にでも頼らないと scp がメンドくさくて死ねる」件については、 RBrowser で何とかなりそなのだけど、カンジンの scp が出来る版のおねだんが高すぎるる。ヽ(´ー`)ノ
OSX の Terminal.app て、ウィンドウひとつ開くごとに新規のログイン扱いだったりするわけだけど、そのワリにウィンドウを Cmd + W で閉じたときはログアウト扱いにならんというー。 logout と打つか、そのショートカット Ctrl + D で明示的にログアウト掛けないとダメ。なんだかなぁ〜。
なんのハナシかってゆーと ssh-agent ガラミ。 SSH の認証カギを、異様に長いパスフレーズで作っちゃったもんで、 najo.cc.sakura 鯖とか相手にログインとか scp とかする用事のたびに指がツルのデスヨ（笑）。そこで ssh-agent でラクしよーという。
~/Library/init/tcsh/login.mine にて ssh-agent 起動の手はずを取り、 おなじく logout.mine でプロセス終了させようと思ったら、このワナでドツボ。まぁとりあえず、ssh-agent コマンドで出てくる環境変数を一時的にファイルにため込んでおいて、そのファイルの有無チェックで ssh-agent の多重起動を回避するとか、新規窓を開いたときに環境変数を引き継がせるとかの、めくるめくダサ技を考案してみた…。もっとキレイなやりかたがありそうなー…。
/Library/StartupItems に項目作って、 ssh-agent をそこで起動しておいたとしても、 Terminal.app そのものが ssh-agent の子プロセスになってなきゃどーしょーも無いんスよね？うーんうーん。ヘタレ。
例のソフトウェアアップデート機構自体の脆弱性を修正するってトコらしー。この修正の有効性を検討するには知識が無さ過ぎるので、セキュリチコミューン系な人々の見解を読みたいなり。いちおうこの単体アプデタをゲトして、チェックサムもいちお見てからインストしたなり。
この脆弱性を突くナイスなタイミングは修正ウプデータンの公開時カモとか言われてるワケで、このアップデートをソフトウェアアップデート経由で行うのは怖くないかいな。そっちはまだ用意されてないみたいだけど。
たまにはマクネタもしとかんと。
0.3.1 だか 0.4 あたりでようやくデフォ状態でも日本語パゲを表示できるよーになって、各地で絶賛の Chimera 。 MacIE5.2.x と比べても起動所要時間に遜色ないし、なんつっても Gecko エンジンの真価が発揮されてる感じで、表示が速い速い。現状でもすでに MacOSX ネイティブの最速ブラウザだとおもう。
確かにブラウザとしての基本機能や GUI 機能がまだ不足しまくってるからメインブラウザにするのはムリ。でも「クロスプラットホムの操作性」とかいう空虚な方向性から（「 XUL 実行環境としての Mozilla 」と共に）解放されてる以上、 OSX Aqua GUI のガイドラインに従って黙々と作っていくだけだし、本家 Mozilla みたいなテイストレスのシロモノが出来上がったりはしないハズ。
マクブラウザ界は、操作性・レンダリング能力・動作速度等の総合的完成度で、 MacIE5.x が 2 年以上トップを維持しつづけてる。この状況を変える候補として、 OmniWeb も iCab も Opera5 も本家 Mozilla も問題外の域。唯一可能性があるのが Chimera 。でもその完成前にとっとと MacIE6 が出て、再びぐいっと引き離したりして。 MS は総合力の演出が上手いからねぃ。
で、テキストを選択してDnDしようと思った時点でGeckoがCarbonである事に気がついた。当然ロケーションのテキストフィールドはCocoaチックな挙動を示すので、やはりCarbonとCocoaとでインターフェイスを統一して欲しいのだが。
[ 遠吠え より ]
あらまほんとだ。つかこのドラドロ操作に限らず、 Carbon と Cocoa の操作感の違いは、 OSX そのもののレベルで統一を図って解決されるべきモンダイである…って意図ですよね。ココ。 Chimera が今後対処すべき事案、なんじゃなくて。
ホント、エンドユザがアプリ操作時に API の違いを意識せにゃいかんというか意識させられるってーのは、ものすごくアホアホな状態。それに、ドロワー他の Cocoa アプリでしか使えない GUI 機能が存在してる事も、何とかしてくだちぃ。 Jaguar で少しは整備されてること希望ー。
きょうから J りーぐ再開。…はいいけどニャゴヤ地方、地上波の中継がひとつもありませんよ？まぁこんなもんか。「祭りの後も J は閑古鳥。期待はずれに終わった W 杯効果」とか言うなよ大手マスコミ。そもそもそんな「期待」してないくせにー。期待してるならもーちっとマシなサカ中継やサカ報道してみろー。いや、 W 杯後も韓国マンセーの態度を維持して、期待どおり W 杯効果が出てる K リーグを大々的に扱っていけばどーよ？あは。
そんなことよりグラハチのゲームがホームでもアウェイでもない松本で開催ってのも気分が盛り下がるなぁー…。なんでこーゆーマッチメイクなんでしょ。
ちと取りあげが遅いんだけど、まぁ気にせずに。
んー宇宙世紀のライン上にある正統ガンダムじゃないのかー。つか、ストライクガンダムのヤワそうな質感や正面シルエットといい、ストーリーラインといい、なにやらガンダム X に似た雰囲気が漂ってますがー。…ティファはどこだ病弱萌え系少女はー。（´Д｀;）ハァハァ
いやいや、ガンダムには権謀術数渦巻く（しかし安い）展開とそれを織りなすシブイオヤジたちしかもう求めてません。わらい。老獪陰謀オヤジとか情熱熱血オヤジとか、もう大好き。やっぱ 0083 がサイコーだなや。 SEED にも萌えるオヤジは居るかなぁ。
にんげんじょ氏、「猫の恩返し」について語る。
制服の女子高生が異世界に紛れ込むというパターンはエスカフローネ以来の王道か (嘘)。
[ 人間城の主な日々 (2002/07/12) より ]
「エスカフローネ」でわなく「ふしぎ遊戯」を挙げたいトコロ。「エスカ」を見たときの第一印象が「古代中国の代わりに中世ヨロパで、人馬や魔術の代わりにロボが暴れるふしぎ遊戯かいなコリャ？」だったぼくとしましてわ。いや、この王道パタンの起源は古くは「レダ」か？いやいや、あれは制服のまま活動してなかったな。…あ。てことわまさか夢幻戦士ヴァリス？（笑）
まぁエスカ・ふしぎ遊戯双方とも美男子萌え要素度が強くてヲタ女子が喜ぶ系統ではあったのだけど、最後まで観た（読んだ）のはふしぎ遊戯のほうで、エスカは途中でザセツした。そこっ、前者には男子向けのえち描写もあるからだろとかいうなー！
なんつーか、それがムチャっぽい企画であったとしても、それを実際に行動に移して実現してしまおうとする情熱と実行力に対して素直にスゲェと感じる。
そゆモノって往々にして、事前の思慮や見通しが甘かったりムチャがたたったりする結果になる事もよくアリガチ。しかし、クーラーの効いた涼しい部屋で椅子にすわって安全な場所から、結果をモトに外野がゴタクを並べるなんてのは、誰にでもできること。意見そのものが至極真っ当で正論だったとしても、その「口先の弁舌」自体をスゲェと思ったりはしない。コトバは行動でわない。
つまりさとみちんも、口先のゴタクはいいから、手を動かして汗を描いて苦しんで絵を描け絵を、ってことですね。…嗚呼。
「
しかし、一番重要な要素が欠けているのであった。
…ダメヲタまるだしですよアリミカサン。でも、変身前と後で甲乙つけがたいほど両方ともルックスが萌えかわういのは、ポイント高いなー。ぴえろ系の変身後は萌えかわいくなかったし。ぜんぶがぜんぶ。わらい。
変身後の自分なら手に入れられる満足感・達成感・幸福感と、しかし本来の自分がそれらを自力では何も手にしてない事に由来するアイデンチチ面への葛藤。この系統の魔法少女モノの主題はたいがいこのあたり。この葛藤を受け入れて克服することが物語的結論となってる。しかしそこに至るための主人公の精神的成長は、魔法のチカラの使用期限がほぼ決まっている事から、半ば強制的にしかも突然促される事が多かったとゆー。結果的に結論へ至るトコの描写が淡泊またはヤッツケ気味。マミもペルシャもユーミもララもそーだった。
マジカルエミの場合は、チカラの使用期限が設定されてはいなかった。んだから自力で葛藤の存在を見つけるしかなかった。そしてそれを乗り越えるためにアイデンチチを掴み、自発的にチカラを返却するまでが丹念に描かれた。マジカルエミがぴえろ魔法少女の完成形とされる所以。
ぴえろ系じゃないけど、初代ミンキーモモは葛藤する暇もなく、チカラどころかイノチまで突然なくしてた。二代目海モモはそーじゃなくて、「魔法（他力本願）で叶えられる夢なんて夢じゃない」と思い至る段階と、魔法のチカラがだんだん失われていく切迫状況が同時に描かれてた。ゆえに海モモのほうが深くて好き。
「満月をさがして」も時間的期限があらかじめ決まっている系統なのだけど、さてどうなるのでしょーかー。
<pre><code>...</code></pre> でいいんじゃないかと思ってる次第。
ソースコードとかって、改行やスペースの数などの整形状態が文法上・視認上重要だったりする事も多いですやね。勝手に改行されたりしたら困るとか。そんなテキストのある程度ひとまとまりな断片を文中にベタ貼りしたらば、そこはもう「整形済みテキストが貼られている場所」としか言い様が無いし。んで、その事を伝達する HTML の語彙は現状 <pre> しか無いワケだし。
つまりぼくわ「整形済みブロックなのだ」って事に重きを置いてるですよ。そこの最終表示形態が white-space:pre である事も望むけど、閲覧者がそれを望まない表示設定をしてるならそれもよし。ぼくは「整形済みだよ」って事は確かに伝えたんだから、後の事はシラン。
「ブロック要素の中身全部を更にインライン要素で囲む」というのが冗長
だという意見が出てますね。たしかにマクアプ結果をブロックレベルからインライン方向へのトップダウンで見たらそーかもしれない。んでもぼくがこのマクアプをするときの思考方向は逆。 <code> でとりあえずマクアプした「断片」が、その性質や量や前後ブロックの流れから、たまたまそれ単体で整形済みブロックを形成する事を求められた…ってケース。なので、そんなに冗長だとは感じてません。
<ol> でマクアプする案も出てる。これ、リスト項目内のソース断片がそれぞれアチコチから寄せ集めたモノでありつつ、その順序も重要であるんだったらイイカンジだなーと。んでもしかし、連続したソースコードの一行一行をリスト項目に仕立てるのは、ちとやりすぎの感が。これがやりすぎじゃないとしたら、連続した複数段落 <p> で構成された普通の文章までも、それぞれ <ol> のリスト項目にしないと扱いが平等じゃない気が。しかしそんなんはバカバカしい話のワケで。
ある部分が何らかの理由でひとまとまりのものとして扱われるべきと判断した場合、僕はまず、その部分を匿名ブロックと見なす。そして、その部分がリスト的な性質を持っていると思えば、リストにする。段落的な性質だと思えば、段落にする。もし HTML で定義されたブロック要素の中に適当なものがなければ、 div でマーク付けし、 class か id で補足する。
[ Latest topics より ]
ぼくもこの流れを採用しとります。その結果、 <div> のなかにインラインしか無い場合もあり得るですよ。そゆのはヘンだ、とする流派がありますが、ぼくはその門徒でわありません。 マクアプ文書をコンピタ処理する上では、ともかく class なり id なりで目印が付けられてれば、なんとでも処理できるだろし。ただ、ソースコードのブロック片には <pre> を使うと決めてるボクとしては、 <div><code>...</code></div> にはしませぬ。
Mail to Alimika Satomi
Site search
About copyrights
