WEBドキュメントのディスプレイサイズは、制約がありますので、デジカメなどで撮影した画像を、そのままのサイズで、ｈｔmlに埋め込むような場合には、制約が出ます。
PDFという選択肢もありますが、画像一枚の表示のために、PDFを起動させて閲覧してもらうというのも、制作側の気持ちから言えば、「申し訳ない」ということになります。
soomifyは大きな画像をスライスして、ズームしたりパンしたりすることが簡単に実現できるｓｗｆファイルです。
画像を制限された領域に配置して、軽く動作します
画像にズーム機能やドラッグ機能を与える例大きな変更があるとアナウンスされていたWordPress3.0を試してみました。
インストールと、テキストの入力などの基本操作を試してみましたが、MU（マルチユーザタイプ）との統合という大きな変革を乗り越え、私たちユーザに大きなメリットを与えてくれそうです。
ベータ版のため概観/メニューなどが、未完成な状態であったり、default テーマが含まれないために、テンプレートの補完機能（テンプレートヒエラルキ)に問題があるように見えてしまったりということはありましたが、大きな問題とは思えませんでした。
最も印象に残った点は、やはり、クラスアトリビュートの動的な配置です。
htmlという文書は、エレメント と 属性からなる いわゆるタグで、テキストの役割が何なのかを示しています。
この属性が、プログラムから動的に配置される場合に、最も、発生しがちな問題は、ブラウザから見たときの、表示の乱れです
ベータ版wordPressによる自動的なクラスの出力は以下のようになります。
<div id="post-117" class="post-117 post type-post hentry category-8"> ......</div>
このような属性が与えられた場合のテーマファイルのコーディングを想像してみます
このマルチクラス指定の優先順は、スタイルシートの指定順に影響を受けます。（クラス属性の順番ではありません）
つまり、部分的なスタイル指定であればあるほど、スタイルシートの末尾に追加していけば、いい。全体に影響するものほど、スタイルシートのはじめに書けばいいということになります。
しかし、スタイルシートのどこかで、div.post-91{color:red;}という風に詳細度を上げた指定をしてしまえば、.post だろうが.post-117だろうが、div.post-91の指定が優先します。
エラーを無視するスタイルシートで、高度なスタイル指定は、簡単ではありません
また、今のところ、ベータ版のクラス属性の指定は、テンプレート上では、 post_class(); によって、class="hoge hoga" と echoします。
このことは、自分たちは、クラス属性をテンプレート上で追加できないということを意味します。タグには、クラス属性を複数かけないからです。
（※ワードプレス関数を使うことで属性値を変更することはできます。が、テンプレートコーディング作業では、できない方向にあるという意味です。）
ただ、いずれもwordPressというより、テーマファイルの問題で、たいした問題ではなく 全体としては、とても魅力的でした。
ベータ版を試してみただけなので、アップグレードする時にはいろんな工夫が追加されていることでしょう。
wordPressは、バージョン3で マルチユーザwordpress と 通常のwordPressの統合が行われるなど、大きな変更があるようです。
このため、特にこれまではβ版からのテストは行ってこなかったのですが、行ってみることにしました。
バージョン3については、wp3 | Information on WordPress themes that www.tenman.info create and manages. を利用して感触を試すことにします。このサイトでは、できるだけ、CSS3のテクニックも取り入れた表現をためします。
OAuthに対応した。Twitter入力フォームを公開します。
桃の木利用方法、Twitterにログインした上で、上記のページにアクセスしてください。画面左上の、Approve(oauth)リンクをクリックすると、
左画像が表示されますから、承認してください。
承認すると、最初にアクセスしたページに遷移します。
テキストエリアに、文章を記述すると自分のTwitterに反映します。
3月末までの目標でイベントリストのリニューアルを行うことにしていました。
イベント仕組み面でいうと、従来は、イベント情報を配列に入れて、Ajaxでロードするという仕組みのものでしたが、開催日などを手書き修正する必要があり、約2年ほどの運営の中で、効率の悪い部分になっていました。
また、蓄積していくイベント配列の再利用の方法についても、使いにくさを感じていました。
Ajax で CSVを処理する方法等も、みてとても便利だと思いましたが、結局データベースにイベント情報を蓄積していく方向で「よい」という事にしました。
最初の情報が、例えば、必ず正確な住所情報が入っているわけではないので、そのあたりをどこまでやるかとか、文中から、住所を抜き出すのにどうすればいいのか、などなど想定していない事がいろいろありましたが、とりあえず結果を出して、想定どおりの動作に気なるのか、見定めなければなりません。
こっちのほうが、ずっと大変な作業です。
何かをやろうとすると、たいていいくつかの方法があります。
やり始める前に、どの方法を使っていこうとするのかとか、やり終わった後に、これはちゃんと動くんだろうかと、検証することは、地味で負担の多い作業です。
プログラムを作ることは、間違っていれば、エラーを出してくれるので、そんなに難しいことではありません。
本当に難しいのは、それが使いやすいものになって、手放せないと思ってもらうために、何ができるか、なんだろうと思いますが、つらい作業です。
htmlは、記述方法であり、phpや、javascript、などを使った出力の結果であることもあり、WEBの根本的な仕組みです。
htmlに関わるスタイルシートや、スクリプト、サーバ機能などによって、大きく姿を変えることもありますが、内容は、その文書構造の中にあります
しかし、ここ数年WEBは、その姿を大きく変えつつあります。（と、私は感じています)
そのひとつは、Ajaxです
Ajaxは、htmlドキュメントに、「状態」を作り出しました。あるイベントにより、外部ファイルを動的にロードしたりすることができるようになりました。
意味的に透明な、divやspanが、Ajaxイベントの処理に使われたりしています。
また、クラス表現も マルチクラス指定ができるようになって、非常に複雑でダイナミックな作業ができるようになっています
これらの進化は、htmlの文書構造を表現するエレメントの価値が薄れさせているように私には見えます
htmlは、潮目を迎えているのかもしれません
ｈｔｍｌは、地味で、シンプルなもので CSSやjavascript サーバテクノロジやサーバサイドスクリプトなどと比べると、それ自体に興味を持つ人は、少ないかもしれません
しかし、ハイパテキストがなければ、WEBは成立しません。
それぞれが、どんなテクノロジを選択し、実際のドキュメントに適用していくかということは、WEBの進化に影響を与えていくだろうと思います。
webサイトの構成変更のため投稿を移動しました。
例えば、今月は、何キロ歩いたとか、数字をメモしておこうと散歩に行くたびに思ったりします。
でも、散歩が終わるころには、そんな事忘れて、とっとと帰ってきます。
散歩に行くのに、ノートと紙持って出かけないし、携帯から自分宛にメールというのも、散歩に似つかわしくない。
とにかくとっとと、紙とペンでメモするより簡単な方法を考えていました。
携帯は、常に電源が入っているので、自分なりに作ってみました。
自分の気になる事を、タグにしておいて、数字を入力（してもしなくてもいい）で、気になる数字を保存しておける。
気が向いたら、エクセルでダウンロードして、まとめれば、
「なるほどな」と、把握できる シンプルなWEBサービスです。
webサイトの構成変更に伴い投稿を移動しました。
実体参照文字を入力してもらうのが、過酷だと思われるときには、必要になるかもしれません。
windowsでapache +php なら、htmltidyを使うのが最も簡単でインストールも特別なスキルを必要としません。
タグ以外の><をエスケープしてタグはそのままにしておく。
しかし、レンタルサーバなどの場合、htmltidyがインストールされているとは限りませんし、windowsに比べてハードルは高くなる。
自力でやるとすれば、と思って作ってみました。
webサイトの構成変更に伴い投稿を移動しました。
PEAR HTML_CSSを学習する過程で、URLで、htmlとcssを指定して、スタイルをインラインスタイルとして埋め込むStyle mergeというプログラムを公開します。
スタイルマージスタイルの優先度は考慮されていません
原因は今のところわかりません。
coreserverでは、問題なくアップグレードできています。
このブログは、2.9.2にアップグレードしました。
Raindrops obandes