メモ。

あやしいところは。

clear:bothしてみる。親もfloatしてみる。float:noneしてみる。

IE6用には _width _marginなどアンダースコアプロパティ

FireFoxなどには :root疑似クラス（？）

を使って後で指定。（ネットショップで一日120万PVのアクセスログを見る限り、IEの圧勝）

inline-blockは確かに便利だけどfirefoxは対応していないので使わないでくれ。ブロック要素をいじるんでhtmlの方を書き換えることになっておおごと。

input passwordフォームの黒丸。IEだとＭＳゴシックなど日本語フォントの指定が原因で「黒丸」が大きい。半角に合わせるにはそこだけfont-familyをarialなど欧文フォントだけ指定。でもってそこにpadding:0なんてのを指定するとIE6だと黒丸が欠けてパックマンになるんで、_paddingを少しだけ。なんだかなあ。

同じく input textエリア。カーソルの高さとフォームの高さが合ってなかったり、カーソル点滅後微妙に上とか下にずれる時。フォントと行間などがうまく合ってない。とりあえずline-heightの指定を1emにすれば妙な挙動はなくなる。（100%とかpx指定だとカーソルが動く）

IE6は、センタリングのためのmargin autoをうまく解釈してくれないことが。親にtext-align:centerを。

IE6でdiv要素の最後の文字などがヨコチン状態になることがある。paddingを0pxに指定してると起こりやすいので_paddingで適当に（検索すると3pxという事だけど、1pxでもハミチンの収まったところもあった、かな）ていうかIE6でpadding:0は危険。

negative marginがごちゃっとあると、FireFoxでは、下のレイヤーの見えているリンクがクリックできなくなったりする。用もないのにネガティブマージンは使わない。

border:1px red solid をエディタに登録しておいてワンキーで埋め込めるようにしておくと便利。

てのが仕事絡みのリニューアルメモ。

「ブラウザ」の「戻る」挙動にハマった。

IE7。

ログインページでID、パスワードを入れてエンター。LocationでHOMEに飛ぶ。工事中のHOMEにはリンク先のない空リンクがたくさん。ある。それを適当にたたくとページが遷移してHOMEが再び。そこで「戻る」と、なんとログインページで入力した内容がHOMEのinput textに出るじゃありませんか。よりによってログインIDだ。こんなものが現れたら腰がぬける。キャッシュがいけないのか、Locationで飛ばすのがいけないのか、それともJavaScriptがなにかやってるのか、で悶絶。

ところがFireFoxだとこんなことは起きない。「戻る」とログインページに、意図したとおり戻ってくれる。

ぐぐるための単語すら思いつかず…。あれこれ試してみたところ、a hrefが空のリンクの時にだけ起こることが判明。ページが完成したら、リンクが空、なんてことはありえないのでほっと一息。

しかし、IEはなんでまた違うページのフォームのデータを余計なところに出すんだろう。空のリンクを踏んだ時の挙動が変なのかな。

てのが読書SNSリニューアルのネタ。

今回は表示回りの部品を先に作ったので、スクリプトを書きながらスタイルシートも一緒に考える必要がないのでそっちはラク、かも。

うちの王様は点滴から投薬に切り替え、自宅療養。

そういや、古処誠二「敵影」が直木賞候補になってたのか。うーん、残念。

都心は底冷え…

[15:01:48]

ありゃ。rssが変だった。

[更新]2026-02-04 09:58:44

ウチの王、昨日あたりは食欲もあって少し元気になって目に力が戻ってきたように見える…んだけど、ヨメの話だと腎不全は治らないし予断を許さない状態に変わりないと。ううう。

サーバーからデータを取ってきてブロック要素にhtmlを流し込んで表示させる。てなことやってるんだけど、JavaScriptがよくわからんので、個々のやってることは単純。JavaScriptで、あのデータが欲しいと、サーバーのperlに伝えれば、perlがpostgresqlからデータを取ってhtmlにまで加工して返すので、それを特定のブロック要素にinnerTextで流し込むだけ。

ただ、perl、JavaScript、スタイルシートが絡むので、perlの出すhtmlが変なのかJavaScriptから渡したパラメータがおかしいのかスタイルシートがおかしいのか

、意図したものが出てこない場合の原因特定が面倒だ。

さらにおまけに、サーバー側ではmod_perl2のキャッシュ、ブラウザ側はJavaScriptのキャッシュで、apacheの再起動やらブラウザの再読み込みやらの必要もある。

alert、printを埋め込みまくり、tail httpd-error.logしまくり…。このあたりの効率を考えないと遅々として進まない。

[更新]2026-02-04 09:58:59

ますますへろへろのグロッキー状態となる。いやもうスタイルシートの微調整は気力体力の消耗戦でうんざり。

まだまだこれからIE6対策を埋め込まにゃならん。しばらく休みも取れそうにない。初老目前のよれよれの身体にはキツイぜ、パンク寸前。

んで。ウチの読書SNSのリニューアルも。HOME画面で今まであまり使ってなかったテーブルを使うようにしたところ、レスポンスががっくり低下。こりゃ仕事の方のサイトと同じく速度をなんとかしないと、と気が重くなってた。ふと見るとテーブルのいくつかにindexをつけてない。まあ「お守り」程度だろうけど、とjoinのキーにしてるカラムにindexをつけてみたら、体感できるほど劇的に速くなってびっくり。…ていうか、常識なんだろうな。

prototype.jsを入れたことだしついでに scriptaculousも。ドラッグできるコンテナが欲しかったので試してみようと。

最初、perlのスクリプトのミスで同じidを複数、一枚のhtmlに書き出していて、まったくうまく動かなかったのは内緒だ。another lint にhtmlを投げて気づくまで小一時間もかかったのはさらに内緒だ。

それはともかく、簡単な、それこそ数行でドラッグのできるコンテナが書けるのでらくちんだ…けど、これはけっこう重いかも。ドラッグ中、コンテナが半透明になる効果なんていらないからもっと軽くならんもんか。そもそも protptype.js と合わせると200K近くにもなるし、読みこむのも大変じゃないか。うーん、どうすべか。

本棚を見ていてその場で気楽に手に取ってみる、という感じにするには、ドラッガブルなコンテナがもってこいだしなあ。

まだMy本棚のレイアウトや細工を考えなきゃいけないんだけど、こんな時間に電車の中でこうやってネットしてるようじゃ時間が作れないわな。しょぼ。

[01/10 01:51:46]

思いつきで、dragdrop.jsの中を覗いて。

starteffect: function(element) {

と

endeffect: function(element) {

の中のopacityを1にしてfrom、toを取ってみたら、もさもさ重かったdragが嘘みたいにシャキシャキ動くようになった。これなら使いものになるぞ。

今日は初通院。コレステロールの監視はともかく。12月から咳がひどくて、と話したらレントゲンやら吸引やら、たいそうなことになって驚いた。怪我でも昔は舐めてりゃなおるで済んでたようことも今では大騒ぎだし、咳だって寝てりゃ治るで済んでたような気がするし。

とりあえず、結核でも肺炎でもなかった。なんでも百日咳とかマイコプラズマとか気管支炎とかあれこれ考えられるんだそうで抗生物質を処方されてしまった。うううむ。

てなことやってるうちに、正月も終わりじゃないか。仕事がらみのサイトリニューアルはスタイルシートが複雑なもんで、どこが原因か特定するのがめんどうなところばかりが残ってるし、ウチの読書SNSのリニューアルはHOME画面のレイアウトと小細工ができただけ、で時間切れっぽい。

読書SNSのHOME画面は、面白いもんだから無駄にAjax使いまくり。今度はデータ取得とデータ加工、表示を分けて作っていて、こっちの方が無駄がない、かも。…とはいえ、自分でどんなサブルーチン（いまどきはメソッドというんだそうだ）を書いたかメモしないと忘れて、同じようなのを書いてしまいそうだけどね。

FireFoxとIE７でしか確認してないけど、たぶん、IE6はガタガタ（後で_widthとか入れるしかない）だろうし、SaFariはHTTPRequestがたぶん文字化け化け（後でBOMを入れるしかない）だろうなぁ。

…ひと月ぐらいかかりっきりでやっても終わるかどうか。時間が欲しいところだ。

[更新]2026-02-04 09:59:45

悶絶。レスポンスが悪いのだ。

ネガティブマージン使って左右を入れかえたり、画面のリサイズをJavaScriptで監視してdiv要素の幅をいじってたり、さらにおまけに１ページ270枚ものサムネイル画像。

画像は、急遽でっちあげた、８枚を一枚に合成して返すスクリプトで様子見（本番では当然全部作成して静的にする）とりあえずこの時点でほんの少し早くなったけど。

ネガティブマージンを使うと、ブラウザは全部読み込んでからレイアウトを決めるっぽい。googleのLoadTimeAnalyzer（？）で見てると、同じようなデータ量の別サイト別ページで、読み込み自体はこちらのほうがむしろ早いのに、表示開始で負けてる。最後まで読み込むのに、こちらは３秒弱、対象にした別サイトでは倍近い６秒弱。ソースを見るとテーブルの入れ子使いまくりなのに、こちらより早いんで愕然。

しょうがないんでネガティブマージンを使わずfooterの位置はなかったものとしてpositionのabsoluteで配置してみる。するとブラウザはある程度読み込むと表示を開始する、っぽい。確かに体感できるぐらいは早くなった。…けど、まだ表示開始が遅い。ちょっとふんづまりを起こしてる。

JavaScriptが、リサイズのために計算してるからちょっと待ってくれと。テーブルタグで作るとたぶんこのリサイズ処理が不要になる。

どうせリスト画面だし、このページだけでもテーブルタグで全面的に書き直すことも考えなきゃいかん。ショップサイトはスピードが最優先。コンマ数秒の違いが売上に直結する、と。じっくり選ぶような商品なら話は別なんだろうけど、ほんとにレスポンスで売上は違ってきそうだし。うううむ…シビア。へろへろ。

webは、間違いなく、文書の論理構造とデザインレイアウトを分ける流れだ。

ブラウザのレンダリングも、検索エンジンも、その方向に沿って表現力をあげるし効率よくクロールするはず。

なもんで、なにかとcssとhtmlの方が都合がよろしい。

テーブルタグを使ってレイアウトすると、今後ちょっとしたレイアウトやデザイン変更に、時間労力など「無駄な」コストが発生して、硬直化したサイトになってしまう。phpやjavascriptを、一度テーブルタグページに埋め込むと、縦のものを横にするだけで、いちから書き直しだ。

…とはいえ、使う側はタグなんて関係ないしねえ。

[更新]2026-02-04 10:00:50