フラッシュ版と同時に用意する代替ページ、いわゆる「HTML版はこちら」がありますが、何気に微妙な存在ですよねあれ。
結論
全flash等によるリッチコンテンツの代替ページは、極めてシンプルなものの方がバランスが良い。
多様なレアケースに備えた、jsもcssファイルさえもない、極力シンプルなページ。プレスリリースのFAXのような。
いっそフィードでも。
そもそもマークアップは必要なのか
トラックバック URL :
フラッシュ版と同時に用意する代替ページ、いわゆる「HTML版はこちら」がありますが、何気に微妙な存在ですよねあれ。
全flash等によるリッチコンテンツの代替ページは、極めてシンプルなものの方がバランスが良い。
多様なレアケースに備えた、jsもcssファイルさえもない、極力シンプルなページ。プレスリリースのFAXのような。
いっそフィードでも。
トラックバック URL :
HTMLファイル————-
<div class=”xxx yyy”>xxx yyy</div>
cssファイル————-
.xxx.yyy { 中身 }
こういうクラス指定をした場合、IE6だと
[.ここ].yyy { 中身 }
が無視される(;・ ω ・ )盲点じゃ~
仕事上の事だけど、カテゴリは「blog製作記録」のが良いかな。
トラックバック URL :
はてなブックマークからのリストは
はてブ アマゾン抽出→yahoo! pipesで整形→wordpressで解決。今度は、本文中からのリンクを便利にしたくなってまいりました。
しかし、これ、 amazon.comです(ノ∀`)
$request="http://ecs.amazonaws.com/onca/xml?Service=AWSECommerceService";
良く分かりませんが、上記を以下のように書き換えたらamazon.jpで動いてくれている気がします(・ω・)
$request="http://ecs.amazonaws.jp/onca/xml?Service=AWSECommerceService";
トラックバック URL :
サイトの規模が大きくなればなるほど、共通パーツの指定に絶対パス表記を用いる事で事故が減ります。さまざまな階層で使われる「共通テンプレ」に於いて階層を意識しなくて良い絶対指定は非常に有効です。
また、細かい所では、javascript内のパス表記。jsファイルは自身の位置ではなく呼び出したファイルの位置が基準となるので、共通js内での表記は絶対指定したい場合も少なくありません。
でもねぇ、地味に面倒くさいんですよね。絶対パスって。
まず、サーバを通さないと表示をまともに確認できません。また、ローカル作業用のローカルサーバと、納品チェック用のサーバの2つは必要です。
面倒くさいとは言え、ここまでは実はどうでも良い事かもしれません。納品チェックの手間はほとんど変わりませんし。
トラックバック URL :
wordpressを始めて、初の月越え。カレンダーが変わりました(*゚∀゚)=3
……
「前の月」へのリンクが出ない!ってそれはスタイルで消してたtfootタグで出力されるんですね(ノД`)
tfootって位置を動かせないじゃありませんか。
どうやら、wp-includes/eneral-template.php に出力形式の定義があるようですが、直接書き換えるのは、後々のバージョンアップが億劫になるので避けたいところ。というか、エレガントにバックナンバーを辿るためのカレンダーが欲しい~
とりえあず、cssをちょこっといじって妥協。
今日のところは引き上げです。
トラックバック URL :
矛盾に満ちたクリック課金型広告 | WIRED VISIONによると「クリック型広告のクリックを呼び掛けるのは禁止」らしい。
確かに、分からなくもありません。
「クリックだけで中身は見なくても良いから寄付だと思って押してくださいー」なニュアンスのものもありますし。
しかしこれ、例えば「広告サイトも見て下さい」とか「スポンサーもよろしく」とかの表現だとどうなるんでしょうね。
トラックバック URL :
WordPress | 日本語 » WordPress 2.5.1
を上書し、更に、my-category-order プラグイン為にtaxonomy.phpだけ戻す(強引)。
とりあえず、問題なさげ。
IE7での管理画面バグもフィクスされています。
ん?
(日本語版のリリースは数日お待ちください)
ちょwww 気付かず、入れてしまいましたよ?(ノ∀`)
トラックバック URL :
Mobile Eye+プラグインで携帯対応。
管理画面が文字化けしてしまったので、コメント60番に習い?mobile_eye.phpの
return mb_convert_encoding($output, get_settings('blog_charset'), 'auto');を
return mb_convert_encoding($output, get_settings('blog_charset'), 'SJIS');に変えたら直りました。
しかし、何故SJIS…って、option.phpがsjisだからでしょうか。
なら、上記コードを弄るよりも、option.phpをUTF8に変える方がスマートかもしれません。
コード変更を戻し、option.phpをUTF8に。
大丈夫でした(・∀・)

トラックバック URL :