私は、妥協するのであればobjectを使うのではなく、原文の変更を選びそう。
私も野嵜さんのはじめにテキストありき
が基本なのですが、ソースコードとして違和感を覚えるような書き方はしたくない。なんというかArrayListの中にArrayListをぶち込んでいるような感覚なんですよね。そりゃ仕様上では問題の無い行為DTD上では問題の無い行為だし、やらざるを得ない場合もあるだろうし、動きもするんだけど、出来ればそんなことはやりたくない。プログラムの仕様（HTMLで言えば文章）を変えようよ。という考え。
というわけで、解決策としてはyamさんのやり方が一番しっくり来る。真名垣さんが言われていたその改行をどうするかが難しい問題だったからだ。それを無視しても、何も解決しない。
については、言いたいことは分かるけど、objectを用いることと、原文がHTMLに適合しないから原文を変えるということは、同レベルの妥協だと思う。（原文を変更することが可能だということであれば。）
と書くと、私にも読解力に問題がある
と書かれそうですが、私は、それくらいの案で解決する
ような、至極単純明快な問題
に「問題自体を変更する」という解決策も「ナシ」とは言えないと思う。文の形態は変わってしまっているかもしれないが、「同じ意味をもつHTML文書が最終的に出来上がるのであれば良い」となる解決も「アリ」ではないのだろうか?と思うわけです。
原文の変更が不可能な状況であれば、objectを用いた真名垣さんの解決方法を選ぶと思います。
上の関連の話題だけど、ちょっと違う話。徳保さんの文章を引用していますが、徳保さん宛の文章というわけではありません。
まあ、現行の Firefox などの代替テキスト表現が素晴らしいかどうかは別問題だと思いますけど。強いて Firefox を擁護すれば、インライン要素を CSS で display:block; することは否定されていないのだし、といったところなんですかね。
確かに CSS で display:block; することは否定されていない
のですが、HTML4.01の勧告には以下のようなことが書いてあります。
Style sheets provide the means to specify the rendering of arbitrary elements, including whether an element is rendered as block or inline. In some cases, such as an inline style for list elements, this may be appropriate, but generally speaking, authors are discouraged from overriding the conventional interpretation of HTML elements in this way.
The alteration of the traditional presentation idioms for block level and inline elements also has an impact on the bidirectional text algorithm. See the section on the effect of style sheets on bidirectionality for more information.
In general, using style sheets to change an element's visual rendering from block-level to inline or vice-versa is straightforward. However, because the bidirectional algorithm relies on the inline/block-level distinction, special care must be taken during the transformation.
When an inline element that does not have a dir attribute is transformed to the style of a block-level element by a style sheet, it inherits the dir attribute from its closest parent block element to define the base direction of the block.
When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element.
When the dir attribute is set for a block-level element, it remains in effect for the duration of the element and any nested block-level elements. Setting the dir attribute on a nested element overrides the inherited value.
Inline elements, on the other hand, do not inherit the dir attribute. This means that an inline element without a dir attribute does not open an additional level of embedding with respect to the bidirectional algorithm. (Here, an element is considered to be block-level or inline based on its default presentation. Note that the INS and DEL elements can be block-level or inline depending on their context.)
慣習的な観点から変えないで欲しいという話と、双方向アルゴリズム的には注意してdisplayの変更をして欲しいという話。
ここからが本題ですが、XHTMLの勧告にも同様のことが書いてあるのかと思って見てみたのですが、私が見る限り1.0、1.1、Basicには見当たりませんでした。何か理由があるのでしょうか?どなたか教えていただけるとありがたいです。（XHTML2.0のWorking Draftには書いてあったんですよ。W3Cはどういう考えなんでしょう?）
さすが期待を裏切らない人だなと思った。これだから小坂先生のファンはやめられない。
そういえば、ウォルナッツはさほど好きでもなかったのですが、こういうエピソードを聞いているうちにちょっと好きになってしまったかもしれない。
私のobjectは使いたくないで指す仕様
はHTML4.01の仕様を指していますね。となると、仕様上では問題の無い行為
は確かにおかしいなあ。仕様上ではdata、classid属性を指定しないことを明確に否定されていないとはいえ、良いとは書かれていないし、object要素はオブジェクトを埋め込むための要素であると書かれていることは間違いないし。となると、少なくとも仕様上では問題の無い行為
は不適切。DTD上では問題の無い行為に変更します。
北村さん、ご指摘ありがとうございました。
ついでに、原文の変更が不可能な状況
のほうを考えようと思っていましたが、そういう状況が想像出来なかったのでそちらの記述も削除。
「訳ではない」が否定するものにて、あれは必ずしも準拠しているとは限らないと云う意味です。
とのご回答を根拠付きでいただきましたので、以下の文章はツッコミにはなっていないのですが、消すのももったいなのでそのままで。
これに疑問を抱くのは私だけでしょうか。確かにOperaは厳密です。
<と、;を忘れて文字実体参照を書いても、<と補完してくれません。然し、だからと言って補完しない訳ではないのです。あくまでも、UAと云うのはスタイルシートを使用してHTMLを表示しているのです。詰り、UAで表示出来るかどうか。それは記述ミスを発見する手段として邪道です。仮にInternet ExplorerとOperaが上手く補完して閲覧出来たとしても、そのHTML文書が文法に準拠している訳ではないのです。
そのHTML文書が文法に準拠している訳ではないのです。
という部分を、そのHTML文書は文法に準拠していないと読みました。（「準拠しているとは限らない」という意味であれば、以下の話はどうでも良い話です。）
HTML4.01の勧告には、以下のように書かれています。
Note. In SGML, it is possible to eliminate the final ";" after a character reference in some cases (e.g., at a line break or immediately before a tag). In other circumstances it may not be eliminated (e.g., in the middle of a word). We strongly suggest using the ";" in all cases to avoid problems with user agents that require this character to be present.
省略しないことを強く勧めていますが、いくつかの場面で省略可能であるとも書いてあります。もちろん私も省略を勧めませんが、文法上ということであれば正しくなる場合もあるのではないでしょうか?
参考として、日本工業規格(HTML文書版) JIS X 4151-1992の8.4.5 参照終了の項からも引用します。
参照終了 = (refc | RE)? ―(61)備考 REで参照が終わる場合，そのREは，データとしては無視する。
refc又はREは,その参照の中に現れうる文字が直後に来るのでなければ省略することができるし,参照終了の省略と解釈できる文字が直後に来るのでなければ省略することができる。
とにかく、;が無い状態が常に文法上の違反になるわけではありません。
それにしても、この手のアプリでは必ずといっていいほど Opera のアイコン取得ができないですね。これは Opera の問題なんだろうな。
Resource HackerでOpera.exeを見ようとすると、このリソースは標準的な構造ではありません..."EXE compressor"で圧縮されていると思われます。
と出てきます。この辺が原因かなぁ。などと考えながら軽く調査してみると、Beside Baysideさんの2003/04/01の日記に解決方法（ソフト側）が書いてあった。
なーんだ、じゃ、取れなくても仕方がないや。……って、やはりあきらめるわけにはいかんのですよ。どうしても取りたいわけですよ。ということで、ウィンドウハンドルからごにょごにょして実行ファイルのフルパスを取得して(すげー面倒)、そこからSHGetFileInfoでゲットしてみると、取れました。まぁ、取れて当たり前ですが。まぁ、そもそもOperaが悪いんだ、といいたいところですがどーせhIconSmallを設定していないソフトが他にもありそうなのでとりあえず対処、と。
ってのはたぶんhIconSmallhIconSmのことだと思う。まあそれはそれとして、こういう解決方法もあるということを覚えておこう。結局のところ標準的なexeではないという部分はどうでも良い話だった。
でも、hIconSmを指定していない状態でもタイトルバーにアイコンが表示されているということは、hIconを指定しているということにならないのかな?なるということであればGetClassLongでGCL_HICONを指定すれば取得出来そうな気がする。それを16*16として描画しても良いんじゃないかなぁ。家帰ったらやってみよう。（やらない可能性大）Operaは悪くないに続く。
Operaのアイコンは取得できない?で考えたことをやってみた。
#include <windows.h>
int main() {
HWND hwnd = FindWindow(NULL, "Opera");
HICON hicon = (HICON)GetClassLong(hwnd, GCL_HICON);
HDC hdc = GetDC(0);
/* 描画位置は適当 */
DrawIconEx(hdc, 100, 100, hicon, 16, 16, NULL, NULL, DI_NORMAL);
ReleaseDC(0, hdc);
return 0;
}
普通に取得、描画できた。ということは、Noriyaさんの言うこの手のアプリ
はGCL_HICONSMの取得しかしていないということになる。
で、MSDNのWNDCLASSEX構造体のhIconSmメンバーの説明を見てみると、If this member is NULL, the system searches the icon resource specified by the hIcon member for an icon of the appropriate size to use as the small icon.
と書かれていることから、hIconSmは「指定しない」という選択肢もありなようだ。となると、Operaに問題があるわけではないということになる。たぶん。（どうでもいいけど、MSDNにWNDCLASSEX構造体の項の日本語訳が無いのは何故?）
せっかくだから、全てのWindowのhIconSmに強制的にhIconのハンドルをセットするようなアプリでも作ってみようかなあ。大抵のアプリはhIconSmしか見ていないんだったら、こっちでセットしてやる。みたいなノリで。
どうせなら常駐型にして何かが起動するたびにhIconSmにセットしにいくようなのにしてみる。いや、そんなの誰が使うんだって話だな。
ReleaseDCを忘れてました。今のソースには追加済み。
わざわざこのソースを何かに使おうとする人なら分かると思いますが、FindWindowで指定されている"Opera"の部分は状況に応じて変更してください。というかむしろlpClassName部分に"OpWindow"を指定したほうが良いかも。
４月に「サナギさん」２巻と「もずく、ウォーキング！」１巻が同時発売される予定です。
忘れないように。
金曜日に同僚と酒を飲んでたのですが、その時の会話。
今思い出したので、実験してみた。
C Z-ADD 0 I 2 0
C MOVEL '1A' B 2
C MOVE B I
C SETON LR
C RETURN
うわ。ほんとだ。落ちずに、Iには11が入る。
同僚曰く、'1S'とか'1B'とかでも落ちないらしい。まあこの時点でなんとなく想像は出来てたんだけど、EBCDICでは0xF0〜0xF9が'0'〜'9'を指していて、'A'は0xC1なんですよね。結果に11が入ることから、つまり0xC1の1の部分のみの評価しかしてないということになる（0xE2の時は2になるし）。一桁目が1〜9であれば正当な数値とみなされるようです。
まあそういう仕様なんだろうな。個人的には10進エラーにしてもらいたいところなんだけど。
コンパイルオプションとかSYSVAL値によっては動きが変わるのかな。今度調べてみよう。
文章が意味不明だったのでちょっと変更。つまりがつまりになってないし。
- 114 ：マロン名無しさん ：2006/02/08(水) 14:49:00 ID:???
- 113と似た意見になるかもしれんが、
キャストアウェイだけど、あれは映画でしかでけん奴だよな。
カメラワーク（映像的な表現手法）とトムハンクスの演技、
監督と俳優の二人だけでガチ勝負みたいな。
ストーリーメインで見たい人には退屈かも知れんけど、
そうじゃない部分を見たがる人には興味深い作品。
漫画でしかでけん作品って、どんなんだろ。
羊の歌のねっとりした感じは、あの人の絵柄があってのもんって気がしたけど。
羊の歌のねっとりした感じは、あの人の絵柄があってのもんって気がしたけど。
の部分、私もそう思った。「羊のうた」は映画化もしたしアニメ化もしたんだけど、原作の漫画が一番良かったと思う。単に原作厨のたわごとでしかないのかも知れないけど、原作のあの味は他の媒体では出せないだろうと思った。
せっかくなので、今更だけども映画版の感想を書いてみる。（かなりうろ覚えなんだけど）
一砂が弱々し過ぎたというかなんと言うか、原作とのイメージのギャップに耐えられなかった。原作を全てにおいて踏襲する必要はまったくないんだけれども、弱さを前面に押し出している感じがちょっと勘弁。
（仮の）両親の前では良い子で、あまり自分の（悪い）感情を表に出さないという原作の一砂が好きだ。原作の一砂はそんな性格だから、感情を表に出したときの強さであったり弱さがうまく強調されていた気がする。
あと千砂の美しさが際立っていなかったかなぁ。加藤夏希さんがきれいじゃないということではないんだけど、あの怖いほどの美しさはやはり実写では無理だよと思った。なんだか無理してるような印象を受けた。
それと、一番重要（?）な八重樫さん。なんというかあんまりかわいくなかったかなと。いや美波さんはかわいいんですけど、八重樫さんっぽいかわいさは無かったと感じたというだけです。初期の八重樫さんっぽさはあったんだけどね。
原作が終了する前に映画化したので、結末はオリジナル。でも全然記憶に無いんだなこれが。どんな感じだったかなぁ。
あ、どうでも良いけど木ノ下って出てきたっけ?これもまったく記憶に無い。
そうそう、私は原作の結末には微妙に納得言ってないんですよ。一つ前のところで終了させても良かったんじゃないかなと思ってます。世界観的にはあそこで終わった方がきれいだったんじゃないかな。八重樫さんには酷な結末だけども。最終回の水無瀬さんと八重樫さんの会話は良いんだけどねぇ。
以下OVAの感想もうろ覚えで書いてみる。
絵が冬目先生っぽくなかった。でも、林原めぐみさん、関智一さんの声は良かったよ。木ノ下も出てたし。
まあ一番の問題は八重樫さんがあんまりかわいくなかったというところかな。千砂は許容範囲内だったんだけど。
とにかく原作の八重樫さん最高ということで。
そういえば冬目先生って女性なんですよね。なんとなく「女性的な書き方をしてる男性」だと思っていたので、知ったときはちょっとびっくりしました。まあだからと言って特に何も無いんですけど。
冬目先生の作品はそれなりに読んでいるわけですが、好きなのは「黒鉄」かな。鋼の迅鉄がかっこいい（特に3巻のラストとか）し、紅雀の丹がカワイイし、水葉もカワイイし。
どうでも良いけど、「イエスタデイをうたって」のシナ子先生は性格最初と変わってないか?
- 223 ：以下、名無しにかわりましてVIPがお送りします ：2006/02/07(火) 20:21:17.27 ID:VEeEdpaI0
- ドラクエで言えば主人公が最初スライムで勇者とか村とか襲いながらレベル上げていって
レベルとか条件満たせば上級モンスターに転生できて
最終的には魔王軍幹部とか魔王とかになれるゲーム
それなんてダークキングダム?
転生は出来ないし、魔王にもなれない（幹部にはなれる）けど、大体そんな感じ。
途中にMMRネタがあるんだけど、タナカとイケダの先輩後輩関係が入れ替わってるのが許せない。MMRを読んだことが無い人がMMRネタを書くと良く間違える。
実際は、キバヤシ、ナワヤが同期。その下にタナカ。その下にイケダ。その下にトマル。イケダは「タナカ」と呼び捨てにすることは無いし、タナカは「イケダさん」なんて言わない。
before、after擬似要素のcontent特性のみで装飾をしているスタイルを代替スタイルに追加。すでに似たようなことをやってる人がいる気がするけど気にしない。
たぶんOperaくらいでしかまともに表示できないと思う。
- 53 ：Name_Not_Found：2006/02/16(木) 05:21:48 ID:???
- ふと思ったんだけど
仕様書に沿って書くを「オナニー」と一蹴される言語って他になくねえ？
C言語には、strictly conforming program(規格厳密一致プログラム)なんて言葉がありまして、「strictly conforming programを書くことに意味は無い」といった話をたまに聞きます。HTMLよりもさらにオナニー
と言われやすい気がする。
そういった話は、結構どの言語にでもあるんじゃないかと予想してます。
ユーザースタイルに以下の記述を加えて一人でニヤニヤ。たまにツボに入って笑いがこらえきれないことがある。仕事場なのにね。
q:before {content:"\A" " ∩＿＿＿∩" "\A" " | ノ ヽ" "\A" " / ● ● | " "\A" " | ( _●_) ミ 「" ;}
q:after {content:"」クマー\A" " 彡､ |∪| ､｀＼" "\A" "/ ＿＿ ヽノ /´> )" "\A" "(＿＿＿） / (_／" "\A" " | /" "\A" " | ／＼ ＼" "\A" " | / ) )" "\A" " ∪ （ ＼" "\A" " ＼＿)" "\A";}
まあAbsoluteSphereさんのクマースクリプトと似たようなものです。スクリプトではなくCSSでやっているというだけ。
とりあえず10分くらいは笑える。10分を超えると飽きる。
HK-DMZ PLUS.COMさん経由。
内閣府によると、朝食をとらない割合は、小学５年生で４％（００年度）、２０代男性は３０％（０３年度）、３０代男性で２３％（同）。こうした傾向が食生活をめぐる大きな問題の一つであるとして、朝食を抜く小学生をゼロに、２０代、３０代の男性はいずれも１５％以下になるよう目標を設定した。
そんなに少なかったんだ。もっといるもんだと思ってた。
とりあえず私は無理。朝は出来る限り多く寝たいので、朝食をとる暇があったら寝てます。
HK-DMZ PLUS.COMさん経由。
なんでジャイ子は不明でジャイアンは公開してるんだろう?ジャイ子と同じ名前でいじめられるという発想があるなら、ジャイアンと同じ名前だからいじめられるという発想もあり得ると思う。というかジャイアンのほうが有名なんだから（たぶん）むしろジャイアンの名前を不明にしたほうが良かったんじゃないか?
まほろさんネタでの回答とは…。επιστημηさんってこっち（どっち?）の人だったんだなあ。こういうの好きだ。
その後のBanさんのツッコミに対するレスも良いなあ。
- Ban 2006/01/21(土) 13:55:35
- # サンプルなので些事ですが、将来の閲覧者のために。
CreateThreadで起こしたスレッドからiostream呼んだらよくないかと。
# Win32onlyで書かにゃならんです＞CreateThreadのハンドラ内部
<MSDN>
CreateThread
-- snip --
C のランタイムライブラリに記録されている関数を使うスレッドは、
CreateThread 関数と ExitThread 関数ではなく、
C のランタイム関数である beginthread 関数と endthread 関数を使うべきです。
この方法に従わないと、ExitThread 関数を呼び出したときにわずかなメモリリークが発生します。
</MSDN>
- επιστημη 2006/01/21(土) 14:04:42
- ツッコミに感謝。その通りです。
このままほっとくと
まほろさんがその機能を停止するまで
残り390日
なんちて
これを言いたかったために、わざとメモリリークが発生するようなコードを書いたのではないかという疑惑あり。（私的に）
επιστημηさんとは、C++標準化委員会の中の人の一人で、C/C++系の質問掲示板でよく回答されている方です。
ようするに偉い人。
The Shakespeare Programming Languageについてのコンテンツの内容を結構大きく変更。
私もあなたは相手の気持ちを理解していない
と言われるタイプです。（だから何?）
伝達とは伝えたら達すること、通信とは通じたと信じること。それ以上を望んではいけないのです。
哲学の話でクオリア問題ってのがありましたね。私が今見てる、感じている質感はどうやっても他人に伝えることが出来ないというもの。これを何らかの方法で解決することが出来るのなら（無理そうだけど）、もしかしたら他人を理解することが出来るようになるのかもしれません。
以下の方法でも復旧可能です。
- Webブラウザ上ではなく、自分の使い慣れたテキストエディタで日記を書く。
- 長時間かけて書いた日記を送信中にサーバエラーでデータが消えることを回避する（マスターデータは手元にある）。
- ネットにつながっていないときにオフラインで日記を書く。
- 過去の日記の表現全体をまとめて直して、一気に送信する。もしくは一気に削除する。
- 指定した時刻まで下書き状態として日記投稿を保留する。
textareaを使わずに、自分の使い慣れたテキストエディタで
書くのは結構普通のことだと思っていたので、これがセールスポイントになるということにちょっと驚いた。
いや、これが初心者向けのツールだったらまあ分かるんですけど、動作条件を見る限り、初心者向けでは無いだろうと思う。となると、中、上級者向けのはずなので、それなら自分の使い慣れたテキストエディタで
書くことはセールスポイントにはならないだろうと思ったわけです。
どうでもいいけど、長時間かけて書いた日記を送信中にサーバエラーでデータが消えることを回避する（マスターデータは手元にある）。
と、ネットにつながっていないときにオフラインで日記を書く。
は、テキストエディタを使用することの利点なので、mixi Diary Writerの利点ではないような気がする。
まあそれらを利点としなくても、メインである過去の日記の表現全体をまとめて直して、一気に送信する。もしくは一気に削除する。
は結構良い感じ。いつか使うかもしれない。