ホームページについての日記

2008年12月26日
CSS3のマルチカラムレイアウトって、便利なのでしょうか?
table要素やpre要素を使った場合上手く表示してくれない。
とくに、長文を書かない私が使った場合、妙に短い文章がカラムに表示されて見た目にもよくない。出力するための領域が決まっている媒体には必要だろうと思いますが、 私の場合は必要ないと感じた。
グリッドレイアウトは面白いと思う。positionやfloatでのレイアウトは、いろいろと難しい。グリッドレイアウトの概念で、作れればいまよりも面白いデザインのWebページが作れると思います。
そうなると、HTMLが現在の意味マークアップでは、いろいろ不具合がでると思います。HTMLが意味マークアップではなく、Webアプリケーションマークアップにならないといけないのかなぁ、と思ったりして。
現状の意味マークアップの進化した形がWebアプリケーションマークアップではなく、現状の意味マークアップを参考にした別のマークアップでなくてはならないと考えます。 レイアウトや機能を重視したマークアップという概念のマークアップの仕様が必要になるのでしょう。
現状の意味マークアップは、素晴らしいと思います。誰でも情報が取得できるWebこれは大切だと思います。 もし、誰でも情報が取得できるWebの概念が無くなってしまったら、とても残念なことだと思います。
2008年12月24日
img要素のwidth属性とheight属性はあったほうがいいのかなくてよいのか。なんか立場で変わってしまう。
img要素をappendChildした場合の挙動を調べてみた。
  1. width属性の値がないと、offsetWidthの値は画像なしの値を取得します。
  2. 画像を読み込むと、画像を取り込んだ後のoffsetWidthの値を取得します。
appendChildした直後とimg要素で画像の読みが終了した後では、取得できる値が違ってきます。
動的にimg要素を作って画像の、場所や大きさで挙動を変える場合は、不都合を生じます。
width属性がある場合は
  1. offsetwidth属性は、width属性の値がセットされる。
  2. 画像の大きさに関係なく、width属性の値の大きさの画像が表示される。
実際にimg要素を含む要素をappendChildして不具合が出て困って調べたので、width属性とheight属性はあったほうがよろしいと感じます。
まぁ、やりたいことは以下の通りです。
  1. mouseoverイベントにより、a要素のhref属性のxmlをxmlHttpRequestで読み込む。
  2. 読み込んだxmlデータをXSLTProcessorを使い、XSLTでHTMLに変換する。
  3. xmlはimg要素に変換されてhtmlにappendChildされる。
  4. appendChildされた結果、横スクロールが出る場合、画像の出力位置を左にずらす。
appendChildしたimg要素のoffsetwidthを取得すると、画像を読み込む前の値を取得してしまい横スクロールがでるのか判定できない。
body要素のoffsetwidth - イベントの発生した要素のoffsetleft - 表示領域のoffsetwidth の値がマイナスであれば、横スクロールがでるので、 マイナスの値だけ出力位置を左にずらせばよいわけです。
ところが、img要素をappendChildしたときに、width属性がない場合、画像の読み込みが終了するまでoffsetwidthの値は取得しても画像なしのoffsetwidthの値で取得してしまい、 右にはみ出る大きさが算出できないことになる。
それを避けるためには、xmlをXSLTProcessorを使ってHTMLに変換するときにwidth属性があるimg要素を作らないと、上手く処理が出来なくなってしまう。(画像の大きさは常に一定ではないので)
scriptで処理をする場合、img要素やobject要素にwidth属性やhight属性があることは悪いことではないと思います。
まぁデザイン的になくても問題ないというのなら、必要ないのですけど。
「width属性やhight属性は見た目なのだから、CSSで指定すべきである」と言う人もいるでしょう。画像サイズが同じならよいのですが、画像のいらない部分があったら編集して必要な部分のみを切り出した場合、 必ずしも同じ画像サイズにならないと思います。
その場合、画像のサイズ分だけの、classセレクタを作ることになると思うのですが、意味の無い名前で大量にclassを作ることがCSSなのでしょうか。 style属性を使うくらいなら、width属性を使ったほうがわかりやすいので、style属性もつかいづらい。
scriptで要素をいじくる場合はメタ情報として、width属性やhight属性があったほうが良い。デザインであれば、画像サイズごとにCSSの指定はナンセンスなので指定しないでよろしい。ってことになる。
あったほうが良い場合と無いほうが良い場合がある。ケースバイケースで考えましょう。メタ情報が全ていけないのであれば、blockquote要素のcite属性や中心属性のtitle属性もダメだと思います。
2008年12月22日
xmlHttpRequestとXSLTProcessorを使ってxmlデータをxsltでHTMLに変換して、apeendChildして画像を表示しているのだけど、mouseoverイベントで画像のサムネイルをCSSの半透明にする指定を使って、 ゆっくりと表示するように作ってみた。結果だけいうとOperaは上手くいく。
処理の流れは次のようになる。
  1. mouseoverイベントにより、a要素のhref属性のxmlをxmlHttpRequest読み込む。
  2. 読み込んだxmlデータをXSLTProcessorを使い、XSLTでHTMLに変換する。
  3. img要素に変換されてhtmlにappendChildされる。
  4. CSSの半透明にする指定を、10段階で、透明→不透明に変化させる。
その間に、XMLを変換するための通信とimgを読み込む通信2回行うのだがその通信が原因で処理が上手くいってないのか試してみた。(img要素は非同期で画像データを読み込むため。)
appendChildした後に、alertで処理を止めて画像を読み込む時間を作ってから、CSSの半透明にする処理を動かしてみる。上手くいかない。
初期値で透明にする処理をしている部分を止めてやってみる。上手くいかない。
透明→不透明にする処理をalertを入れてとめてみる。上手く行く
メモリーにしかない要素に対して透明→不透明の処理が上手くいってないようです。Firefoxのバグかどうか不明。書いてあるHTMLでないと処理が上手く適応できないのは、Firefoxでは良くあることなので、 そのうちできるようになると思う。
一連の処理でなく、画像の読み込みと表示を別のイベントとして発行すれば出来ると思うのだが、考えるのが難しくて面倒なのでこれで終了です。
2008年12月19日
Firefoxのリンクを辿るTABkeyやclickイベントを発生させるEnterKeyゃーや矢印keyはKEYeventの対象外にしたほうが良いと思う。
いわゆる特殊キーの扱いになるので、そのkeyにまでeventを発生させるのは、アクセシビリティ的に悪いと思う。 リンクを辿るキーやクリックするキーはkeyEventObjectの対象外にしたほうが操作しやすい。
体が不自由なfirefox利用者が、「リンクはタブで辿れる」のでタブキーでリンクを辿って、「clickはEnterキーで出来る」ので、clickする代わりに、Enterを押して、閲覧したとします。
ところが、TABにKeyEventを貼り付けた場合、リンクを辿れないってことが起こる可能性がある。
EnterキーにKeyEventを貼り付けた場合、clickできなくなる可能性がある。
WAIWCAG2.0には、 「コンテンツの全機能を、キーボードで操作可能にする」という項目があります。特殊キーは、KeyEventとClickEventを同時に指定した場合、両方のEventがちゃんと機能しなくてはならないはずです。 そうでない場合は、デフォルトで設定されているEventを生かし、追加されたEventは無視するようになってなければ、利用者、製作者共にこまります。
特殊キーの扱いは、コンテンツ製作者のアクセシビリティ配慮ではなく、ブラウザ製作者のアクセシビリティへの配慮の部分だと感じます。
W3Cの仕様に準じるというのなら、WAIの仕様にも準じなさい。Firefoxには、WAIの仕様に準じる姿勢が見られません。
この文書を書いていて、「リンクを辿る」や「クリックする」以外のキーイベントは、コンテンツ作成者が気を利かせなければならないよなぁ。と気がついた。
Shift(16),Ctrl(17),Alt(18),Tab(9),Esc(27),Enter(13),←左矢印(37),↑上矢印(38),→右矢印(39),↓下矢印(40),+加算(43),-減算(45),のkeyCodeは、表示処理をしないでScriptを終了するように修正。
TabやEnterをわざと抜こうかなぁと思ったのだけれど、どうせ直すのならと思っていれました。矢印、加算、減算はOperaがこのKEYでブラウザを操作するために抜くことにしました。
Operaはリンクを辿るとき、Shift+矢印keyでリンクを辿ります。画面構成を上手く作ってやると、個数が制限されているaccesskey属性を使うよりも、はるかに簡単に目的のリンクにたどり着けます。
読み上げブラウザ用にaccesskey属性を残す配慮をすれば、より良いものを作ることができると思います。
Operaは加算、減算keyで文字の大きさを変えることが出来ます。その際画像がでると良くないのでこれも抜くことにしました。
keyイベントからTab(9)やEnter(13)を抜くことによって、Firefoxでclickイベントが動くようになったので、まぁWCAG2.0の項目は満足できるようになりました。
2008年12月18日
CSS3のopacityという指定を使ってみた。2008年7月WDが出ているCSS3のプロパティです。
IEでもFirefoxでも独自拡張という形でCSSが指定できるのだが、CSS3で正式にopacityが定義される予定なので、使ってみました。
結果、Opera以外、意図通りに動きませんでした。
IE。opacity自体をしらないのでまったく動かない。Keydownイベントをしていしている場所に行くと、それ以降のリンクがたどれなくなる。
Firefox。上手く表示できてない。0→1になっているように見える。実際は処理をしているようです。Keydownイベントをしていしている場所に行くと、それ以降のリンクがたどれなくなる。
keyイベントがある要素以降のリンクを辿れなくなるのは、致命的なバグだと思います。
その点Operaは優秀です。Operaなら、accesskey属性はあまり使わないので削除されても、大して困らないが、それ以外のブラウザのキーボードインターフェイスはお粗末です。
ブラウザのレンダリングやスクリプトだけでなく、Firefoxには操作性の改善もお願いします。
2008年12月16日
楽天ad4Uという名のスパイウェアみたいな挙動をするサービスが提供された。
ブラウザの履歴情報を盗み見て、広告を表示するサービスだそうだ。
しかも、バグを利用して実現しているらしい。
特許申請中らしい。
前にも書いたが、この手の(個人)情報金になる。
金にする術を見つけた企業は儲かるわけだ。Googleはまだ、ギブ アンド テイクだけど、楽天ad4Uは搾取するだけです。
履歴情報はあまり使わないので、多少表示は遅くなるが一切履歴を残さないように設定を変更する。履歴が残らなければこのサービスは効果ないはずです。
なんていやらしいサービスなのでしょう。
こんな文書を見つけた。楽天infoseek 楽天ad4U 2009年1月03月のご案内って広告主を集っている文書みたいです。

※尚、クッキーを使用せず個人情報は一切取得、保存、蓄積しないため、
 個人情報保護に関する問題等は御座いません。
日本国の法律では「個人情報」ではありません。しかし、履歴などの情報は、「個人情報」だと思っている人は多いのです。
法律が個人の価値観に追いついていない現状の穴をついて、こんなサービスを展開して企業の倫理が問われると思います。
このサービスを利用して宣伝しようと思っている企業も、個人情報保護の法律に触れないだけで、不快感をもつ個人が結構いることを覚えておいてください。
ブラウザ製作者が修正しようとして、なかなか修正できていない脆弱性を利用して、法律に触れないように情報を取得して商売することが、倫理的によろしいのでしょうか
私はよろしくないと思います。
この機能は、リンク済みのスタイルを他のスタイルと変えることで、利用者が該当リンクをクリックしたことがあるのか明確にすることができる機能です。
従ってこの機能を限定することは「アクセシビリティ」「ユーザビリティ」を限定することになり、よろしくない。
「アクセシビリティ」「ユーザビリティ」を考えて作られた仕様を、「自分の利益」のために使うのは良いことなのか?
パーソナルデータは個人情報です。リンク済みのデータの保持はブラウザの利用者のためのものです。
「楽天ad4U」開発社のコンプライアンスは法律を守るとしか明記されてないのでしょうね。もしかしたら、コンプライアンスもしらないダメ企業かもしれない。
2008年12月10日
「Mozilla Firefox 3.1 Beta 2」が出た。期待を込めて使ってみたが、1箇所だけダメだった。
XMLをXSLTで変換した場合、ちゃんとFLASHの再生をするのに、JavaScriptをかますと再生しない。object要素の代替テキストを認識する。
「なんとなく趣味のページ」を全てちゃんと表示してくれるブラウザはいつになったら登場するのでしょうか?
なんとなく釣りのページで、全てのチェックができます。
アクセスしてメニューが出力されれば、JavaScriptでxmlをxsltで変換して、appendChild出来てます。
アクセスして、リンクが【文字】のような色をしていれば、CSSの属性セレクタが使えてます。
「メニュー表示」の文字列の後ろに(a)のような文字が見えていれば、after擬似要素が使えてます。
また、余計な「ボーダー」が見えている場合、隣接セレクタが上手く使えてない状態です。
「魚の観察」から、「アイナメの観察」クリックすると、アイナメの観察が表示されます。
ブラウザの右上、タイトルを表示している部分が、「なんとなく釣りのページ-【アイナメの観察】」に変更されなくてはいけません。
フィード情報も、「アイナメの観察」に変更しているので、「アイナメの観察」を表示しなくてはなりません。
【エグレから飛び出したアイナメ】のリンクをクリックすると、FLASHの再生するOBJECT要素をJavaScriptでxmlをxsltで変換してappendChildして、FLASHが再生されます。
画面下のほう、「仕掛け」の欄のヘチ沿いを狙うに、SVGが表示されます。
SVGはJavaScriptで、赤い楕円形をクリックすると、画像の中に簡単な説明が表示されます。
これらを全てクリアするブラウザは、まだ存在しません。はやく出てきてくれないかなぁ。
2008年12月5日
Opera10のアルファ版がでた。「Acid3」で、100/100だしたというわりに、大いに期待はずれ
xmlhttpRequestでXSLTを使いDOM変換してHTMLにappendchildするのだが動かない。
svgのJavaScriptも動きません。
9.5の時も、appendchildしたときにJavaScriptの挙動が同じように不安定になったような気がする。
本当にアルファ版です。インストールすることは強くお勧めしません。
2008年12月3日
アクセシビリティをチェックするソフトを見つけた。富士通が作っているのだが、「使用するのはいいが、結果は公表するな」というソフトらしい。
一つの点を除いて納得できる。納得できないのは、定まった用語に対して必ず対策が必要だといわれることだ。
対策が必要だと言われたので、その用語を30分かけて調べてみたが、国の機関で正式に発表されている用語なので直しようがない。
JIS規格が悪いのか、環境省が悪いのか、富士通が悪いのかは知らんが、どうにかならないものですかね。
対策が必要でも、公式に採用されている名称は直しようがないです。アクセシビリティ対策のために名称を直してくれ。国。
2008年12月2日
いつのまにかSVGにCSSを外部ファイルで指定できるようになっていた。
よくよく調べてみると、JavaScriptも動くみたいです。
CSSとJavaScriptが動けば、ポイントをクリックすると説明が表示されたりする画像が作れる。
魚を釣る場合のポイントの説明を作ってみよう。
<?xml version="1.0" standalone="no"?>
<?xml-stylesheet href="../css/nesakana_point.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
        "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="350pt" height="150pt" viewBox="0 0 1800 900"
     xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
	<script type="text/javascript" xlink:href="../script/nesakana_point.js"></script>

	<rect class="sea" x="0" y="0" width="1600" height="900" />

	<ellipse class="check1" rx="40" ry="14" transform="translate(450  375)" onclick="text_disp(evt)"/>

</svg>
外部スタイルの適応は、普通にXMLのスタイルの適応のさせかたでします。SVGのCSSはSVG専用の記述もあるので、HTML用のCSSとはちょっと違います。
ScriptのリンクはXLinkを使います。XMLのリンクを規定した仕様です。
普通にSVGが作れれば、ScriptやCSSは普通のXMLを扱うのとほぼ同じなので、たいして難しくはない。
詳しくしりたければ、SVG 1.1 勧告 日本語版についてを参照のこと。 「6 スタイル付け」と「18 スクリプト」が該当します。
OperaではJavaScriptが動かない。スタイルの適応は可能なので図解には使えますが、クリックでの説明ができない。なんとかしてくれOpera。
2008年12月1日
メバルが3種に分かれたので、情報をsakana_data.xmlに反映させようと思ったら「現状の生き物の簡単な説明を記述するための語彙。」の造語だけでは、納得いくマークアップができない。
拡張したい内容は次の2点
まずは、学名と標準和名の由来の造語を定義する。名前に関することなので、rdf:resourceで別の主語ノードを子要素に持つことはしないで、あくまでも学名の構成要素の一つとしたい。
まず、Propertyとして、"originate"(由来)、"ScientificName"(学名の概略)、"NipponName"(標準和名の概略)を定義します。
そして"originate"にrdf:parseType="Resource"を持たせて、"ScientificName"(学名の概略)と"NipponName"(標準和名の概略)を属性Propertyとして記述すればようわけだ。
<fncm:TechnicalName rdf:about="urn:technicalname:Sebastes inermis Cuvier,1829" fncm:JapaneseName="アカメバル">
	<fncm:Classification>カサゴ目フサカサゴ科メバル属</fncm:Classification>
	<fncm:originate rdf:parseType="Resource">
		<fncm:ScientificName>Sebastesはギリシャ語で尊敬されるという意味。inermisはラテン語で武器を持たないを意味する。「尊敬する武装しない魚」という意味。</fncm:ScientificName>
		<fncm:NipponName>張り出した目が語源。アカメバルは2008年8月に「旧メバル」を3種類に分けられたうちの一種</fncm:NipponName>
	</fncm:originate>
</fncm:TechnicalName>
こう書けば、TechnicalNameの目的語として機能する訳だ。これで由来の部分は終了。
身体的特徴は、名前に関する要素ではないので、TechnicalNameの直接の子要素にはならない。従って別の主語ノードを子要素にするほうがわかりやすいと感じる。
ちょうど"Habit"(習性)という、クラスが定義してあるので、これの子要素としてしまえばよい。
"feature"(身体的特徴)というPropertyを定義、それを子要素にもたせる。あとはデータをマークアップすればよいわけだ。
sakana_dataのデータの、「名前」と「習性」と「捕まえ方」の関係は下記のような図になる訳です。
svgデータによる図の表示
「名前」のデータの子要素として、「習性」と「捕まえ方」が存在する形になってます。
データを作ったら、それを表示するものも直さなくてはならない。
XSLTで変換するので、関係あるXSLTを要素があったら出力するように直す。
写真データのXMLを変換したときに、付属データとして出力されていることを確認して終了。
これで、完了です。自分で語彙を作ってRDFを作ると拡張さえできれば自由に作れるので良いのではと思った。
語彙を考えるのは面倒くさいけど。
2008年11月26日
グーグルマップで「限定公開」とした場合は、マップのURLを家族や友人ら自分が決めた範囲の人とのみ共有することができる。と書いてあるけど、 データ自体は、公開される場所に存在しています。グーグル以外の検索エンジンに対して、「限定公開」のマップを検索対象からはずすよう要請中らしいですから。
ようするに、URLさえわかれば誰でも見れる場所にデータは存在しているということです。「限定公開」と言ってますが、実質は「無制限公開」です。
グーグルは、情報の共有を目的にこのサービスを始めたはずです。情報の共有を第一目的に作られたシステムに、非公開という紛らわしい表示の区分を作るから、 グーグルの想定外使い方をする人が出てくるわけで、グーグルが悪いといえば悪い。
グーグルは情報を売って稼いでいる会社だということを、使う人は頭に置いてサービスを使うようにしないといけない。営利目的の会社で、無料で便利なサービスなどあるわけがない。 グーグルの場合は、金の代わりに(個人)情報を提供させているのである。
グーグルは、情報を金に換える術をもっているとみて付き合うべきでしょう。
グーグルマップの件は、「サービスを理解できなかったかわいそうなユーザーが悪い」と思います。
自分だったら「グーグルに変な情報を提供してらたまらない。」と警戒して使わないです。
2008年11月25日
アクセスログとかいろいろ見ていると面白いことがわかる。
IE6を入れてる人が、休日23:00くらいに、株式会社NTTPCコミュニケーションズを使って、OPERA firefox3という検索ワードを入れている。乗り換え検討かなぁ。
IE7を入れてる人が、休日22:00くらいに、Softbank BB Corp.を使って、safari3.1.2という検索ワードを入れている。Safariって何?という感じでしょうか。
IE7を入れてる人が、平日19:00くらいに、日本テレコム株式会社を使って、javascript version opera9.5という検索ワードを入れている。ホームページ製作者がなんかの情報を求めてさまよっているのでしょうか。
Fx2を入れてる人が、休日12:00くらいに、XXXXXXXX株式会社から、safari3 XSLT XML 対応という検索ワードを入れている。ホームページ製作者が、SafariのXSLTについて調べているみたいです。
IE7を入れてる人が、平日15:00くらいに、株式会社嶺南ケーブルネットワークを使って、Opera9.6 FireFox3という検索ワードを入れている。両ブラウザの違いを調べているみたいです。
Opera9.6を入れてる人が、休日1:00くらいに、株式会社 インターリンクを使って、opera9.6 ベンチマークという検索ワードを入れている。性能を知りたいみたいです。
検索サービスをしている会社では、もっと雑多な情報を取得している訳だ。
こっから先は、ムシムシの邪推、妄想なのですが、こんなことが考えられると思います。
Google Chromeやツールバーなんかを入れている場合、インストール時やGoogleに初回アクセスした時にブラウザやツールバーにID番号を振っておくなんてことをすると、 「Axxxxx-xxx」を使っている人は、XXXXX株式会社に所属していて、XXXXな検索している。ということがわかります。
コード番号「Axxxxx-xxx」の個人的嗜好がまるわかりになります。
そんで、「Axxxxx-xxx」でGoogleのメールを使用してすると、「Axxxxx-xxx」は、Googleのメール「ユーザー名@gmail.com」という、情報を付加できてしまいます。
そんで、「Axxxxx-xxx」でグーグルマップを使うと、「Axxxxx-xxx」は日本のどこどこを検索していたという情報が付加されます。
そんで、グーグルデスクトップにも、「Axxxxx-xxx」という情報を付加してしまうと、グーグルデスクトップの送信した内容と付け合せが可能となります。
こうやって、個人の嗜好やら行動やらの情報が、どんどん蓄積されてしまうということが起きてしまうかもしれない。
しかも、これらは「個人情報」ではないので罰せられません。売買してもよいことになります。
実際にこんなことをやっていたら、物凄く富を得られると思います。
こんなこと、やってないですよね。グーグルさん。
同じようなことは、携帯端末やってる会社でも出来そうですね。
どっちにしろ、個人情報っぽいデータは高く売れそうだなぁ。と思います。
2008年11月14日
safari3.2が出ていた。
入れてみた。
やっぱり残念な結果だった。
残念でなくなる日はくるのでしょうか
Acid3よりも、JavaScriptでXSLTProcessor()のloadを動くようにしてくれ。
他のブラウザは動くんだぞ。
2008年11月13日
PHPの掲示板のサンプルを拾って、そっと設置したのですが変な人たちに見つけられて、ガンガン書き込まれている。
何故か、htmlspecialchars()でHTMLのタグのチェックをしているのだが、その書き込みはリンクが有効になってしまう。
PHPに詳しい人に、"<"を文字列変換してしまえばいいじゃないの、といわれて文字列変換してみる。
しかし、問題が解決しない。吐き出されたソースはtarget="_blank"が付いている。どうやらPHPソースの問題らしい。
問題箇所を発見しました。コメント内リンクを殺したつもりで、いつのまにか復活したみたいです。
あせりました。
それにしても、カキコが多いのでアドレスで制限をかけてみたのですが、それでも新しいアドレスで書き込まれるのでいちいち追加するのは面倒です。
取得したアドレスから国を引いてみると、日本国からの書き込みが皆無。みなさん外国です。
それでは、HTTP_ACCEPT_LANGUAGEを取得して、"ja"以外はページを表示しないように変更してみました。
OperaのXSLTのDocument関数
いろいろ調べている人がいるみたいです。その中にdocument関数がうまく機能していないようです。と書いてあった。
ファイルの位置をHTTP://~で書いてやると動きます。
for-each select=を失敗するときがあります。
XMLを変換するXSLTであれば、HTTP://~が理解できてれば良いのではないかと思います。
もともと、XMLはデータ交換フォーマットであり、データの位置はHTTP://~書くものだし、../なんて書くのはXMLでは妙ですしね。
XSLTでdocument()で../を使う場合は、内部で使う定数かなんかでしょう。別にhttp://で書いても支障はないと思うんだけど。
それよりも、名前空間も使わないXMLをXSLTで変換することに何の意味があるのだ?
RDFの語彙を使ってXMLを作って人に見せるためにXSLTを使うならわかるが、自分しか要素の意味がわからない自分勝手のXMLをわざわざXSLTで変換って、 「自分XMLわかるんだぞ」って誇示したいだけじゃん。
本当にXMLがわかるのなら、二次利用されることも考えろよな。
意味の無いXML-XSLT変換するなら、HTML4で書かれたほうが二次利用されやすい。
二次利用されたくないなら、Webの公開をしなければよい。
2008年10月30日
ボジョレ・ヌーボーのペットボトル登場するらしいです。
「ボワセ米国法人の広報担当者は、ペットボトルがワインの味を損ねることはないとしている。」らしいのですが、本当にないのでしょうか?
ペットボトルは、わずかな気体透過性がある。そのため、長期間保存した場合、内容物が酸化することがあるらしい。
ダイヤモンド・ライク・カーボンでコーティングする方法で酸化は防げるらしい。
まぁ、ボジョレ・ヌーボーで酸化うんぬん問題視する人はいないと思うが……
html5で「なんとなく趣味のページ」をマークアップの試行をしてみた。
<div id="load_d">
	<header>
		<h1>釣りに関係するページ</h1>
	</header>
	<div id="mokuji1">
		<h2>釣行記</h2>
		<nav>
			<ol>
				<li>1999年の釣行記</li>
				<li>2000年の釣行記</li>
			</ol>
			<h2>著作権情報</h2>
		</nav>
	</div>
	<div id="meisai">
		<div>
			<h2>ムシムシの釣り情報です。</h2>
			<nav>
				<dl><dt></dt><dd></dd></dl>
			</nav>
		</div>
		<div>
			<h2><tile>10月23日</time> 貞山堀南蒲生</h2>
			<section>
				<p></p>
			</section>
		</div>
	</div>
</div>
構造を表す部分をマークアップしなおしてみたのだが、ちょっと悩ましい。
こんなことをわざわざ明示する必要があるのだろうか?html4は文書を書くうえでシンプルでよい仕様だと思います。 navやsectionなど文章を書くうえでわずらわしいだけだと思います。大抵のhtmlを書くひとは、そんなことを気にしてないとおもうし。
video要素等は、きちんと対応されれば良いなと思います。object要素のように対応具合がブラウザでまちまちすぎると使えません。
これらの要素追加されたhtml5が主流になるのかは疑問が残る。html4に不便を感じているコアなユーザー以外、移行しないかもしれない。
html5に積極的なのが、FirefoxやOperaだということも気になる。自分たちのブラウザの宣伝の為だけにhtml5を使っているようにも見える。
実際にhtml5がユーザーに向いているのか疑問だ。
2008年10月22日
ポメラ欲しいです。
仕事中はパソコンはついているが仕事中だからネタ書けないし、家ではネタを思いついてもパソコンをつけるのが面倒で書かないし。
大抵は脳内メモをしているのだが忘れる。これなら気軽につかえるなぁ。
このくらい手軽だといいと思います。「なんとく趣味」は一つ一つのネタがメモなのでちょうどいい感じです。
大体、一つの話題を15分程度で書くので電車の中でも書けそうだし。
というわけで欲しいものリストに入れておこう。
2008年10月21日
いい加減にOpera9.5からXSLTのdocument()に対応しているのだからそう書けばいいのに
これに対応するだけで、出来ることが大幅に増えるのだから。重宝してます。
最近、このページがgoogleにキャッシュされたらしくたまに「お客様」がくる。
アクセスログはXMLHttpRequestをgetでPHPと通信していたので、JavaScriptから値を送るのが面倒だったので、postに直した。
JavaScriptでリファラを獲ってPHPに渡すのですが、googleはurlに検索ワードを付けているので、なにで検索されているのかわかるようになった。
マイナーなブラウザとJavaScriptのxml技術の組み合わせの検索できているようです。
ここには、具体的な情報はないですよ。
「なんとなく趣味のページ」はJavaScript+xslt+xmlで構成されたページですけど、こちらではやってません。
2008年10月17日
Opera9.6が出ていた。チェックするのをすっかり忘れていた。
大体いい感じである。「なんとなく趣味のページ」は見れている。
object要素で動画も展開出来てるし、svgもつかえるみたいです。
フィードにOperaが独自のスタイルを適応させている。あれ迷惑ですよ。
せっかくxsltスタイルシートをつけているのに無視するのだからたまらないですよ。
xml-stylesheetが付いているxmlは常にxml-stylesheetの指定を優先させればよいのに。出来ないことないだろまったく。
カナヘビの画像なんかはRSS1.0にfoafで画像データをつけて作ってある。 そのデータをxsltでhtmlに変換して表示するように作ってあるのだが、まったく生きてこない。
ユーザースタイルがある場合はユーザースタイルを優先させろ。
2008年9月9日
IE Testerなるものを入れてみた。IE8 beta2 IE7 IE6 IE5.5のレンダリングをチェックできるソフトである。
IE8でAcid2のテストをしてみるといい感じである。CSSはほぼ満足できるのではないでしょうか
IE8でAcid3のテストをしてみた12/100だった。
これが、どのくらいの成績なのかと申しますと、Safari3.1.2は75/100。Chromeは79/100。Firefox3.0.1は71/100。Opera9.6は84/100。
まぁこんなもんだ。現行のブラウザ2008年9月現在、Acid2のテストをクリアしてない有名なブラウザはIEのみです。
おーいIE、かなり遅れているぞ。どうにかしてくれ。JavaScriptをieに対応させるの面倒なんだ。
2008年9月5日
Google ChromeはWebKit 525.13を使っていて、これはファイルを勝手にダウンロードする脆弱性があるバージョンだそうだ。
ちなみにsafariでは、525.21にバージョンアップされており、なんでこんな古いバージョンのエンジンで作るかなぁ。
JavaScriptのベンチマークをしてみた。
WebKitを作っている団体のベンチマークを試してみると、Opera9.6を1とした場合、Firefox3.0.1は約1.5倍速い。Safari3.1.2は1.2倍速い。Chromeは2.9倍速いという結果がでた。 速いっすねChrome。さすがV8エンジン。
OpenSpaceってとこで作っているベンチマークを試してみた。Opera9.6を1とした場合、Firefox3.0.1は約0.6倍速い。Safari3.1.2は0.4倍速い。Chromeは0.3倍速いという結果がでた。 速いっすねChrome。さすがV8エンジン。
WebKitを作っている団体のベンチマークで速い結果がでるようにしか作ってないんでしょう。もうすこし非標準に目むけないとダメだろ。
記事を見て思った。「Google Chromeはまだベータ版だから……」なんて書いてあることがある。
普通「ベータ版」なら扱いが違うだろ。Firefoxにしたって、Operaにしたって、あまりニュースにならない。
いろいろ記事見て「正式版」だと思ってましいました。
ついでに、ChromeのScriptの致命的にダメなところ。
XSLTProcessor()使ったときに、loadメゾットがないから使えない。
atom:content要素でtype="xhtml"指定している場合に、atom:content要素の子要素のdiv要素の子孫を全て取り出して、divについているxmlns属性を取り除いたDOMオブジェクトをappendChildできない。
head要素のtitle要素を後からJavaScriptで変更しても、ブラウザの表示に反映しない。(Firefoxもです。)
rel="alternate"属性をもつlink要素のhref属性をJavaScriptで変更しても、ブラウザに反映されない。(firefoxではライブブックマークは反映しない。)
ちなみに、Operaでは全部反映させてくれます。
細かいところに手が届かないのに、スピードだけアップされてもねぇ。
2008年9月4日
PHPでRSS1.0や天気予報のXMLデータを取得して、HTML上に書き出すPHPを作ってみた。
いまだにXMLへのデータアクセスの仕方がよくわからない。まだまだ勉強でしょう。
XMLHttpRequestは無事にpostできるようになりました。解説がいっぱいあるのに良くわからないのは、経験不足なのでしょう。
Opera9.6を入れてみた。不安定になるときもあるが、ダウンロードサイズが6MBくらいになっていた。
Operaのパターンなので最終的にどうなるのか不明。
フィードにOperaが独自のスタイルを適応させてきた。迷惑なのでやめて欲しい。
XMLも独自のスタイルがあるのなら、そちらを優先させるべきだろう開発者達。
rss1.0をRDFの語彙で独自拡張して色々表示につかっている私にとっては、迷惑なだけである。
2008年9月3日
Google Chromeをさっそく入れてみた。
閲覧につかうのならばいい感じではないでしょうか。
safariよりはかなり使いやすい感じをうけます。
しかし、loadメゾットがないのは困りものだ。早くどうにかしてもらいたいものだ。
中途半端な実装ならしないほうがまだマシだ。
2008年9月2日
googleがWebKitのエンジンを採用した独自ブラウザを発表するそうだ。
私はieと同じくらいWebKitが嫌いだ。理由は唯一つXSLTProcessor()に変わる機能がないからである。
はっきり言って迷惑なのである。そんなブラウザ。
まともにDOMを実装していないieと同じくらい迷惑なのである。
なくなればいいブラウザNO1なのである。
最速NO1って宣伝するなら、他のブラウザが実装している機能をきちんと実装して欲しいです。
2008年8月29
XMLHttprequestを使ってPHPを呼び出して、アクセスログの最新25件を出力するスクリプトを作ってみた。
XMLHttpRequestをgetでopenしているのが気になるが、まぁ初めてだからなんでも試してみよう。
しかし、いろいろできるよなぁ。
アクセスログを見てみた。
「なんとなく趣味」じゃない場所から来ている人がいる。適当に作ったログなので適当な情報しかとれてない。
「なんとなく趣味」から流れてきている人もいるっぽい。
2008年8月28
なんとなく趣味のページ別館を作った。
こっちはPHPが使えるのでそっち関係と動画をアップしようかなぁ。と思う。
「なんとなく趣味のページ」で扱えない話題をこっちに書いてしまおうとという目論見です。
最近PHPなるものコードを書いている。いろいろサンプルがいっぱいあって楽しい。
XMLHttpRequesを使ってPHPで簡単なアクセスログを盗るスクリプトを作ってみたのけれど、なんか楽しい。
もっと早くやってたらなぁ。なんかできることが結構ありそうで楽しみです。