application/rdf+xml にしました今まで一部 RSS 読み取り機におもねって RSS への link 要素の type 属性の値を application/rss+xml にしておりましたが、iana の Application Media-Types に2005年03月02日現在 rss+xml なんて値はないので気持ち悪いから全部 application/rdf+xml に変更しました (RSS のルート要素は RDF の名前空間を持っているし)。
と言う訳で RSS 読み取り機が XHTML に記述された link 要素や a 要素から自動的に RSS を検出出来なくなるかもしれませんが、ろばQとしてはそんな事知るかの精神で行きたいと思いますので宜しくお願いします (妥協して application/x-rss+xml ですが、多分RSS 読み取り機は自動認識できない)。
既に解決しているのですが、03月02日昼頃から03月03日昼頃まで、ろばQの account で netlaputa の smtp server に接続できない状態になっていました。
netlaputa の電話受け付け時間が10:00 - 18:00 (土日祝祭日除く)
と言う事だったので03日の昼休みに問い合わせてみると、数件分の mail account の password で障害が発生していたとの事。障害が発生してしまうこと自体はある程度仕方がないと思うのですが、障害が有ったなら、障害情報に記載しろ (2005年03月03日14時30分時点でそれらしい記述なし)。netlaputa とっては数千、数万ある account の内の数件の問題かも知れないが、ろばQとしては2個持っている account が2個共使えなくなったのだし、万が一を考えると背筋が凍る。mail が使えない間の見知らぬ女性からの間違いメールから始まった恋とかの機会損失とかどうしてくれるのだ < それは spam。
冗談はさて置き、真面目な話しゃれにならないので、せめて障害情報には記載しろ、と久しぶりにクレーマモードに変身して苦情 mail を送信。
CNET JapanによるとWindows責任者のJim Allchinは、Intel Developer Forumで講演を行い、64ビット版Windowsのデスクトップバージョンは4月初旬に、サーババージョンは4月末に登場すると述べた
との事。64bit化では他のOSよりかなり出遅れておりましたが、これでと言うか、漸くと言うか、やっとと言うか。昨年の02月に早ければ2004年夏、遅くても年内にはでるだろうと勝手に予想を立ててAthlon64の PC/AT 互換機を購入していたろばQとしては感慨無量と言わざるを得ます (何が言いたいのか自分でも今一つ不明)。
今年の夏には IE 7 が提供されるそうですから、以降は Windows + IE 環境しか考えずに site を構築する場合でも 64bit 版 IE 7、64bit 版 IE 6、32bit 版 IE 7、32bit 版 IE 6 を考慮せねばならなくなって来るんでしょうか。さぁ、いよいよ面白くなってまいりました。
我らが、大英帝国の名誉騎士で在らせられるゲイツ様、どうかこれを機に、仕様を守らない場当たり的な表示だけを愛する連中を皆殺しにしちゃって下さい (守るべき仕様は公開されていて誰もが使えるなら別に Microsoft 社独自の物でも構いませんから……余程優れていない限りろばQは使いませんが……)。
例えば XHTML の q 要素など、 RSS の description 要素の中に XHTML の断片をそのまま RSS に記述できないかな、と言う話 (面倒臭がらずに XSL か何かで XHTML の要素に頼らなくても意味が通じる #PCDATA に変換しろよ、と言うご意見もあるかと思いますが、仰る通りでございます)。
結論から言えば RDF を使う場合、rdf:parseType 属性に Literal を設定する事により、その (rdf:parseType 属性 を記述した) 要素の内容に他の XML 系言語を記述する事が出来る模様。具体的には以下のような感じ。
<ex:sample rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml">
<q cite="http://example.com/a.txt">(引用文)</q>
</ex:sample>で、初め rss:description に rdf:parseType を記述しようかと思ったのですが、rss:description の内容は #PCDATA と成っており、(この記述も必ずしも問題があるとは思わないのですが) 一般的な RSS 読み取り機で如何にも不具合が出そうなので、その点内容 (の XML 的な構造) が余り厳密でない Dublin Core (Dublin Core (ダブリン・コア): 書誌情報メタデータの共通語彙) を使えば発生するかもしれない不具合も狭い範囲で抑えられるだろう、と言う事で最終的に RSS に埋め込む XML の断片は以下の通りに。
<dc:description rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml">
<q cite="http://example.com/a.txt">(引用文)</q>
</dc:description>序でに、title 要素にも XHTML の断片を埋め込みたいので、同じように dc:titleも併記。
<dc:title rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml">
(XHTMLの要素を含む、記事名と成る XML の断片)
</dc:title>と、ここまでは解かったのですが、そもそもろばQは XHTML 文書の meta 情報配信の手段として RSS を利用しているので、余りごてごてした情報は RSS に含めたくないと言う事、そして何よりDublin Core (ダブリン・コア): 書誌情報メタデータの共通語彙にDC要素の内容は文字列に限るべきだという意見もあり、微妙なところです。
と言う記述を見つけてしまったので、現在実装はせずに検討中。
なお、今回の件に関して IRC #xslt で色々相談させて頂きましたのでこの場を使って勝手に感謝。実際使うかどうかは別にして、XML やら RDF やら XSL やら色々勉強になりました。
実はあまり意味のない行為なのかな?
CSS の適用優先順位は !important 付き閲覧者側 stylesheets、 !important 付き制作者側 stylesheets、制作者側 stylesheets、閲覧者側 stylesheets、UA の default stylesheets と成っている訳ですが、html.cssを殺したFirefoxでさとみかん日記系を見てまわったスクリーンショットを淡々と記録したよ は、(その通りなら) 本来 HTML 処理機が持っていて当然の UA の default stylesheets を無効化しているので (例えば、要素で style 指定を行わない事になっている HTML4.01 strict であっても、ol の子要素の li 要素は番号付きリストとして表示されると言うのは HTML の仕様の内と考えて良いと思います) 、この様な状況を前提として制作者側が CSS を記述する必要はないと思います。
しかし、擬似的な状況として、閲覧者が !important 無しで UA の default stylesheets を上書きしてくる事はありえる (と言うか CSS 仕様でそう言う事が出来ると明記されている) 訳で、で有れば、html.cssを殺したFirefoxでさとみかん日記系を見てまわったスクリーンショットを淡々と記録したよを擬似的に全 CSS プロパティに default 値が設定された閲覧者側 stylesheets を適用して閲覧した場合に、各 site はどのように表示されるかの一覧として見る事が出来ると思います。
正直、本来 HTML として default 値があるのに別な値を上書きしたら HTML としての表示が壊れるのは当たり前なので、それを気にする必要は特にないと思いますが、しかし、もし制作者側 stylesheet の指定が、例えばある要素は display:block; である事を前提にしていて、他の値では表示が狂うと言う事なのであれば、制作者側側の正しい指定によって site の表示が崩れる可能性がある訳ですから、(display に限らず) その style が成立するのに必要なプロパティは全て指定しておかねば成らないのではないでしょうか。結論としては制作者側で必要な指定は制作者側で記述すると言う事に成ると思います (一般には color プロパティを指定する場合には background-color も指定する、などが有名です (参考: CSS の color と background は一組で書くべき理由))。
で、具体的に制作者側で必要な指定とは何か、と言われると場合によるので個別に各自判断と言う事に……。何も言ってないのと大差ないぞ > 俺。
IANA の各文書を読み直して .htaccess を書き直したので、ろばQ屋本舗内の各文書の MIME 型を、拡張子別に列挙。
csstext/csshtmltext/htmljsapplication/x-javascript (text/javascript や application/javascript は登録されていない)lzhapplication/octet-streamrdfapplication/xml (application/rdf+xml の方がより好ましいが、Firefox 1.0.x におもねった)rssapplication/xml (application/rss+xml は登録されていない。application/rdf+xml の方がより好ましいが、Firefox 1.0.x におもねった)svgapplication/xml (image/svg+xml や application/svg+xml は登録されていない)xhtmlapplication/xhtml+xmlxmlapplication/xmlxslapplication/xml (text/xsl や application/xsl+xml は登録されていない)ほぼ1ヶ月ぶりの日記。と言うか既に日記ではなく、月報。
なんか、やる事が色々あるなぁ (やる事が無いよりも何百倍も幸せ)。
XMLHttpRequest の code を見て思った先月辺りから凄く狭い範囲の巷で大人気の XMLHttpRequest を使って何か出来ないかと思ったり思わなかったり。色々やる事が有るんちゃんうか > 俺、と思いつつ、その場その場が面白ければ良いじゃない、の精神で。
で、XMLHttpRequest に関して色々 google で調べてみたのですが、そこで散見出来てしまうのがこんな code。
function processReqChange() { // only if req shows "loaded" if (req.readyState == 4) { // only if "OK" if (req.status == 200) { // ...processing statements go here... } else { alert("There was a problem retrieving the XML data:\n" + req.statusText); } } }
うわっ、何コレ、気持ち悪ぅ。if 文の条件式の中に 4 とか 200 とかが直接書いてある。コメント文で loaded
とか OK
とか書かれているから、4 や 200 が一体何であるか解からなくなる事は無いでしょうが、そう言うのは const や enum で外に出しませんか、普通 (ECMAScript 3rd ed. には const も enum も有りませんけど)。
上記引用元の Dynamic HTML and XML: The XMLHttpRequest Object はそんな事百も承知で、一々値を列挙すると逆に code の総量が増える事によりの可読性が下がり、例示として相応しくなくなるので態々 if 文の中に数値を直接書いているのは解かるんですが、実際 XMLHttpRequest で巧い事やってる (例示ではなく実際動いている) code をそのまま頂いてしまおうと (嘘) 参考にさせて頂こうと見てみると、javascript の中に上記の様に 4 だの 200 だのと言う値が直接書かれていたりとかして一寸げんなり。
それとも最近では (或いは script の様な一般的に短く、構造も複雑ではない code では) 一々定数を前もって宣言したりとかはしないのだろうか (実際、1回限りしか登場しない定数の場合、しっかりとコメント文が書かれていれば特に保守性、可読性が下がるわけではないし)。
と言いつつ拙作 javascript を見直してみると、if(url.test("https://robaq.info/") === false) とか書いて有りました。笑い (笑って誤魔化すな > 俺)。
03月17日、会社に1時間遅刻。
本気で時計を読み違えていた (遅刻していること自体に気付いて居なかった) ので出向先に連絡なし。当然出向先から自社や自宅に連絡入っており、出社時にようやく遅刻している事に気が付いて各所に頭下げまくり。
全く冗談抜きに社会人としてどうかと思う > 俺
表は項目に縦横2つの項目名があって、その項目の意味は2つ項目名から解釈される。
箇条書きは0又は1つの項目名があって、その項目の意味は (有れば) 項目名と (場合によって) 箇条書きの順番から解釈される。
違いが有るのだから当然使い分けの必要が生じるし、単純に交換可能なものでもない。
例えば MFSA 2005-04: view-source:形式の URL を使って安全なサイトを示す鍵アイコンが偽装される の影響を受ける製品名
と修正済みのバージョン
は表の方が相応しい。例えば HTML の場合、以下の様に成る。
<table summary="MFSA 2005-04: view-source: 形式の URL を使って安全なサイトを示す鍵アイコンが偽装される問題の、影響を受ける製品名と修正済みのバージョン">
<thead>
<tr>
<th>影響を受ける製品名</th>
<th>修正済みのバージョン</th>
</tr>
</thead>
<tbody>
<tr>
<th>Firefox</th>
<td>1.0</td>
</tr>
<tr>
<th>Mozilla Suite</th>
<td>1.7.5</td>
</tr>
</tbody>
</table>上記で例として用いた MFSA 2005-04: view-source:形式の URL を使って安全なサイトを示す鍵アイコンが偽装される は そのテーブル、本当に必要?で例として用いられていた為本文書でも取り上げただけであり、MFSA 2005-04: view-source:形式の URL を使って安全なサイトを示す鍵アイコンが偽装されるの markup に対して批判の意図はありません。
最近話題の onload イベントで javascript + DOM により大量の HTML の要素を追加して要素の角の見た目を丸くする話に対して、javascript だから HTML は汚れないとか、DOM を使うなら許容できると言った記述があったので駄突っ込みを。
onload イベントで javascript + DOM により大量の HTML の要素を追加して要素の角の見た目を丸くする行為がHTML を汚さない許容できるもっとも重要な所は onload イベントで実行するところにある (別に読み込み後に onclick イベントなどで適用しても良いのだが)。要するに server から 汚れていない HTML が UA に渡され、UA 側で HTML 側に加工を行うから、加工後の HTML が仕様上宜しくない状態になろうとも看過する事が可能なのである。
javascript が client side 専用 script 言語と言うことであれば、或いは DOM が client side 専用の 規格と言うことであれば、javascript だから或いはDOM だからと言うのが仕様上宜しくない状態になってしまった HTML を看過する十分条件となるのだが、別に javascript や DOM は client side 専用と言う訳ではない。
と言いつつ、ろばQとしては server side で動いている javascript を1例しか知らないので (しかもその1例は拙作だったりする) 一般的に javascript と言えば client side script じゃん、と言われればまぁ、そうだよね、とは思う。……でも、DOM は余りにも関係ないんじゃなかろうか (javascript で言う所の write メソッドを使うよりも DOM で追加した方が code が綺麗だと言われればそうだが、それも結局 servar side で行われるなら閲覧者には関係がない)。
仕様上宜しくない状態になろうとも看過する事が可能なのか
IRC にて IWAI さん (参考: IWAI さんの web site) から、javascript は必ずしも client side とは限らないし、DOM は更に関係ないが 18.2.4 Dynamic modification of documents を知らずに書いているように読める、とのご指摘を頂いたので補足。
ろばQの主張は飽くまで (client side での HTML への変更なら) 仕様上宜しくない状態になろうとも看過する事が可能
であり、DTD や仕様に反しても問題ないと言う訳ではありません。
また、何故看過する事が可能
かと言えば、例え script などにより問題が起ころうとも client 側での処理の結果であれば、閲覧者が (再読み込みして) その処理を実行しない事により、問題発生前の HTML を取得できる事が十分期待できるからであり、その様な意図であろう発言であるにも関わらずjavascript だから HTML は汚れないとか、DOM を使うなら許容できると言った記述があったので駄突っ込みを
した次第です。
なお、例えば HTML 4.01 の p 要素に、子要素として div 要素を追加 (DTD 違反) しようとした場合、UA は error 処理して、挿入された div の開始 tag の前に p の終了 tag を補い、div 要素挿入前から存在した p の終了 tag を無かった事にして、結果 <p></p><div></div> (本来 p の内容だった筈の文字列) と言う (恐らく div 要素を挿入するよう指示した者の意図とは別の) HTML の断片として再解釈を行うかも知れません。
18.2.4 Dynamic modification of documents にHTML documents are constrained to conform to the HTML DTD both before and after processing any SCRIPT elements.
の1文が有ろうが無かろうが、UA が解釈する HTML は (一連の処理の実行途中であっても) 常に妥当な HTML でなければ成らないのは言うまでも有りません。
document.getElementsByClassName = function(klass) { var all = document.getElementsByTagName("*"); var ar = []; for (var i = 0; i < all.length; i++) { if (all[i].className == klass) ar.push(all[i]); } return ar; };NodeListの
lengthアトリビュートに全要素の数だけアクセスするのは何の為? ものすごく多くのDOMユーザーに言いたいことだけど、NodeListは生きているよ。lengthはDOMツリーの操作に対応して変化可能だということ。
appendChild などにより変更を行うと length の値も変わる事は知っている筈なのに、それが何を意味するかちゃんと解かっていないから for(var i = 0; i < document.getElementsByTagName("*").length; i++) なんて書いたりする (ろばQが)。
DOM に限らず、1度だけ参照してその値をリテラルとして保持すれば良い値を毎度毎度参照するなんてお馬鹿も良いところな訳で……何をやっているかなぁ……偉そうに他人に突っ込みを入れている場合では全く有りません。
取り合えず拙作 code を色々見直し中。
Node.hasChildNodes() の意義 (2003-11-05 の Past topics)length プロパティは負荷の高い処理 (かも知れない) と言う記事。