LaCoocan?

新しいホームページ/ウェブサーバーサービス。

http://lacoocan.nifty.com/


@nifty、MT設置が可能な容量2GBの新ホームページサービス「lacoocan」 (Internet Watch)

 3時より公開とのこと。チェックしてみます。

*追記


ニフティ、Movable Typeを利用できるホスティングサービス「LaCoocan」開始(CNET Japan)

*追記

 で、結局LaCoocanではデータベースの選択はできるのかどうか?ということが私の関心となったわけですが、
気になったので問い合わせてみました。本日返事があったのですが

お問い合わせいただいた「LaCoocan」の件について回答いたします。

 ご連絡いただきながら誠に恐縮でございますが、弊社 LaCoocan では、データベース機能である MySQL・PostgreSQL はご利用いただけません。何卒ご了承ください。

 あらかじめ、ご承知おきいただいた上で、LaCoocan のご利用をご検討いただけましたら幸いです。

 なお、フルカワ様より頂戴いたしましたご意見につきましては、必ずしも反映さ
れるとはお約束できかねますが、弊社担当部署へ申し伝え、今後のサービス提
供における貴重な検討材料とさせていただききたく存じます。

 とお返事をいただきました。お手数かけました、ありがとうございます>担当者さま

 …と、まあ予想のつく回答だったわけです。現時点ではMySQL・PostgreSQLには対応しておらず、また今後すぐに対応する予定もないということです。

 現実的にはMovableType・Wiki「なども」利用できる、というよりはMovableType・Wiki「は」利用できる、という現状ではありますが、それのみでかまわないユーザーにとっては考慮しうるサービス、ということではないでしょうか。

|

ゴールひとつ。

ココログいちの名物連載だった、ぴっくあっぷ。さんの「ぴっくあっぷ。のめも」が先日、一周年達成ということで完結されました。

今日の更新分で、まずは一区切り付けたいと思います。 1年間昼夜を問わず動いていたノートPCと、もう若くない体と心に休息を。(笑) (「ココログ1周年。めも1周年。」)

 お疲れ様でした。ココログサイトの動向を見続けることができたのも、「めも」のおかげでした。サービス開始当時と現在ではサイト群の動向もすっかり変わってしまって、別のアプローチが必要になっているのかもしれませんね。
 私みたいな放置ユーザーから見ると、一年間かっちり継続されたというのはとんでもなくすごいことだと思います。

 そんな「ぴっくあっぷ。」さんに一日遅れでココログ「詞織」も一周年。「詞織」にとってはなんとも薄い一周年です(汗)。

|

ココログでamazonへの簡単リンク作成

 本家ではMovable Typeのプラグインで実装させていることなのですが、ココログでamazonのアフィリエイト・サービスのためのリンクソースを手書きで書くのって面倒くさいですよね。ウィンドウを複数開いて(ココログ記事作成ページとamazonの書籍の個別ページとか)、コピー&ペーストを繰り返していると本文を書く気力も失せそうです。

 そこで今さらですが、tsupoさんとかfacetさんがよく記事にされているBookmarkletについて調べる機会を持ったのでメモしておきたいと思います。

 ココログ(ベーシック)の場合、MTのようにプラグインで機能を追加することも出来ませんし、そもそもNewsHandlerやはてなみたいに、サービスにもともと付加されているわけでもありません。CGIで実現させようとしても、正直@homepageにCGIを置くのは他のサーバーより面倒。
 なのでnaoyaさん開発のBookmarklet(ツール)・amazletを利用するのが簡単みたいです。煩雑な手作業の必要なく、簡単にリンクソースを作ることが出来ます。

amazlet - Amazon アフィリエイト簡単作成ツールNDO::Weblog

 amazletを使用して作成したソースは、↓のようになります。

Blog Hacks ―プロが教えるテクニック&ツール100選
宮川 達彦 伊藤 直也
オライリー・ジャパン (2004/08/07)
売り上げランキング: 983
通常24時間以内に発送します。
おすすめ度の平均: 4
4 ブログいじりはたのしい。
4 そのまま使えて実用性の高いノウハウ集

生成されるソースは上記のほかに、単純なテキストリンク、単純なイメージリンクもあります。記事に自動でタグを入れているひとは、こちらのほうを使うと便利かもしれませんね。

|

MovableType3.0、リリース

なんとか予告どおりに出した、というところでしょうか。お疲れさまです。

Movable Type 3.0 Developer Edition 日本語版の提供を開始しました[Six Apart Japan]

導入手順については、おなじみMilanoさんの解説が出てます。超速い。

TypeKeyへの登録
MT2.6からのアップグレード
MT3.0を新規導入する場合
[以上、Movable Type 3.x 導入手順]

 3.0ツールをダウンロードするためには、TypeKeyサービスのIDを取得していることが条件のようです。これは無償ライセンスで利用したい人も同様みたいなので、まずはIDを取得しましょう(注:フルカワはまだです~)。


 関連情報もとりあえずクリップ。

Movable Type 3.0 ガイド[MovableType本家]
Movable Type 技術情報 Blog はじめます[Techknow Movable Type]

 TypeKey情報もまとめないと、ですね。

|

MT3.0メモ

まともな更新もままならない昨今ですが、気になってるMT3.0日本語版に関してシックス・アパート社日本法人の追加説明がありましたので記事にしておきます。

Movable Type 3.0のライセンス体系について

 価格体系と個人ライセンスとして許される限度(とりわけウェブログ数、数えられる「ウェブログ」の定義)についての追加説明となっています。ユーザーの多くが気にしている「個人ユーザーによるフリー利用」について、ずいぶんと説明が加えられた感がありますね。
 私のように「複数の子ブログを使ってウェブサイトを作っている」タイプのばあい、ウェブログ数は「1」と数えられるようです。ちょっと安心。

 以前のニュースからの変更点で目に付いたのは「ユーザー数3→5」への増加(ウェブログ数は5のままで変わらず)。

 ウェブログ5を超える運用を個人単位でされているユーザーもいらっしゃるかとは思いますが、私のような一般人レベルでは困ることはないかなという印象です。

|

MovableType3.0

NDO::Weblog」さんの記事経由で、SixApart社の日本法人プレスリリースの存在を知りました。

 さて気になるのはやっぱりこのニュースですね。

シックス・アパートが日本法人を設立~Movable Type 3.0やTypePadの日本語版を提供~

 ココログプロなどですでに稼動している、記事作成時のインタフェース画面の洗練化が新MTにも影響を与えることを期待しています。
 またTypePadも日本語版がリリースされる予定ということで、ココログとの競合も発生するのかなー、などと思ったり。

|

ユーザーの声:プラス/プロ

新着記事一覧ぴっくあっぷ。さんとこ、それに私のアンテナにも続々と「ココログプラス/プロ」関連の記事情報が入ってきてます。
 私は無料期間中もとくにバージョンアップする予定がなく、ベーシックのままで行く予定なのですが…体験談を聞くのは無関係でも面白いですね。

 てわけで、臨時クリップ。サイトタイトルまではひっぱってませんがご容赦ください。

公開日時を設定できるのがいいですなあ
カレンダーの穴を埋めるのです。
新しいココログ?
とりあえずみんな変えてるし…って、お気持ちわかります。
プラス版でデザイン変更
プラス版でベーシック版のときのスタイルを再現できるでしょうか?
ココログプラス一日目終了
アクセス解析機能はこんな感じで。
ココログプラスに移行しました。
移行前に機能がわかればもっとよいですね。
ココログプロ雑感(高くないよとかなんとかいろいろ)
値段は相応かなと。私はゼロか否かだからなー(汗)
カスタマイヅ完了…
スタイルシートがDLできなかったので、ってダイタンでステキです。
ココログプロ化(汗)
まあ今は無料期間なわけで。
ココログプラスにしましたよ
記事ジャンル別に子ブログを作るとか。
ココログプロのアクセス解析で自サイトを弾きたい。
どなたかお願いします。
ココログプラス/プロの「テンプレートビルダー」はすごいよ
MT3.0の動向が気になります…無料のまま機能を使えないかなー。
ココログプロ実践記1
続編に期待。
ココログプロにしてみました
子blogのURLは親URL+サブフォルダ名。
ココログプロ:スタイルシートを外部ファイルに(ぴっくあっぷ。さん経由)
validに自作スタイルを適用するやり方。テンプレをいじれる人にはわかりやすい説明になってると思いますよ。

(03/20追加)
ココログのお値段(「public memo」さん)
 私やおはるさんとは逆に「高いのではなかろうか」というご意見。気軽に移行することの「できない」金額設定ではありますね。ただこの値段設定は、あくまで「ホーム」…使い捨てのされない、ユーザーのもつ唯一のblogサービスを狙った価格帯ではないかと思えます。持っている複数のサービスの一つとしてみるなら安くない。でもバーチャルソサエティにおける「自分」の「ホーム」の維持費としてなら?レンタルサーバを借りる金額などが比較される対象になるのではないかなーと感じます。たとえば最近のロリポップ!の子会社化ニュースなど見ていても、ニフティの(比較的)長期に安定したサービス、というだけで価格が上がり気味になるのもやむをえないかなと。

|

コメントとトラックバックを許可しないということ

 「コメント書くときのメールアドレス」に対する「あそびをせんとやうまれけむ」さんのトラックバックを読んで思ったこと。それと関連して、以前「ごまめのつぶやき」さんが記事にしていたことに対する感想につなげています。

 まず「ココログ」では、サイト管理者は管理画面からコメント投稿者のIPアドレスを確認できる、この点をすっかり失念してましたので補足しておきます。アドレスがわかった程度でどうだっていうんだ、てことは知るひとは知るわけですが、メルアドをさらすのが不安な人のために付記しておきます。正直なところ、何かしら不安な点があるなら「自宅から(というか職場からアクセスせず)、ただ閲覧のみ(=書き込みしない)」というのが安全策の基本ではないかと思います。この点はサイト管理者側からの「書き込み時の不安をなくしたい」という意図とはまったく別の問題として、閲覧者側が気に留めておく事項ではないかなと思っています。

 で、それとはずれたトピックとなりますが、「ごまめのつぶやき」さんの「コメントもトラバも受け付けないココログユーザーの方へ」という記事に対しての感想を付記します。なんでこの二つのトピックをつなげるのかというと、blogツールを意識的に使ってる=ヘビーな(私の理解する限りでは、加野瀬未友さんの言うところの「ギトギトなブロガー」)とは、大半のココログユーザーは異なる認識基盤を持っているのではないか、またココログの設定が無意識なユーザーに「自然とそのような「結果としてのスタンス」をとらせているのではないか、とそう思うからなのです。

 「ごまめのつぶやき」さんは、

最近、エントリーに対して突っ込みや反論を書こうと思ってクリックしても反応しないblogに、特にココログ内で、ちょくちょく出くわすような気がします。 大上段に「世相を切る」というスタイル(ごまめも最近それに該当するな~)なところで反論コメントやトラバを受け付けない設定になってると、「人様に対しては偉そうに言いっ放し、叩き放しで、自分自身は傷つかないように殻に閉じこもってるのかよ」とさすがに温厚なごまめ(ウソつけ)でも腹が立ちます。 一定の事情があって、その旨説明した上である特定のエントリーについてのコメントやトラバを制限してる、ってのは理解できます。しかし、サイト全体のエントリーについてコメントやトラバ不可にしているのは、ごく限られた個人的な内容を扱う日記サイトを除いて、はっきりいって卑怯者の謗りは免れないのではないですか

と(かなり挑発的に)切り出していますが、これは私など第三者から見ると「とどかない非難」であるように感じます。発言者が「いかに毒舌的な提言」をしているように見えるとしても、それは(口の悪い言い方をするならば)「オナニー」であるし、(ma-samiさん的に表現するならば)「チンコを出すこと」だと思います。要は「別に反論やツッコミなど求めていない」要は「言いっぱなしにすることが(本人にとって)一義であって、それにともなうフェアネスみたいなものを他人は求めようがない」ということだと思ってます。ココログはまだしも紳士的なほうで(多少アダルトの多いプロバイダコミュニティではありますが)、それこそ某掲示板を例に挙げるまでもなく、日本のインターネットは言いっぱなしの文化以外の何者でもないなと思っています。そして、私自身もそれを完全には否定しない。どれだけ「卑怯な」言い口であっても、そこから何も(私が)得られないとは限らない。むしろいいっ放しの中にこそ得られるものがあるかもしれない。その点については判断しようもない。だから、リンクフリー原理主義者が言うように「とにかくまずは”語られる”ことが大事で、発言を制限するべきではない」、というような論調に、この点に限っては私は共感します。だって、コメントとかトラックバックとかって、そんな重要じゃないじゃないですか?
 私はまずインターネットにおける読者です。少なくともそのように自分を定義しています。自身が発言したいことがあるなら自身の領域において発言するし、自身の発言が他者の発言を「抑制」するならば自身が発言しない方が良いように思います。だって、私は先ず「そこにあるテキストを読みたい」のですから。「抑制」された結果テキストが出現しなくなるなら、そのほうが「全体として」マイナスであることは言うまでもないことです…たとえそのテキストが便所の落書きであったとしても。
 だから「コメントとトラックバックを許可しない」ということは、「その管理者が自覚的である限りにおいて」管理者の意思であり…管理者が「自分の記事をどの程度のものとして読んで欲しいか」という、そのような意志として許容するしかないのではないかと思います。反論したければ反論すればよいし、トラックバックする必要なんかないわけで。それこそリンクフリー主義者に言わせれば「反論されたくなければデータをWWW上に置くなよ」という話になる。その程度には、コメントとトラックバックというのはサイト上において「脇役」なのだ、と考えていれば、blogツールというものもそれほど難しいものではないのでは、と思うのです。

 そしてココログ上で「無意識にコメントとトラックバックの機能がオープンになっていない」ということは、皆さんもご存知の通りだと思います(「ごまめのつぶやき」当該記事のコメントでnariさんがすでに指摘されてるように)。「ごまめのつぶやき」さんが追記していた、「ココログスタッフルームで同様の指摘がされていた」という点に関しては、(ニフティに冷淡な私ですから)「そう思うならデフォルトでコメントとトラックバックを受け付ける状態にセットアップしておけよ…ツールに詳しい人間ばかりじゃないんだから」とルッコミを入れるしかないところですね。もっとスタッフを追求するべきことなのかもしれないけど…私は基本的に「わからなければ自分で学ぶしかない」というスタンスなので。今コメントが「無意識に」オープンになってないひとも、どうせそのうち友達に指摘されるからそれまで待っても良いのではないのかな、と思ったり。

 とりとめなくなってしまいましたが、blogだろうが他の形態だろうが、サイトはまず管理者本人が「書きたいこと・書いたこと」が第一義であり、それ以外のものは副次的なものじゃないかなあ、というふうに考えるのでした。そしてそのようなサイト管理者の「勝手な主義」を、それはそれであると許容してコメントをしてくれる方とは懇意にしたいな、とそうも考えるのでした。

|

ココログでblog関連について語ることの

 何かしら興味を持って読み、書いた…特に、結果的にblogに関する…文章がマンソーさんの「acidMansoの日記」に「繰り返される自己言及」分類としてクリップされると、ちょっとイヤンな私です。
 「Artifact」さんの「Start!JUGEMに対する「ブロガー」の期待 」で、クリップURLの最初の方に載せられたときもイヤンと思ったから、単にこっち方面の話題でクリップされることそのものが好きでないのかもしれない。まあ、その気持ちに対する自衛策はわかってるんだけどね。
 でも逆に考えてみると、後ろのケースでの結果として「私自身はJUGEMを試さない」という結論へと導いたのだから、感謝するべきなのかしらん。

|

コメント書くときのメールアドレス

 ぴっくあっぷ。さんの「ぴっくあっぷのめも。」の昨日分に、関連性のある二つのサイトが並んでて面白く拝見したので、覚書きしておきます。

 「匿名コメントを許可に設定しよう」(「まいど、blog始めました」さん)
 「blogは閉鎖的か開放的か」(「...My cup of tea...」さん)

 どちらも話題はblogサイトにコメント入力するときに必要な「メールアドレスの入力」についてです。もちろん上記二つのサイトさんが対立する論旨を語っているというのではなく、「まいど、blog始めました」さんは(ココログ内のサイトとして)、「コメント入力するときにメールアドレスの入力を必須にしている設定だと書き込みにくい人もいるからやめました」という、ご自身の報告になっています。いっぽう「...My cup of tea...」さんのほうはコメントのつきやすい話題、つきにくい話題、というところからはじめて、「そもそもコメントを書き込むのにそんなに抵抗感を感じないひと(特に自身でblogサイトをやってるひと)と、そうでないひとがいるんじゃないだろうか」という印象を述べてらっしゃいます。

 ココログの話題に戻りますが、「詞織」でもコメント入力するさいにはメールアドレスの入力を「必須」に設定してます。この設定によってどれほどのコメントが「書き込まれ損ねている」かどうか、もちろん知るすべはありません。ですが私の記憶する限り、コメントを書き込む人は必須だろうがなんだろうが書き込むかなあ、という印象です。特に荒らし系のひと、自分のコメントが皮肉交じりになっていると自覚してるひと、あるいは悪意はないんだけどメールアドレスをさらすのが不安なひと。そういう人たちはきっちりと「ニセのメールアドレス」で書き込みます。abc@de.comとかですね。ココログの「メールアドレス入力必須」という設定は、せいぜいその程度のしばりしかないわけです。必須だろうがなんだろうが、いくらでもごまかせるし知っている人間は知ってる。

 私が面白いと思ったのはそのような「コメント書き込みを巡る攻防」みたいなところではなくて…「...My cup of tea...」さんの

ということは、普通は誰かの記事にコメントを残すなんて事はしない、ということではないだろうか? 自分の知り合いか、同じblogを持っているという共通点が初めてコメントを残しやすくしているだけで、コメントを残す方が特殊かもしれない。 blogを持っている人はコメントやトラックバックをもらうと嬉しいということが分かるので、残したりするということもあるかもしれない

 というくだりです。考えてみれば、私も日々インターネットのあちこちを覗いてますが、ついぞコメントをつけたことなんかない。ココログを含めたblogサイトにコメントをつけることはありえますけれど、冷静に言ってみてそちらのほうが特殊例ですね。そう考えてくると、結局のところ書き込みしやすいかどうかに関しては「メルアド入力を必須に設定するかどうか」がポイントではないのではないかなと。エントリーされた記事に対する反応を「閲覧者の側が持つかどうか」ではないかなと。そんなわけでメルアド入力必須に設定するかどうかってのも「サイト運営者の好みの問題」におさまるんじゃないかなと思ったりします。

 私自身の過去の行動を見ても、「ニセのメルアドを入力される」という体験そのものに対しての評価はしていないように思います。コメントの内容が「レスポンスできる(=会話が成立する)」ものである限りは、入力されたメールアドレスをチェックするという行動にまで進みません。むしろいただいたコメントの内容が意味不明だったり、単なる悪意にしか読めなかったり、…もっと「相手の情報を求めたい」ときにそのようなニセのメルアドで「情報がシャットアウトされている」と、困惑を感じたり不快に感じたり、相手の言説を素直に受け止めたくない感情を惹起されたりするのだなと思います。
 なので私自身は「メルアド入力必須」の設定のままのほうが長期的に見ると良いコミュニケーションが(自分の周囲では)できると思うし、自身が閲覧者としてコメントを入力するときも「コメントをつけた先の人が”関連情報を見れる”」ようになっていればいいなと、そのくらいに思っています。


 私自身の感想が「まいど、blog始めました」さんの論旨とは逆の方向に向いてしまいましたが、ご不快でしたらTB削除していただけるとさいわいです。各サイトさんのそれぞれのご判断に口をさしはさみたいという意図ではないとご理解いただければと思います。

|

創作小説のサイトを作ってみる

blogツールを使ってサイトを作ってみよう、というのは今年一年の懸案でありました。

 それまでは私もタグ手打ちしたりとかドリームウィーバーを使ったりとかしてましたが、更新時にかかる負担がハンパじゃないのがネックですよね。おまけに私はかなり忘れっぽい人間で、ちょっとさわらないでいるとすぐにツールの使い方を忘れてしまいます。ましてホームページ作成ソフトを乗り換えていった日には…!おお、考えるだにおそろしい。サイトを更新するよりツールを勉強する時間の方が長くなっちゃいますよ。そして飽きて投げ出す。…うーん、自分の未来の姿がくっきりと見えます。

 そんなわけで、最低限HTMLとCSSの知識だけを核になんとか一生やってゆけないかなあ、などとぬるいことを考えていたことが、私がblogツールなるものに手を染めるきっかけではあったのでした。

 私はもともと@ホームページで創作小説のサイトを作ってちんたら自己満足にひたって生きてきてますが、たかだか10M(今は20Mですね)のサイトを維持・メンテするのさえ避けたがる怠惰な性、いったん生み出されたページはそのまま紙ごみと大差ないほどの扱いをしてました。これではいけない。blogツールを使えば、とりあえずテキストデータは資産とみなすことができる。ということで、ココログをはじめたのもその流れの副産物でした。

 とりあえず、こんな感じのサイトがblogツールを使って作れるよ、というお話でした。

|

ほったらかしー

作ったばっかりの「Exciteブログ」版「詞織」ですが、作った翌日にはもうほったらかしになってます。メークアップを終えたら満足して寝てしまったようなものですが、システム上やむをえない部分も多い。
 なんとなくの印象でしかないですが、まずサイトを作った人間同士の交流がココログよりもさらに希薄な感じがするのがひとつ。ココログだってそれほど緊密なコミュニティを作ってるわけじゃないですが、exciteはますますジオシティーズに近い感じなのかな。
 そして今のところ、ログのエクスポートができない。ということは、書けば書いただけ(私にとっては)労力をドブに捨ててるようなものなのです(そんなわけで過去の闇に消えたテキスト量に思いを馳せたりします)。

 もっとも、厳密にいうとExciteには罪はないのですが、これについては別記事で。

|

Start!JUGEM!の境界線

 マリリン・マンソーさんの記事をきっかけにして、心の中に漠然と生まれていたものがはっきりしてきました。

しかし、今回若干改善の余地があるのではないかと考えられるキャンペーンサイトが出現した。『Start! JUGEM!』である。はじめてブログを利用する人たちが多く集まることが予想されるホスティングサービスのプレイベントとしては、はじめてブログを利用する人たちにとってわかりにくい内容となっているのだ。(「Ocolog」さん)

 「詞織」はJUGEMの提供元・paperboy&co.のレンタルサーバー・ロリポップ!上で動くMovableTypeから動き始めたので、フルカワも同社のサービスの動向にはかなり関心があります。ココログ以外の選択肢のなかではもっともフルカワを魅了している(予定の)サービス、それがJUGEMです。
 そんな感じで基本的に同社に期待しているのですが、同様に「かなり期待をしている」と仰ってるマンソーさんの上記の印象とフルカワの印象には重なる部分が多いです。ロリポップ!にせよJUGEMにせよわかりにくい、というか「雑然とした印象がある」。他のブログサービスが基本的に「ブログについて何も知らなくても、とりあえずはじめられるように…」というスタンスが垣間見えるのに対し、JUGEMというかpaperboy&co.のスタンスはまったく逆を行ってるように見えます。そのスタンスをフルカワはあんまり好んでないのですが、自分で使う限りの部分についてpaperboy&co.とそのサービスが生み出すコミュニティ(と、外部が判断するもの)の影響力に強制されない限りはそれも企業文化(かあるいはネット文化)かな、と割り切りたいところです。
 で、会社のスタンスについて問題にしたいわけじゃなくて。このサービスのインフォメーションサイトである「Start!JUGEM」についてマンソーさんが指摘されてるポイントのうち

 さらに、このような有名だけれど有名でない有名人たちをかき集めて、さて、そこから何を訴えたいのかという方向性がいまいち見えてこない。この点は執筆を依頼された当のブロガーたちのほうが戸惑っているのではないだろうか?
 むしろ、これらの執筆者が「JUGEMマンセー!JUGEMワッショイ! この赤外線発生磁気枕を使うようになってから冷え性や肩こりが治って安眠できるようになりました」といったプロパガンダ的ポストを羅列したほうが読者としてはわかりやすく読みやすくなるのかもしれない。

 という点にものすごく同意、というかそうしてほしいなとさえ思っている一般人がここにいるわけなんです。ただでさえ「わかりにくい・雑然とした」印象のpaperboy&co.提供サービス上で動くサイトのテキストがさらに輪をかけて雑然としている印象がものすごく強くて、逆に「書かれたもの・伝えられた(伝えることを望まれた)もの」を私はうまく受け取れない。受け取れないということは、そのサービスから放たれる魅力の引力も感じることができない。これは同社のファンとしては残念なことです。せめてプロパガンダ・広告記事が「Start!JUGEM!」にばんばん並んだ方が、まだ受ける印象は良いのかもしれないなあと感じているのです。あるいはマンソーさんの着目したのとは逆の印象として感じる点ですが、他の提供元(それこそ@niftyやlivedoor、exciteなど)と異なって、paperboy&co.を利用しようと関心を持っている層というのは最低限「ウェブスペースとか自作CGIとかブログツールとか」に興味のある層だと思うのだけど…かならずしも「その層」に向いた企画じゃないような印象を感じているのかもしれません。あるいはそうではないのかな?もっと関心の薄い層に向いてるのかな?でもそのわりには「敷居が高い」ように見える気もしますし。

 私はもともと社長ブログにも有名人ブログにも興味のない人間なので、先に使ってるひとが「このサービスはこんなとこが良いよ!」と言ってくれたほうが(それが純粋な広告でも)楽しんで読めますね。なのでこれから記事を書かれる有名人のかたがたの誰か一人でも、そちら系の記事を書いてくれたらうれしいなあと思っています。それがフルカワにとっての「スタートのための境界線」になるかもしれません。でもそういう情報が「有名人の側に与えられてるのかな?」という疑問も感じないわけじゃなかったり。

|

現在使用中といえば

私は定番で「パラボナミニ」ですね。

RSSリーダー何使ってますか?

「RSSリーダー何使ってますか?」と題して利用状況調査をおこなってみようと思います。動機は単純に個人的な興味ですが、皆さんからの情報は、各ソフトウェアを製作されている方に限らず、これから利用しようとしている人、乗り換えを考えている人にも役に立つのでは、と思っています。(「weblog Escapade」さん)

 キタシノガイチさんが標題の件についてコメント&トラックバックを募集していたので、紹介がてら自分のケースについても書いておきます。

 フルカワはRSSリーダーをあまり活用していないユーザー層です。意図的に情報をインプットしないようにしているというのもあります。人間の目はあまり遠くまで見えないほうが良いかも、などと思うくらいに。なのでリーダーにも高機能や(他ツールとの)統合性をあんまり求めていません。軽くて、さくさく動いて、私にとって重要な情報(興味をひかれる「記事タイトル」)を伝えてくれることを望んでいます。
 そんなわけで、ごく限られたお気に入りのサイトと「ココログ新着情報」を見るためだけにRSSリーダーを使っていますが、このくらいの使用度だと「パラボナミニ」はとても良いソフトだと思います。フリーウェアというのも大きいですね。「パラボナミニ」はTickerとしても使えるので、使い方も意外と広いかなと思います。

|

「詞織」ノート:ノート02

コンテンツのためのノートその2。
内容はまともな文章になってないので見とばしておくんなさい。

 おおざっぱに言うと、cssの各要素の適用は以下のような感じ。
どこで指定するか?
h2への指定を例とするなら以下のような感じに適用されます。
どこで指定するか?h2での事例
ココログの「外箱」はこんな感じになってます。(三段カラムの場合。二段は…時間が-o-;)
要素の概略図

|

「詞織」ノート:ノート01

コンテンツのためのノートそのいち。
内容はまともな文章になってませんので読み飛ばしておくんなさい。


前説:Tips紹介のスタンスについて†
前説:「詞織」利用の上での希望
前説:@niftyのスタンス(いちユーザーからの視点)

★自作スタイルシート(css)
・自作スタイルシートの適用†
・自作スタイルシート適用の問題点
★Mac文字化け対策
・Macの文字化け:わかんないひと向け†
・Mac&IEの文字化け対策†
○Operaのフォント対策
・Operaのフォントを美しく表示させる†
○(参考)ブラウザとフォント
・ブラウザでページのフォントを設定する
★サイドバーの応用(マイリスト)
・オリジナルコンテンツを表示させる†
・サイドバー応用の問題点
★デフォルトのココログテンプレート&スタイル
・デフォルトで見やすいスタイル・段組
・デフォルト:01~13†
・なんちゃってデフォルト†
・デフォルトで設定の必要な項目
・ココログCSS要素:抜き書き
★blogコミュニケーションの入り口へ
・トラックバックとコメントを受け付ける?
・記事によって受付けないTB・コメント†

|

デフォルトスタイル見学!

(ココログ紹介)
デフォルトのスタイル」に「梅ヶ枝」さんからトラックバックを頂戴しました。

ココログテンプレートの見本

固定リンクのページとプロフィールのページがあります。レイアウトは「両サイドバー付き」。トラックバックとコメントが1つずつ付いた状態です。窓を小さくしたり最大化したり、複数のブラウザで見てどんな具合か試して下さい。

 @ホームページスペースと連動して、ココログデフォルトのデザインぺージが色違いを含めて全16種類アップされているという、労作です。すごい!フルカワは感動しました。
 ココログのデフォルトデザインはいつこっそり詳細が変更されてるかわからないという問題(汗)があるのですが、それでもデザインのイメージをつかむため、「梅ヶ枝」さんの作品は利用価値大ですよ!

|

Macの文字化け:見る側から

Macの文字化け:わかんない人向け」「コメント文字化けMAC&IE」が「サイト管理者側からの文字化け対策」なのに対し、この記事は「サイト閲覧者の側からの」文字化け対策の紹介です。「コメント欄が文字化けして入力できないよ」と言われた場合、こちらのやりかたを紹介するのも手かと思います。どっちか楽な方をすすめたほうがよいかなと。

 具体的なやり方は「ぞうさんちv2」さんのところで記事になってます。

Mac版IEのコメント欄の文字化け解消法

 今までは(主な原因としては私がMacのIEにさっぱり無知だったという点のため)、なんとかCSSをいじってむりやり修正しようというスタンスでの記事を書いたりしてきたのですが、だれかに「ブラウザのこの設定をいじれば見えるよ」と説明できるならば、この方法が一番楽だなという印象です。もっとも、誰かに説明するってことがほんとに難しいですよね(汗) Macユーザーがんばれ!

注記:この記事は「文字化けを閲覧側で回避!か?」の続報として書かれています。

|

文字化けを閲覧側で回避!か?

コメント文字化けMAC&IE」に、新井隆浩さんからトラックバックを頂戴しました。


Mac 用 IE と UTF-8(「新井隆浩」さん)
試した所、IE の環境設定で、文字セットが「ユニバーサル文字(UTF-8)」の場合のフォントを日本語のフォントに設定しておけば解決できるようだということが分かりました。これで特に対策を行っていない所でも問題はなくなるのではないでしょうか?

 実は最初、述べられた意味がわからずに悩みました。IEに環境設定なんて項目があったかな?と。
新井さんが仰ってる意味は、おそらく以下のような内容だと思います。

WindowsIE6の場合ですと、ツールバーの「ツール>インターネットオプション」で開く「全般」タブの下部に並んでいるボタンのうち「フォント」で設定できる項目を日本語のフォントに設定しておくと、解決できるようだという主旨のようです。もっともこのボタンには「文字セットが~」に相当する「ユニバーサル文字の選択」項がないので、新井さんは別の機能について仰ってるのかもしれません。

 Macを使っていて文字化けするという方は、この項目を一度チェックされてみてはいかがでしょうか?フルカワはWinユーザーだしデフォルトで「MS Pゴシック」設定だったりで、この現象をあいかわらず確認できておりません。まさに幽霊対策。試された方のTBおまちしてますー。

|

デフォルト13:M▲TRIX

M▲TRIXはIE5.xで、デフォルト設定のままでは3段カラムのページを閲覧することができないスタイルです。
 手間をかけたくない人は選択肢からはずしましょう。

M▲TRIXの見え方
IE5.xだと右サイドバーの姿がはるか下方に…

 M▲TRIXは本文背景(#container)色が黒色、本文が蛍光グリーン、リンク色が灰色となっています。どこかで見た配色ですが気のせいです。なにせM▲TRIXですから(そもそもなんと読むのでしょう?) 本文の視認性は意外に良いです。恐るべし蛍光グリーン。リンク色が背景にまぎれますが、そんなに問題を感じないのは本文に挟まれてるからでしょうか。
 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。ボーダーありのスタイルなので、デフォルトの状態では、IE5.xでサイドバーが吹き飛んでしまいます。
 行間は本文・サイドバーでそれぞれ150%( .content p制御)・150%( .sidebar li制御)。

 M▲TRIXの本文とサイドバーのフォント指定( .content p、および .sidebar li)は「'Trebuchet MS', Verdana, sans-serif」となっていますので、フォントの視認性は許容範囲内だと思われます。ただこの設定だと、バージョンの古いOperaでは非常に読みにくいフォントが適用されてしまうという問題があります。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が40pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。タイトルに画像を入れる際にはお気をつけください。

|

CSS配布?

新着記事から見つけたリクエストを紹介します。

 「ココログにCSSを適用したい」(「Blogtopia★斑鳩」さん)

どなた様か、CSSを配布して下さっている人はいないですかね~。
例えば、ココログの標準デザインだとサイドバーがブラウザによっては飛んでしまうことやフォントが見づらいことがあるようなので、それらを訂正するCSSをフォントやリンクカラーなども含めて記述して公開するってことをどなた様かがやって下さると非常に大人気なコンテンツとなるのではないかな~なんて思うわけです。

 …とのことです。「募集中」のキーワードが入ってなかったためか、まだクロールしてないだけか、「ココログル」さんでは拾ってないみたいでした。そこで「詞織」で紹介記事としてみました。
 どなたか「Blogtopia★斑鳩」さんの記事に反応されるかな?

|

デフォルト12:@nifty2

@nifty2はIE5.xで、デフォルト設定のままでは3段カラムのページを閲覧することができないスタイルです。
 手間をかけたくない人は選択肢からはずしましょう。

@nifty2の見え方
IE5.xだと右サイドバーの姿がはるか下方に…

 @nifty2は本文背景(#container)色が白色、本文が黒色、リンク色がオレンジとなっています。本文の視認性は良いです。リンク色とバナー部の強調色がシンプルにマッチしているのは良い印象です。
 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。ボーダーありのスタイルなので、デフォルトの状態では、IE5.xでサイドバーが吹き飛んでしまいます。
 行間は本文・サイドバーでそれぞれ150%( .content p制御)・150%( .sidebar li制御)。

 @nifty2の本文とサイドバーのフォント指定( .content p、および .sidebar li)は「'Trebuchet MS', Verdana, sans-serif」となっていますので、フォントの視認性は許容範囲内だと思われます。ただこの設定だと、バージョンの古いOperaでは非常に読みにくいフォントが適用されてしまうという問題があります。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が39pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。タイトルに画像を入れる際にはお気をつけください。

|

Ping情報は必ずしも最新記事を

先日からの「ココログ新着記事」上に存在する「詞織」の新着情報がずーっと「ゼルダの伝説に興味アリ」になってました。まあいいんですけど。

 なんでこうなるのか?については以前に書いた気もしますし、めんどいしささいなことなので放置するとして。

 私は任天堂のまわしものではありません^^;

|

デフォルト11:@nifty1

@nifty1はIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その8)です。
 手間をかけたくない人にはオススメです。
@nifty1・3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる
 
 @nifty1は本文背景(#container)色が白、本文が黒、リンク色が青となっています。なかなかどぎついオレンジですね。DADADA!

 @nifty1は視認性・サイズともに使用価値の高いスタイルとなっています。本文記事の行間も、サイドバーのマイリストのメモ欄に書き込んだ部分の行間はほど良いです( .sidebar li 150%)。ただIE6だとやっぱりちょっと行間が開くかな?背景色のわりには^^;、トータルで閲覧できるサイズという意味で評価は高いです。

 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。もともとボーダーのないデザインなので細かく設定してなくても問題がないです。

 @nifty1の本文フォント指定( .content p)もサイドバーのメモ( .sidebar li)も「'Trebuchet MS', Verdana, sans-serif」となっています。サイドバーのほうはいまいちですが、本文は多くのブラウザで快適に読むことができると思います。

 ページのヘッダ部分(#Banner)の縦幅を決定している要素は、40pxとギリギリ感があります。バナー貼り付け時にはご注意を。

 というわけで、@nifty1は背景色以外はしごく標準的なデザインとなってます。やはり色か!まあ、これは本当に好みの問題になっちゃいますね。

 手を加えずともIE5.xでも閲覧できる3段カラムのスタイルは、以上の8種類・ボックスの色違いをあわせて9種類のバリエーションが利用できることが判明しました。ココログユーザーなんぼいるかはわかりませんが、安牌9ですか…そりゃスタイル増量要望が増えますわな。

|

デフォルト10:無地

無地はIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その7)です。
 手間をかけたくない人にはオススメです。
無地3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる
 
 無地は本文背景(#container)色が白、本文が黒、リンク色が青となっています。無地ですから。

 無地は視認性・サイズともに使用価値の高いスタイルとなっています。無地ですから。しかしIE6だと本文記事の行間はちょっと広い(200%)。IE6だと読みにくいなーと感じます。サイドバーのマイリストのメモ欄に書き込んだ部分の行間はほど良いです( .sidebar li 150%)が、IE6だとやっぱりちょっと行間が開くかな?でもトータルで閲覧できるサイズという意味で、評価は高いです。

 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで900、それぞれ200・500・200。デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。もともとボーダーのないデザインなので、清流のように細かく設定してなくても問題がないです。もちろん全体幅900という数値は、ごく標準的なページ幅(800)から考えると広めともいえます。IEで「お気に入り」を表示していると、右端を見るのにスクロールしなくてはならない、というラインですね。この状態をどのように捉えるかは、サイト管理者次第ではないかと思います。

 無地の本文フォント指定( .content p)は「Georgia, 'Times New Roman', serif」。サイドバーのメモ( .sidebar li)は「Verdana, Arial, sans-serif」となっています。サイドバーのほうはいまいちですが、本文は多くのブラウザで快適に読むことができると思います。

 ページのヘッダ部分(#Banner)の縦幅を決定している要素は、40pxとギリギリ感があります。バナー貼り付け時にはご注意を。

 なにせ無地なので単体のスタイルとしてはほとんど個性のないこの「無地」、スタイルをカスタマイズできるようなサービスが開始されたときにはより多く活用できる潜在能力を秘めているのではないでしょうか。

|

個別記事ごとに設定できるTB/コメント

誰に?:ブラウザかRSSリーダーか」をエントリーしたら、呼んでもいない人たちからの「反論」がトラックバックされてきて、困惑しているフルカワです。議論することを否定はしませんが、議論の押し売りされるのはごめんだなあ。最初に「この記事は○○さんへ具体的に宛てたもので、議論を開始するためのものではありませんよ」と説明すればよかったのでせうか。それもなにやら、いい大人相手に失礼な気もするのですが。

 *まず上記記事にトラックバックされた方がたのそれぞれのご意見の論旨のキモについては、勉強になりましたし今後の判断材料としてフルカワの心の糧になりました。あらかじめお礼を申し上げておきます。
 ただ今回のケースのような場合、しばたにさんはともかくとして、私のところにトラックバックする必然性ってないんじゃないの?という気がします。少なくとも私はこの件に関して聞く耳もってないわけですし。

 「詞織」の記事は今のところ全記事オープンにコメントもTBも受け付けるようになっていますが、他者がトラックバックする価値の残っている記事だけでなく、すでに話題としても過去のものとなってしまった記事や、フルカワ個人の考え(しかもアンチテーゼを求めているんでもない、つぶやきみたいなもの)にさえ、あるときは「論理的だけど記事の主旨とはまったくずれた、我田引水な反対意見(しかも結論そのものは同じだったりする)」や、「フルカワの無知を糾弾しつつも建設的な意見を教えてくれない、単なる煽り」がときたまおとずれます。

 こーいうのって、やる気、下げますね。

 しょうがないので、以前のくまさんのご意見にしたがって「トラックバックおことわり記事」を導入することにしました。以前は否定しておきながら、結局先人の知恵になびく惰弱なフルカワでした。とはいえ「詞織」のログは現在、閲覧者の対象を絞っていない一般向け記事もあれば、絞りまくっている個人的メモみたいなものも混じるブログ、誤解を招かないためにはやむをえません。くまさんありがとう!

--------------------------------------------

 やり方は簡単です。
 記事を作成する時点で、記事エリアの下部の「コメント」「トラックバック」には、それぞれを受け付けるかどうかを選択することのできるチェックボックスなどが置かれています。「これは有益な情報だからトラックバックを受け付けよう」「これは私の単なるボヤキだからトラックバックはごめんだね」などと選択することができます。

 賞味期限の切れた過去記事は、トラックバックもコメントもクローズにしてしまって、掲示板で時たまそちら関連の話題をふたたび取り上げる…そんな使い方が「賢い使い方」みたいですね。そんなわけで「詞織」の記事の中には、トラックバックもコメントもできない記事があります。基本的に古い記事はどんどんクローズにしてゆきます。質問などは掲示板でも対応しますのでお気軽にどうぞ。楽しくココログしましょう!

なおこの記事はトラックバックもコメントもうけつけてません^^;

|

わかんない人向け(前説)

前説なのに更新順番はあと。

Macの文字化け:わかんない人向け」の補足説明です。わかんない初心者の人向けというよりは、初心者に伝えてくれるMacユーザーの人向けの説明かな。


 「詞織」には主としてCSS関連の仕組みについて、ある程度噛み砕いて解説している一連の記事があります。でも、まったく初心者向けには書いていません。ホームページの作り方は知ってるけどCSSってわからない、という人向けには記事を書いていません。なぜかって?まったくわからないものをわからないまま使うのは危険なことだと、フルカワは思うからです。わからないけどとにかく使えるようになりたい。使えるようになったらもっといろいろわかっていくだろう、まずはとっかかりがほしい。そういう人に向いてるのが「詞織」です。
 なので、ページのデザインをコントロールするための技術であるCSSは「無難な技術」です。知ればいろいろ楽しく楽にコントロールできるけど、使えなくても知らなくても問題がない。それもまた、詞織が「完全に初心者向けというわけではない」理由です。

 ただ、現在の「ココログ」で(おそらく唯一の)「初心者の越えられないCSSの壁」があるとすれば、それは何回か話題に出てきている「Mac&IEで、コメントフォームが文字化けする」問題ではないかなと思います。ニフティから提供されているものがMacで使えない!推奨がWinだけ?買い換えろとでも!? …Winユーザーなので憤りの声までは代弁できませんが、「Macの文字化け:わかんない人向け」によってとりあえず急場をしのぎ、ニフティが対応してくれるのを待つなりcssを覚えるなりすれば新たな道も開けてくるんじゃないかな、そのように考えて今回の記事を作成しました。

|

Macの文字化け:わかんない人向け

注記:「MacのIEでココログサイトを閲覧し、コメントフォームに文字を入力しようとすると文字化けする」という現象は、基本的にはブラウザの環境設定で回避できます。本記事は「設定を直せることに気づいてない人にもストレスフルに閲覧してもらうための裏技」という位置づけです。すでに自作スタイルを使ってる人・自作スタイルを使おうとしている人候補のかたのために。

 文字化けを回避するための設定についてのTipsはリンク先をご参照ください。

http://siolli.cocolog-nifty.com/blog/2004/01/mac_1.html

----------------------------------------------

初心者Macユーザー向けに特別編:すぐに使える文字化け対策のご提案です。CSSはわかんない。面倒なのは嫌いだし。でも文字化けするのは困るなあ。という人のために。

*注意点
この方法は「ファイルをアップロードする」ものです。現在ココログでは一度アップロードしたファイルを消去する方法がありません。 試される前に、この点を確認のうえ自己責任でお願いします。このサンプル記事ではcssファイル名を「macstyle」としています。サンプルのcssファイルは最小限の設定のみ記入しています(2kb相当)。


 (基本的な方法は「自作スタイルシートの適用」です)

1.まず以下のリンクを「右クリック>対象を保存(Macではどうやるのかわからないですが)」で、cssファイルをダウンロードしてください。

コメントフォーム文字化け修正用cssファイル(macstyle.css)


2.このcssファイルをそのまま、管理画面の「写真やファイルをアップロードする」でココログにアップロードします。管理画面1
管理画面のこの項目をクリック

 項目をクリックしてきて出てきたウィンドウで、「参照」でダウンロードしたファイルを選択します。他の項目には何も入力しなくて良いです。選択を終えたらアップロード。

3.サブタイトル欄に以下のタグを入力します。コピー&ペーストしたあとあなたのURLと入れ替えましょう。

<link rel="stylesheet" href="あなたのサイトのURL/あなたのサイトのディレクトリ名/macstyle.css" type="text/css" />

「詞織」を例にすると
<link rel="stylesheet" href="http://siolli.cocolog-nifty.com/blog/macstyle.css" type="text/css" />
となります。
管理画面2
管理画面のこの項目をクリック

管理画面3
タグを入力するのはこのフィールド

 さて、「保存」して「サイトに反映」させてみましょう。

 あとはご自身でフォームに文字を入力してみるなりして確認し、文字化けしなければ成功です。

 スタイルシートってなんだかわからん、て人も、まずはここから試してみてはいかがでしょうか。


 *フルカワはWinユーザーですので、この方法を自己確認したわけではありません。文字化けするようでしたらコメントなりトラックバックなりいただければ、サンプルのcssを修正していきたいと思っています。

|

誰に?:ブラウザかRSSリーダーか

(2003.01.13「パラボナミニ」の新バージョンに関する追記アリ)

 サブタイトル欄にlinkタグなどが含まれることの問題性について、キタシノガイチさんと情報交換しました。

 「詞織」で紹介している「自作スタイルシートの適用」は、サブタイトル欄にlinkタグをつっこむというその「乱暴な」やり方のためもあって、賛否両論のはっきりしているやり方です。この件についてはすでに討論テーマともなりましたし、フルカワ自身も「なぜあえてそのような方法を紹介するか」について所信表明してきたりもしました。
 RSSリーダーのユーザーもまた、この「サブタイトル欄の問題」に関わってくる対象です。RSSリーダーはその「ツールとしての目的」から言って、ホームページに設定されているスタイルシートと縁の薄い存在です。リーダーを使っていると、そもそもサイト作成者の意図した「デザイン」を見ることなく、リーダーのユーザーは「コンテンツ(=テキスト)だけ」を取得していきます。
 このことの是非そのものは問題ではありません。百人の閲覧者がいれば、百通りの「閲覧方法」があるのですから。ですからサイト作成者が「リーダー閲覧者のほうを向いたサイトを作成するか」「ブラウザ閲覧者のほうを向いたサイトを作成するか」もまた、(逆に)サイト「作成者」にゆだねられていると言って良いと思います。

 私見ですが、「ブラウザもRSSリーダーも両方ともに綺麗に情報伝達できるような、そんなインフラはまだ整っていない」のではないかと思います。これからもどうなんだろう、という印象さえあります。

 フルカワのみるところ、問題はあきらかにRSSリーダーの側にあります。そのように考えるに至った経緯については、キタシノガイチさんとの以下のやりとりにあらわれています。

 *キタシノガイチさんの場合、それまで使用していたらしい自作スタイルをとりやめた理由のひとつが「RSSリーダーによっては「サブタイトル欄のタグを表示してしまい、サイトの説明文が意味不明になる」ということだったようです。

自分が試したRSSリーダーの中には、ウェブログのタイトル(ここだとweblog Escapade)とともに、サブタイトルを表示するものがあった。ここで問題になるのは、アクセス解析以外にももっと重要なタグが貼り付けられていることだ。そう、ココログ内では有名な、自作スタイルシートを読み込ませるためのタグが書き込まれている。
正直、このウェブログをRSSリーダーに登録して、最初にサブタイトルが表示されたときに思ったのは、「ココログ利用者なら事情がわかっているから良いにせよ、何も知らない人がRSSをキャッチして、たまたま自分の記事に興味を持って表示させてみたら、変なサブタイトルが出てきた」という事態。もし自分がココログユーザーではない、普通にRSSリーダーを使って情報収集をしている人だったら、「なんじゃこのサブタイトルは?」って思ってしまうだろう。(「weblog Escapade」さん)

 フルカワはこの記事に対してコメントをつけ、タグが表示されてしまうRSSリーダーについてお訊きしました。RSSリーダーを日常的には使っていないサイト作成者が、RSSリーダーのユーザーのために気をつけねばならないことはあるだろうか?それが興味の焦点でした。

 フルカワがチェックしたのは「パラボナミニv1.1.8」「rabbit ticker」「CMN」「Headline-reader」の4種類。厳密に言うとリーダーではないCMNも含んでますが、これらのうちサブタイトルの中のタグ情報を読み込んでしまうのは「パラボナミニ」「CMN」の2種類です。

 「パラボナミニv1.1.8」は基本的にサブタイトル情報を表示しませんが、収集しているURLの編集を行う際に表示される「説明文」とい項目が、ココログのh2タグ(サブタイトル欄)を取得しています。このためサブタイトル欄にタグをいれているばあい、まるまるタグが表示されていました。現行のv1.1.9では、このタグは表示されないようになっています。

 「CMN」はいわゆる3ペイン式のツールで、記事情報を表示するエリアには基本的にスタイルは適用されていません。ただ1点、サイトのタイトル情報を表示する際にのみ「タイトル」「サブタイトル欄」を参照し、この際サブタイトル欄にlinkタグが含まれている場合、スタイルが適用されます。この現象に問題性があるかどうかは、フルカワの見る限りではあまり気にしなくて良いようにも思われます。タグそのものは表示されません。

 「rabbit ticker」はサブタイトル情報を取得せず、「Headline-reader」はサブタイトル欄のタグ情報を除外して取得しているようです(「詞織」でいうとsi olli・・・のみ表示)。これらで問題がおこるケースは、(すくなくともlinkタグに関しては)薄いのではないかと思います。

 以上のように調べて見て思ったことは、「そもそもcssファイルという存在はブラウザ閲覧のためのファイルである。RSSリーダーがタグとして(あるいはテキストとして)読み込んでしまうのは、ツールとして問題がある」のではないか。それがそもそも「問題である」とするならば。ということです。

-----------------------------------------------
*追記 CMN上で動作するココログエクステンションのスタンスについては、エクステンション作成者であるしばたにさんからトラックバックを頂戴しました。

CMN用エクステンションに関しては「練り込み不足」ではなく、「あえてそうしています」と強く主張しておきたいと思います。(「本格焼酎忘備録」さん)

 トラックバック先もご参照ください。フルカワはトラックバックをふまえて、上記「それがそもそも~」の部分にアンダーラインを追加しました。フルカワ自身のスタンスとしては、「そもそも各種RSSリーダー及び同様に利用される各種ツールがタグを読み込むか読み込まないかそのものを問題とは見なさない」ということを言明しておきたいと思います。私が各種ツールを使う場合、気になるのは記事タイトルと本文記事が読めるかどうかでその他の条件ではありませんので(つまりサイトタイトルとかサイトの説明文は興味がないです)。ただ、文脈の中で好意的ではないようにとれる表現があるとして、ご気分を害されたのでしたらお詫び申し上げます。ごめんなさい。

 タグが表示される「パラボナミニ」にしても、それが「問題を看過した」単なる「練りこみ不足」といえるのかどうか、フルカワは疑問に思っています。つまり今回のようなケースでタグが「文字列として表示」されたり「スタイルとして適用」されたりするのは、「問題」なのかな?という思いからの記事となっています。

(2003.01.13追記)
 「パラボナミニ」におけるタグ表示について、キタシノガイチさんの記事によると、このタグを隠すように対処された「パラボナミニ v1.1.9 [RSSリーダー]」がバージョンアップされた、とのことです。
 フルカワもバージョンアップしてみました。確かにタグが表示されないようになっています。すごい!そして早い!製作者のくまけんさんからも、ご丁寧にもメールでバージョンアップの件についての案内を頂戴しました。くまけんさん、ありがとうございました。

*追記終わり
-----------------------------------------

そもそもココログのサブタイトル欄情報<h2>タグは、「HTML文法的にサイトの説明文を書くべきとされたエリア」なのでしょうか?HTMLは文書構造記述のルールだと思うのですが、H1・H2などのタグ内容までは厳密に「タイトルのため」「サブタイトルのため」と言い切れない部分があるように思います。一括して「見出し情報のため」ということならば理解できるのですが、そのばあいページ中に含まれる<h2>タグは自然と限定されると思いますし、「ページの説明文であるサブタイトルとしてのh2」と「記事のタイトルとしてのh2」が混在するのはどうなんだろう?という印象にもつながるかなと思います。つまりh2タグというだけでは、それが「サイトの説明としての見出しなのか」「ページの個別記事の見出しなのか」「それ以外の何かの見出しなのか」を、厳密には区別していないのです。
 となると、そもそも「サブタイトルとしてのh2タグにサイトの説明文を載せているユーザーシェアはどれくらいなのでしょうか?
 それは一般化した慣行なのでしょうか?ユーザーはサブタイトル欄をサイト説明文として見るでしょうか?そのためにタイトルにもサブタイトルにも余計なもの(画像ファイルとかlinkタグとか)を含めずに、タグなしのテキストのみでサイトをデザインするでしょうか?現行のツールでサブタイトル欄に含まれている「テキスト以外の情報を読み取ってしまう」ツールはあきらかに練りこみ不足ではないかとフルカワが思うのは、そのような理由からです。
 「詞織」のサブタイトルから読み取れることは、せいぜい「詞織」を運営しているのがフルカワマサユキだということくらいです。ラテン語を読める人がいたらもう少し余計な情報も取得できますが、読めなくても問題ないようなことしか書いていません。「詞織」のサブタイトル欄は伝達性の低いキャッチコピーみたいなものです。
 ですからサイトの説明を「サブタイトル」で行いたい方は、そこではサイトの説明しかしないほうが良いということです。タイトルをタグで修飾しない(詞織でもしてません)ように、サブタイトルでもタグはいれないほうが良いのです。逆に言うと、サイトの説明をしてないひとは、この問題にかかずらわる必要がないということになります。だって、まともなRSSリーダーなら、サブタイトル欄のどの情報を取得すべきで、どの情報がRSSリーダーにとっては不要なものなのか、ちゃんと判断する(もしくは、判断すべき)のですから。逆に言うと、そのようなタグ情報を表示しているツールはその時点で、「私はこの情報を有害ではないものであると判断しているよ」と所信表明しているようにも思われるのです。

 サイト作成者が「どのような閲覧者層に向けてサイトをデザインするかどうか」は、サイト作成者本人の理解と判断にゆだねられています。作成者に前提となる知識がない場合、サイトはたとえ文法的には「妥当」であっても、各種のツールによってはいろいろ「瑣末な」問題が生じてきます。何も考えずに問題なくできる方法など存在しません。だから、たとえば今回のケースのような、「ブラウザで閲覧してもらうためにcssを活用する」か「RSSリーダーで情報取得してもらうために(ココログでの)css活用をためらう」かどうかも、どちらもありうるのではないかと思うのです。「どちらか」という事態が生じるとすれば…そのときはlinkタグを読み込むことによって、ソフトウェアが「致命的なエラーを起こす」そのような状況が発見されたとき、ということになるのではないでしょうか。「致命的なエラー」を体験した方が、教えてくれることを期待しています。最善なのは「致命的なエラー」が存在しない、ということもいうまでもないことです。

 サブタイトル欄にlinkタグを埋め込むことによる「マイナス」のひとつであったこの問題について、1ヶ月経ちましたが以上のような「判断」をフルカワはすることになりました。いろいろ教えていただいて、キタシノガイチさんには感謝しております。


|

デフォルト09:清流

清流はIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その6)です。
 手間をかけたくない人にはオススメです。
清流3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる
 
 清流は本文背景(#container)色が白、本文が黒、リンク色が青となっています。ごく標準的な配色ですね。

 全体としても清流は視認性・サイズともに使用価値の高いスタイルとなっています。IE6でもIE5.xでも本文の行間は許容範囲内かなと思います。これは後述の指定フォントのおかげかもしれません(本文150%)。サイドバーのマイリストのメモ欄に書き込んだ部分の行間もほど良いです( .sidebar li 150%)が、IE6だとちょっと行間が開くかな?でもトータルで閲覧できるサイズという意味で、評価は高いです。

 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで902、それぞれ200・500・200。デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。トータルの数値設定が、IE5.xのずれを考慮していて好感が持てますね。全体幅902という数値は、ごく標準的なページ幅(800)から考えると広めともいえます。IEだと「お気に入り」を表示していると、右端を見るのにスクロールしなくてはならない、というラインですね。この状態をどのように捉えるかは、サイト管理者次第ではないかと思います。

 清流の本文フォント指定( .content p)は「Georgia, Times, serif」。サイドバーのメモ( .sidebar li)は「Verdana, Arial, sans-serif」となっています。サイドバーのほうはいまいちですが、本文は多くのブラウザで快適に読むことができると思います。

 ページのヘッダ部分(#Banner)の縦幅を決定している要素は、69pxと多少余裕があります。

|

記事タイトルとアイコン

本文記事のタイトル欄<h3>にアイコン画像を表示させる方法について、「アイコンをつけてみました」(「KOROPPYの本棚」さん) で紹介されています。
この場合に、タイトルを中央あわせにするのではなく、画像の直後に表示させたい場合。


.content h3 {
text-indent: 28px;
}

 指定するピクセル幅は、アイコン画像の横幅より心持ち多めに設定すると良いでしょう。

 「詞織」では記事タイトル欄<h3>の背景をまるまる画像で指定してます。


*追記:
もともとは「KOROPPYの本棚」さん向けに書いたエントリーでしたが、さかのぼって本家の「文字書きわーるど♪」さんにもトラックバックしておきまーす。

|

タイトルのないマイリスト

反応が遅くてどーもアレですが。

 サイドバーに置く「マイリスト」はあれこれとコンテンツを詰め込めて便利な機能です。ただタイトルが一緒にくっついてきてしまうのは困る場合もあります。
 新規作成したマイリストにタイトルをつけない(半角スペース)こともできますが、当然のことながら一つっきりしか作れない。そこでおはるさんが見つけたトリビア。

 

マイリストに名前を付けつつ表示させない方法
そこで、小技マイリストに付ける名前は、
<!-- コメントアウト -->しておく。
これでマイリストの名前は分かるけど、実際には表示されない。
(「異空間==お花畑」さん)

おー、これがトリビアってやつですか?参考になりました。
上記引用記事内でのfacetさんのコメントも「へぇ~」ですよ。

|

デフォルト08:春

春はIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その5)です。
 手間をかけたくない人にはオススメです。
春3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる
 
 今まで紹介してきたデフォルトスタイルと「春」は明確に異なる点があります。それは

記事本文の入るスペース(#center)が伸び縮みする

設定になっているということです。
その他のスタイルは本文スペース+左右のサイドバーの合計という、「箱」が設定されているのに対し、「春」はブラウザの画面が広ければ広いほど「本文スペースが広がる」のです。この特徴は長所でもありますし短所でもあります。他のスタイルの本文スペースは狭い。たしかに私もそう思うことがあります。広いほうがいい、基本的にはそうかもしれません。800よりは1260のほうがいい。しかし1600だとどうでしょう?パソコン画面の広さはサイト作成者にはわかりません。考えられるケースはいくらでもあります。なんのことかわからない、という方、ためしにブラウザのウィンドウの横幅を狭くしたり広げたりしてみてください。スペース伸び縮みという特徴は、サイト製作者の意図しない「ページの見え方」を生む可能性があります。ご留意ください。

 春は本文背景(#container)色が白、本文が黒、リンク色がピンクとなっています。トップバナースペースとサイドバー・本文の背景色が全て異なっており、デフォルトスタイルの中ではもっともカラフルなデザインのひとつです。言い換えるならば、既存設定の特徴が強く、そのまま使うと「あちこちで見るデザイン」になりかねません。サイト作成者の手間のかけどころではないかなと思います。

 春は視認性・サイズともに使用価値の高いスタイルとなっています。IE6だと多少行間が空き気味に見えますが視認性に影響を与えるほどではないと思います(本文150%)。背景色がピンクのサイドバーでは、より薄いリンク色が多少目立ちにくいですが、アンダーライン付きということを考えて許容範囲内にも思えます。

 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはそれぞれ200・*(可変)・200。デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。

 春の本文フォント指定は( .content p)は「'Lucida Grande', Verdana, Geneva, Arial, sans-serif」となっています。デフォルトスタイルの中では少数派のこの組み合わせ、視認性は許容範囲内ですが「Trebuchet」系と同じく、Operaではまともなフォントで読めないという問題を抱えています。

 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が68pxと固定になっています。充分な縦幅があります。もちろんMozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性はあります。バナーは小さめに。なお、サイドバーがトップバナースペースに「めり込んで見える」のは、IEの解釈のせいみたいです。

|

デフォルト07:ルージュ

ルージュはIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その4)です。
 手間をかけたくない人にはオススメです。
ルージュ3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる
 
 ルージュは本文背景(#container)色が薄いピンク、本文が焦げ茶、リンク色が茶となっています。一言で特徴を言うと「エレガンスの色違い」ということになりますが、やはりピンクピンクしていて印象はかなり違います。背景が純白でないというのも高評価の理由です(真っ白な画面だと目に厳しいという方、多いですよね?もっとも、どピンクが目に優しいかどうかは別問題ですが…。)エレガンスの暗色系・ドドメ色系が好みでなければ、ルージュを選ぶ…そんな感じでも良いかなと思います。
 全体としてもルージュは視認性・サイズともに使用価値の高いスタイルとなっています。IE6だと多少行間が空き気味に見えますが視認性に影響を与えるほどではないと思います(本文150%)。逆に「裏エレガンス」として、エレガンスと同様サイドバーのマイリストのメモ欄に書き込んだ部分の行間はつまりぎみです( .sidebar li 100%)が、IE5.x込みで閲覧できるサイズという意味で、トータルしての評価は高いです。リンク色が多少目立ちにくいですが、アンダーライン付きということを考えて許容範囲内にも思えます。

 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。

 ルージュの本文フォント指定( .content p)は「Verdana, Arial, sans-serif」となっています。デフォルトスタイルの中では少数派のこの組み合わせ、視認性は許容範囲内ですが「Trebuchet」系と同じく、Operaではまともなフォントで読めないという問題を抱えています。いや読めるけど。ルージュの場合、崩れ系フォントを狙うつもりで使うのかな(それにしてはIEではちゃんと見えるし…)。

 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が38pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。

|

デフォルト06:ライン

ライン(ネイビー・ワイン)はIE5.xで、デフォルト設定のままでは3段カラムのページを閲覧することができないスタイルです。
 手間をかけたくない人は選択肢からはずしましょう。

ラインの見え方
ラインは好みを別にすれば、視認性はわりと良い

 ライン(ネイビー・ワイン)は本文背景(#container)色が暗色、本文が白色、リンク色がネイビー→茶、ワイン→緑となっています。本文の色は背景とあわせるならば視認性は良いです。
 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。デフォルトの状態では、IE5.xでサイドバーが吹き飛んでしまいます。
 行間は本文・サイドバーでそれぞれ150%( .content p制御)・150%( .sidebar li制御)。

 ライン(ネイビー・ワイン)の本文とサイドバーのフォント指定( .content p、および .sidebar li)は「'Trebuchet MS', Verdana, sans-serif;」となっていますので、フォントの視認性は許容範囲内だと思われます。ただこの設定だと、Operaでは非常に読みにくいフォントが適用されてしまうという問題があります。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が39pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。タイトルに画像を入れる際にはお気をつけください。

|

あああ、ええっと

cocoonさん、そんな_| ̄|○させるつもりでは…

何を言えばフォローになるのだろう。ええと、ううむ、ボックスの良いところは。うう。
あ、あった!
 cocoonさんのページは、引用文のスペースがとても見やすいですね!

 …オリジナルのスタイルでしたね_| ̄|○

|

容量と「詞織」

 容量がかさばることで一部で話題になりつつある(?)ココログですが、「詞織」も3日の朝でまる1ヶ月経過しましたので、「使用容量アンケート開催」(「SO505i Stand-by Disp」さん)にトラックバック。

 「詞織」 記事数84 コメント数151 TB数116 2.704 メガバイト (9.01%)
画像はほとんど外部リンクになっています。cssファイル・画像のココログ内総量は200kb以内のはずです。

 現時点で「書き出し」した場合のテキストファイルの容量は467kb。「詞織」の記事単体の文章量はさほど多くもなく少なくもなくくらいの容量ですので、まあ一般的なココログユーザーは「詞織」よりはゆっくりしたペースで容量を埋めていってるのではないかな、くらいの印象です。フルカワが開設時に感じた印象よりも「おもったよりは埋まるのが早くはない」かな、という感じですね。まあ1ヶ月で1割埋まってるのか、という見方ももちろんできますけれど。
 あと「詞織」はフライングデータ(ココログ開設前の記事)が少々あるので、そのへんを差し引くともう少し寿命が長いかな、という気がします。

|

デフォルト05:ボックス

ボックス(カーキ/緑)はIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その3)です。
 手間をかけたくない人にはオススメです…が、別の理由からオススメしません。詳細は下記に。
ボックス3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる。しかしフォントは見づらい
 
 ボックス(カーキ/緑)は本文背景(#container)色がカーキ/緑、本文が白、リンク色が黄系(暖色)となっています。はっきり言って本文・未読リンクともに見づらいことこの上ないです。本文色と背景色の配色についてはさまざまな意見がありますが、フォントそのものを目をこらして見るような配色というのは、少し考えものですね。デフォルトでもう少しフォントが大きかったら、別の効果も生まれるかもしれませんが。そんな中にあって、カーソルを合わせたときのリンク色のみがはっきりと目立つようになっていますが、この効果が閲覧者にとってどれだけプラスなのかは疑問です。
 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。ボックス(カーキ/緑)はボーダーで縁取りされていませんので、デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。

 ボックス(カーキ/緑)の本文フォント指定( .content p)は「'Trebuchet MS', Verdana, sans-serif」となっています。Opera以外でのフォントの視認性は許容範囲内だと思われます。エレガンスでも述べたように、この組み合わせはOperaでは許容範囲を越え、読みにくいフォントが適用されていると思います。行間は本文( .content p)およびサイドバーのマイリスト( .sidebar li)ともに150%。IE6では多少開き気味になりますが、許容範囲内といえるのではないでしょうか。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が40pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。

|

なんちゃってデフォルトスタイル

 デフォルトスタイルについてのノートも(4)まで来ました。ここまでくると、知識を持ってなくても勘の良い人はすでに気づいているかもしれません。「なぜIE5.xでは右サイドバーがふっとぶスタイルがあるのか?なぜふっとばないスタイルがあるのか?」

 とはいっても、答えはすでに「IE5.xとココログ(2)本文やメニューが下の方に表示される場合の対処法」(「insomnia days」さん)で説明されています。
 つまり「IE5.xでは右サイドバーがふっとぶスタイル」=「ページがボーダーで縁取りされているスタイル」なのですね。IE6とIE5.xではこの「幅」の計算方法が異なっており、ボーダーのピクセル数だけ「表示に必要な幅が足りなくなるため」サイドバー部分がふっとんでしまう、ということなわけです。

 スタイルは気に入ってる。邪道なかたちで自作スタイルを使うのはなんとなくいやだ。でも面倒なのは嫌いだし。という人のために、妥協策としてすべての要素をちょっとづつ使った方法についてエントリーします。「なんちゃってデフォルトスタイル」です。

*注意点
この方法は「ファイルをアップロードする」ものです。現在ココログでは一度アップロードしたファイルを消去する方法がありません。 試される前に、この点を確認のうえ自己責任でお願いします。また、ファイル名を忘れないように、cssファイルの名前は自身が忘れないようなものに変えたほうが良いと思います。デフォルトで作成されるcssファイル名(styles.css)以外なら何でも良いと思います。この点を考慮して、サンプルのcssファイルは最小限の設定のみ記入しています(1kb相当)。


 基本的な方法は「自作スタイルシートの適用」です。
1.まず以下のリンクを「右クリック>対象を保存(Macではどうやるのかわからないですが)」で、cssファイルをダウンロードしてください。名前は変えても問題ないし、そのままでも問題ないと思います。

(1)ボーダーを消しちゃった「なんちゃってデフォルト」
(2)ボーダーを残してページを微妙に広げた「なんちゃってデフォルト」
2.このcssファイルをそのまま「写真やファイルをアップロードする」でココログに送り、

3.サブタイトル欄にタグを入力します。下記の例はそのままアップロードした場合。
上記(1)をダウンロードした場合
<link rel="stylesheet" href="あなたのサイトのURL/あなたのサイトのディレクトリ名/style-site007.css" type="text/css">
上記(2)をダウンロードした場合
<link rel="stylesheet" href="あなたのサイトのURL/あなたのサイトのディレクトリ名/style-site008.css" type="text/css">

「詞織」を例にすると
<link rel="stylesheet" href="http://siolli.cocolog-nifty.com/blog/style-site007.css" type="text/css">

という感じです。
 さて「保存」して「サイトに反映」させてみましょう。選択済みのデフォルトのスタイルが表示されましたか?ほとんど変わらない?そうです。「なんちゃってデフォルト」ですから。でも、ちょっとだけ違う。そして右サイドバーは吹き飛ばないと思います。
 スタイルシートってなんだかわからん、て人も、まずはここから試してみてはいかがでしょうか。

|

デフォルト04:タイプパッド風

皆さんあけましておめでとうございます。
そして何事もなかったかのように連載続行。

タイプパッド風はIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その2)です。
 手間をかけたくない人にはオススメです。
タイプパッド風3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる
 
 タイプパッド風は本文背景(#container)色が白、本文が黒、リンク色が青系(寒色)となっています。いわゆる昔ながらの配色で、多少地味という面はありますが視認性・サイズともに使用価値の高いスタイルとなっています。IE6だと多少行間が空き気味に見えます(本文140%、サイドバーのマイリスト150%)が、IE5.x込みで閲覧できるサイズという意味でも、評価は高いです。

 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。

 タイプパッド風の本文フォント指定( .content p)は「'Trebuchet MS', Verdana, sans-serif」となっています。Opera以外でのフォントの視認性は許容範囲内だと思われます。エレガンスでも述べたように、この組み合わせはOperaでは許容範囲を越え、読みにくいフォントが適用されていると思います。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が39pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。

|

プロフィールページからの「戻る」リンク

みなさまの来年が良き年でありますように。ささやかな小ネタをひとつ。

 プロフィールページは通常ですと、扉ページへ「戻る」リンクがついていません。
たいていのブラウザの場合、ブラウザそのものの「戻る」ボタンで戻ることになりますが、どうしてもページ中に「戻る」リンクをつけたい場合、以下のような方法があります。

1.プロフィール末尾にリンクタグを貼り付ける

 たとえば下記のようなタグを自己紹介欄の末尾に貼り付けましょう。
 <p><a href="あなたのココログのURL">扉に戻る</a></p>

 なにせプロフィールの中に書き込むものですから、余計なデータが混入していると言えなくもありません。

2.マイリストで「戻る」リンクを作り、「プロフィールページの設定」で貼り付ける

 マイリストでタイプ=リンク、タイトルに
 <a href="あなたのココログのURL">扉に戻る</a>

 というマイリストを作成します(マイリストのタイトルのみ作成)。
 この方法の問題ですが、マイリストのタイトルは全角半角あわせて50文字しか入れられません。なのでURLをフルに入れることはできません。ですので相対リンクとして

 <a href="あなたのココログのindex.htmlの相対リンク">扉に戻る</a>

 を指定します。「詞織」の場合ですと

 <a href="blog/index.html">扉に戻る</a>

 となっています。
 便利な「タイトルのないマイリスト」をまだ使っていない場合、むりやりマイリストのタイトルに押し込まずに
タイプ=リンク、タイトル名=無名(半角スペースでもOKかな)として、リストとして

 <a href="あなたのココログのURL">扉に戻る</a>

 としてもよいかもしれません。

2004.01.07追記 マイリストのタイトルについて「タイトルのないマイリスト」を別記事としてエントリーし紹介してます。

|

デフォルト03:システム

システムはIE5.xで、デフォルト設定のままでは3段カラムのページを閲覧することができないスタイルです。
手間をかけたくない人は選択肢からはずしましょう。

システム3段の見え方
本文背景・本文フォント・既読リンクはIE5.xではこんな感じ

 システムは「無地」に次いで無個性なスタイルです。本文背景(#container)色が白、本文が黒色、リンク色が茶色/オレンジとなっています。既読リンク色が多少未読リンクより目立つのが問題かもしれません。
 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。デフォルトの状態では、IE5.xでサイドバーが吹き飛んでしまいます。
 行間は本文・サイドバーでそれぞれ200%( .content p制御)・150%( .sidebar li制御)。エレガンスとは異なってサイドバーの文字も視認しやすいのですが、それと引き換えに右サイドバーがふっとぶ可能性を秘めています。また本文の行間が開いているので、IE6などでは逆に読みにくくなるかもしれません。

 システムの本文とサイドバーのフォント指定( .content p、および .sidebar li)は「Georgia, Times, serif」および「Verdana, Arial, serif」となっていますので、フォントの視認性は許容範囲内だと思われます。ただしサイドバーが多少大きめになるようで、サイドバーが吹き飛ぶ原因でもあります。またこの設定だと、Operaではサイドバーのほうに非常に読みにくいフォントが適用されてしまうという問題があります(本文は問題なし)。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が69pxと固定になっていますが、他のスタイルに比べて比較的タイトル(サブタイトル欄)に画像を入れやすいという特徴があるかと思います。もちろんこの規定幅を超えてしまうと、画像やサブタイトルが見えなくなる可能性は残っています。

|

デフォルト02:クリスマス

クリスマス(緑・赤)はIE5.xで、デフォルト設定のままでは3段カラムのページを閲覧することができないスタイルです。
 手間をかけたくない人は選択肢からはずしましょう。

クリスマス3段の見え方
修正を加えないと、IE5.xでは右サイドバーがページ下部に飛んでしまう

 クリスマスは本文背景(#container)色が白、本文が灰色、リンク色がクリスマス緑→渋い赤、クリスマス赤→緑となっています。本文の色が多少薄めなのが問題といえば問題です。
 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。デフォルトの状態では、IE5.xでサイドバーが吹き飛んでしまいます。
 行間は本文・サイドバーでそれぞれ150%( .content p制御)・150%( .sidebar li制御)。エレガンスとは異なってサイドバーの文字も視認しやすいのですが、それと引き換えに右サイドバーがふっとぶ可能性を秘めています。

 クリスマスの本文とサイドバーのフォント指定( .content p、および .sidebar li)は「'Trebuchet MS', Verdana, sans-serif;」となっていますので、フォントの視認性は許容範囲内だと思われます。ただし多少大きめになるようで、サイドバーが吹き飛ぶ原因でもあります。またこの設定だと、Operaでは非常に読みにくいフォントが適用されてしまうという問題があります。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が40pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。タイトルに画像を入れる際にはお気をつけください。

|

デフォルト01:エレガンス

 しばらく集中連載のかたちで、デフォルトのスタイルについて個別にまとめていくことにします。余裕があれば、自作スタイルシートを適用させる場合の注意点も追加していきたいと思っています。
 記事の関心はおもに「閲覧者が製作者の意図したようなデザインで読めるかどうか」にあります。そのため本文の色・サイズ、段組レイアウトの安定という2点がポイントになっています。
 記事中のカッコ内には、当該のスタイルclassもしくはid名を表示しました。自作スタイルを作成する際の参考にしてください。

 まずエレガンスから始めるとしましょう。

 エレガンスはIE6/5.x双方で3段カラムのページを閲覧することのできるスタイル(その1)です。
 手間をかけたくない人にはオススメです。

エレガンス3段の見え方
修正を加えなくとも、IE5.xで3段組として閲覧できる
 
 エレガンスは本文背景(#container)色が黒、本文が白、リンク色が白(下線付き)となっています。本文とリンクを区別するのは下線のみなので、これを消してしまうと閲覧者はリンクを探すことが難しくなります。
 本文記事が挿入されるスペース(#center)と左右のサイドバーのスペース(#left/#right)の長さはトータルで800、それぞれ200・400・200。デフォルトの状態ではサイドバーが吹き飛ぶことはないと思います。
 行間は本文・サイドバーでそれぞれ150%( .content p制御)・100%( .sidebar li制御)。なぜかこの「エレガンス」では、サイドバーテキストの行間(line-height)に余白がなく、指定されたfont familyではサイドバーのテキストの行間が詰まって見えてしまいます。リストにメモをつける場合はご注意ください。

エレガンスの解説図
左図はIE6、右図はIE5(推測)の見え方

 IE5でフォントが大きく表示されても、レイアウトがくずれるところまではいきません。むしろIE6でもIE5でもサイドバーの行間が詰まりすぎている方が問題かもしれません。この問題の原因についてすでに記したように、デフォルトのスタイル指定の不徹底にあるようです。
 エレガンスの本文フォント指定( .content p)は「Georgia, 'Times New Roman', serif」となっていますので、フォントの視認性は許容範囲内だと思われます。
 他の問題点としては、ページのヘッダ部分(#Banner)の縦幅を決定している要素が38pxと固定になっていますので、Mozillaなどのブラウザではタイトル・サブタイトルの下半分が隠れて見えなくなってしまう可能性があります。

 その他のエレガンスの特徴として、「タイトル・サブタイトルが中央寄せになっている」点が挙げられるかと思います。自作スタイルを適用せずにこの特徴を生かしても良いかもしれません。

|

デフォルトのスタイル

insomnia days」のうえださんからのコメントをきっかけにして、ココログのデフォルトのスタイルの特長について調べてみました。焦点は「本文とリンク、サイドバーのフォントサイズ/カラー」です。テキストをメインとするページを作るなら、最低限この部分が「読める/使える/許容できる」必要があるはずです。

 一覧の読みかたですが、「スタイル名:スタイルID content.pのフォント指定におけるserif/sans-serif」となってます。

エレガンス:serif

 黒地に白色リンク→アンダーラインを消すと本文との区別つかず
 本文→行間は許容範囲内だが、サイドバーの行間がつまっていて文字列が重なる。
    また本文の文字間が多少広いので読みにくい可能性がある
 
クリスマス:sans-serif

 白地に彩度の高い暖色・暗色リンク→視認性は許容範囲
 本文→行間は許容範囲内。ただフォントカラーが淡く、視認性には優れない
 
システム:serif

白地に彩度の高い暖色系リンク→視認しづらい
本文→行間が空きぎみ。フォントサイズが小さめなので視認性はさほど良くない

タイプパッド風:sans-serif

 白地に寒色リンク→慣習的なカラーで視認性は良い
 本文→視認性は良い。デフォルトのスタイルの中ではもっとも良いバランスでは。

ボックス:sans-serif

 正直読みづらい。
 淡色地に彩度の高い暖色リンク→大きいフォントを指定しないとつらい。
 本文→地が淡色なのに本文フォントは白色なので、よっぽど大きいフォント・短い記事でないとつらい気がする。

ライン:sans-serif

 暗地に彩度の低い暖色リンク→目立ちにくいが区別そのものはつく
 本文→行間・フォントサイズ・文字間ともに許容範囲内。静かな印象を与えるページが好みの場合は選択肢に。

ルージュ:sans-serif

 ぴんくページ。
 うすピンク地に茶色フォント。本文は読みやすいがリンク色のほうが薄いので目立ちにくい。
 本文→行間・フォントサイズ・文字間ともに許容範囲内か。
 
春:sans-serif

 デフォルト状態でサイドバーがヘッダにめり込んでるのは仕様ですか???
 白地に暗色フォント。本文は読みやすいがリンク色はピンクなので好みが分かれるか。
 本文→行間・フォントサイズ・文字間ともに許容範囲内か。
 
清流:serif

 他のスタイルに比べてページ幅が広いので好き嫌いが分かれそう。
 カラーは慣習的なものに近いので安全牌とも言える。
 
無地:sans-serif

 ページ幅は上記「清流」に同じ。
 なぜかこちらは行間の空きが目立つ。視認性はより悪くなっているかも。
 カラーは問題ないが、当然ながら無個性。
 
@nifty1:sans-serif

 おれんじページ。いまどきこのカラーで攻めるユーザーがいたら、かなりアグレッシブな気がします。
 オレンジは意外と黒色フォントを強調しないので、視認性はそんなによくありません。
 リンク色は彩度の高い暖色系で、リンクをとにかく目立たせたい場合はいいかも。
 行間・文字間は普通、許容範囲内か。
 
@nifty2:sans-serif

 「システム」の強調色をオレンジにした感じ。与えるイメージも似たような感じに。
 フォント指定が「システム」とは異なっているので、好みに応じて選択できるかも。
 ただ半角アルファベットの視認性は「システム」より悪い感じがします。
 
M▲TRIX:sans-serif

 まあマトリックスな感じの配色ですが。
 @nifty 1とは対照的に、彩度の高いグリーンの本文が異様に目立ちます。
 リンク色の彩度が低いので、とにかく本文記事を目立たせたい場合は良いかも。
 

 いくつかのスタイル(清流など)ではサイドバーのフォントサイズが尋常じゃなく小さくなります。IE6など新しいブラウザを使われている場合は、デフォルトで大きめなサイドバーフォントを用いているスタイル(@nifty1/2とかシステム、M▲TRRIXなど)を選択すると良いかもしれません。逆にIE5.xを考慮に入れる場合、気を抜くと(本文フォントの大きさのため)右サイドバーが下にふっとんでしまいます。あちらをたてればこちらがたたずです。清流や無地などはIE5.x向けのスタイルといえるかもしれません。
 「フォントを大きくして、かつ右サイドバーがふっとばないようにしたい!」場合は、やはりある程度自分でいじる必要があるかもしれませんね。現状のところ。

 夜中にこんなことを調べているとふらふらになってしまいました。私もやはり「孤独で寂しい人間」でしょうか^^;(まあ自己紹介でも「世界の果てに流された」って言ってるし…)
 ぼくもう眠くなっちゃったよ、パトラッシュ…。

|

積極性とユーザー取り込み

Curryさん、今まで「ココログル」をとても便利に使用させていただきました。ありがとうございます。「新規記事情報取得一時停止」については、ハードウェアの限界から言ってもCurryさん・利用者ともに事前に予想できたことだと思いますので、今回の措置も自然な流れではないかと思います。いち素人としては、ここしばらくのココログユーザーの増加数を考えると、個人所有の機器ではほとんどの試みを長期的には維持できないのではないかと思っています。とりあえず「詞織」サイドバーのリンク部分をとめておきました。「ココログル」再開をいち個人として願っていますが、ご無理をなさいませんように。

記事件数増加のため、これ以上検索にかける時間が長くなると、検索プログラムが動かなくなる可能性があります。(「健康な生活を送ろう!」さん)

 このトピックの経緯や周辺情報について、下記のサイトでも触れられています。

ココログル停止(「StarChartLog@cocolog」さん)
ココログル停止に思う(「ぴっくあっぷ」さん)
何とかならないものか(「風の吹く街」さん)
ココログル、一時、新規登録停止!(「あそびをせんとやうまれけむ」さん)

 「ココログル」のような検索サービスを付加することが企業にとってどれほど負担になるかはわからないのですが、現状の「ココログ」ユーザー(あるいは@niftyユーザー)にとって、またISP側にとってもサイト横断検索システムは必要なのではないだろうか?といちユーザーである私は思います。
 日本国内においてウェブログユーザー層を拡大させた「はてなダイアリー」は「キーワード」というシステムを採用することによって、実質的に「はてなダイアリーサイト」内の横断検索を実現させています。このシステムによって、ユーザーは自分の興味のある話題がどのサイトでも取り上げられているかを知ることができます。
 あるいは、先日「infoseek」「livedoor」のように、すでに一定規模のコミュニティを作ることに成功している他ISPがウェブログサービスを開始したり、そのような方向に向かうことを宣言しているのが現状です。むろん@niftyがこのような動向を視野に入れていないとは思いません。ですがあえて言うならば、@niftyは既存の「フォーラム」「@homepage」などで作り上げてきたユーザーネットワーク層を活用する方向で顧客層を拡大するための手を、もっと打っても良いのではないでしょうか?

 フルカワは「接続するためだけに@niftyを利用していた」一般的な会員のひとりです。このような人間は、すでに@nifty内のコミュニティに加わっているひとたちとは異なって、自分から積極的にネットワークの一端を形成する力をほとんど持っていません。現状では「トラックバック野郎」に代表されるように、ツール自体の有効性を啓蒙する方向でコミュニティの自己形成を促している段階なのかもしれませんが、多くのユーザーが自然な感想として述べているように、トラックバックそのものは「現状のココログでは」単なる逆リンクにしか過ぎません。それはコミュニティ(あるいは、社説となりうる複数のメディア=ココログサイトと、それを定期的に閲覧しリアクションする読者層)が成熟したのちに本領を発揮する仕組みだと思います。

 「つながっていく」だけではなく、「つなげていく」…@niftyがユーザーに求めているのは、自然発生的なユーザー層の活発化なのかもしれません。それでも、@niftyがより積極的になることによって、より多くのユーザー層を呼び込める機会が、今、この「検索機能」を焦点にして明確に見えてきてはいないでしょうか?

イブ、会社でスタッフblogを書いてます。

これからも、ご期待に添えるようなコンテンツ、機能の準備を進めてまいります。
これからもココログをよろしくお願いします。(「ココログスタッフルーム」より)

 私たちユーザー層と@nifty双方にとって、「特定の機能の」充実は利益になると思います。現状での機能追加が未定なのだとしても、@nifty側から「検索機能」が提供されることを願ってやみません。@niftyの今後の動向に、期待しております。

 (生まれてはじめてサービス提供元に要望を述べてしまいました^^;)

 追記:「ココログル停止」(「健康な生活を送ろう!」さん)のコメント欄によると、現在ココログルはベータ4となって再稼動しているようです。Curryさんはやっ!「詞織」でも様子を見てサイドバーのリンクを復活させたいと思っています。

|

IE5.x系とココログ

 以前から話題になっていた「IE5.xでの表示の不具合」について、「insomnia days」さんからトラックバックをいただきました。

IE5.xとココログ(1)

 「なぜ右サイドバーが下にいってしまうのか」「なぜフォントが妙に大きいのか」といった現象の理由について、上記リンクで解説されていますのでご参照ください。参照示唆されている「娘娘飯店しるきぃうぇぶ」さんとともに、わかりやすい解説記事になっていると思います。

 さて「詞織」では、とりあえずIE6で動作確認をしていますが、ソースをいじることによって「IE5.x系のようにページを表示させることができる」ことがわかりましたので検証してみました。

20031225e.jpg

 左図がIE6での「見え方」、右図がIE5.x系での「見え方(推測)」です。5.x系のほうがサブタイトル・記事タイトル・本文のいずれも大きいことが確認できるかと思います。
 
 「詞織」ではこみいった内容を解説するというスタンスをもちませんので^^;、興味のある方はまず上記サイトで理屈と修正の仕方をチェックされたほうが良いかと思います。

 今回は、とりあえず「詞織」的手抜き修正方法を書いておこうと思います。

・大きすぎる本文のフォントは「small」のままにしておく
 自作スタイルを適用されているかたも、本文のフォントサイズはデフォルトの指定のままのほうが楽かと思います。5.x系では多少大きくなるものの、上図くらいの差異で収まるかと思います。

 →まっとうな修正方法:「IE5.xとココログ(3)文字サイズが大きくなりすぎる場合の対処法」(「insomnia days」さん)

・右サイドバーが下にふっとんでいってしまうのを避けるため、左サイドバー・本文・右サイドバーの合計の長さを心持ちデフォルトより短くする
 たとえば「詞織」で使っている「システム」の場合、左サイドバー・本文・右サイドバーの合計の長さは800pxと指定されています。「詞織では195・390・195と指定してあるので、スタイルが適用されている限りは右サイドバーが吹っ飛んでいないと思います。面倒な人は、スタイルシートの#left・#right・#centerのところにある数値200・400・200を195・390・195に代えてみましょう。とりあえずこれでなんとか。(超適当です)
 なお「どうもサイドバーの余白が気になるからpaddingを減らして文字数多くしちゃえ、えいえいっ」とやっちゃった人はもう少し正確に調整する必要があると思いますので、リンク先を見てがんばりましょー。

 →まっとうな修正説明:「IE5.xとココログ(2)本文やメニューが下の方に表示される場合の対処法」(「insomnia days」さん)

 「詞織」では記事タイトルを「normal」指定→「120%」指定に代えて、とりあえず良しとしております。

|

ココログル3に対応(一部)

Curryさん提供の「ココログル」ベータ3の運用開始にともない、今までオリジナル分類だった「詞織」のカテゴリをデフォルトのカテゴリにあわせました…一部だけ^^;

 とりあえず「about_blog」→「ウェブログ・ココログ関連」にしました。ほかのカテゴリは…うーん、既存のカテゴリだと違和感を感じるな、ということでオリジナルのままです。「diary」は別に日記目当てで「詞織」を探す人がいる可能性も考えにくいし、あえてヒットしにくいようにオリジナルのカテゴリのままで。
 ベータ3でディレクトリ検索ができるようになったことで、ココログユーザーも自然とデフォルトのカテゴリで記事をエントリーするような傾向が強まるかなと思います。

|

Tips紹介における「詞織」のスタンス

*この記事はマイリスト「ココログベーシックをいじる」のための前説です。
 WEBページ作成におけるある程度の知識を持ち、タグ記述の妥当性・非妥当性を意識されている方のための「ことわりがき」を兼ねたリンクとなっています。
HTMLとXHTMLの区別や、スタイルシートの仕組みについてよく理解されていない方は、とばされて良いと思います。

  「自作スタイルシートの適用」に代表されるように、当「詞織」で紹介しているココログ用Tipsの中には、いわゆるXHTML文法的な観点からするとinvalidな、妥当でないものが含まれています。
 「詞織」では上記の点について知覚しつつも、あくまで「とりあえず手軽にサイトの見かけを変える」ことを目的として、上記のようなinvalidなTipsを掲載しています。ココログベーシックはテンプレートをまったくの任意に変更することができないため、その上であえてデザインを変えたい人に向けた記事であるとご理解ください。
 このinvalidなTipsを掲載し続けることについての是非に関して、「詞織」上ではvalidnessを重視される、専門知識をお持ちの方たちとの対話がありました。

 今後、このvalidnessという話題について当「詞織」で取り上げることはないと思いますし、個別記事に「これはvalidではない」という主旨のトラックバックを付けていただきましても、特にご返答差し上げることもないと思います。また現行のシステム上の制限(容量30メガ)という点からも、このようなトラックバックは削除する可能性が高いと思います。invalidな「適用」に対する改善案を提示していただいた場合はその限りではありませんが、「詞織」の管理人であるフルカワは専門知識を持たず、噛み砕いてさらに他のかたに説明できるような内容でない場合(極度に専門的なTips)であっても、同様の結果になる可能性が高いと思います。

 ですので、そのような立場にある方がトラックバックをされる場合、以下の関連記事に目を通して、そのうえでトラックバックしていただけるかどうか決めていただければと思います。


・「適用」をエントリーした時点でのフルカワの狙い
 ようやく一息。
・valid:invalidに関する、「詞織」での対話の流れ
 (まとめ)validに関する対話の流れ
・対話を終えた時点での、フルカワのスタンスの再表明(この記事は上記の「流れ」を読んだ上で目を通していただければと思います。)
 invalidにこだわってるわけじゃないけど

|

おや?

現在(日本時間a.m.3:00すぎ)、ふと気づくとタイトル裏の背景(back.jpg)とプロフィールの写真(top.jpg)が通常の画像に戻ってます。クリスマス用に直したんだけどな。cssは変更後のものが適用されていたので、そちらを通常版に戻して再アップロード。サーバー側で何かやってるのかな?

追記:そしてa.m.4:00前には復旧。謎。

|

ココログ用巡回エクステンションと詞織

結果的に同じ記事に二種類のトラックバックを送ることになってしまったりしました。

この記事は「本格焼酎忘備録」さんが提供されている、掲示板巡回ツールCMNのココログ用巡回エクステンションについての報告です。
 しばたにさんは「エクステンション巡回上の仕様制限」において、

私の作成したエクステンションではサブタイトル欄をふたつに分けているケースでは正しくサブタイトルを取得することができない場合があります。 (中略)サブタイトルの内容・その2に関しては取得不能な場合があります。現在いろいろと調整中ですが、すぐの対応は難しいかもしれません。また、巡回ソフトを利用している人への配慮をして頂けるようでしたら、サブタイトルの内容・その2については読めない人もいることを前提とした内容として頂ければありがたく思います。
と発言されました。その後追記で
できないかもしれないとか書いたのに意外と早くできたかもしれないf^^;) たぶん大丈夫だと思うのですが、その代わりだいぶサブタイトルのイメージ関わってしまいました(;^^A

 とされ、実験台報告を求められています。「詞織」でもこのツールでまっとうに見えるかどうか、検証してみました。

以下は「詞織」でよく使っている3パターンの「サブタイトル欄記入方法」での報告です。

1.自作スタイルのためのlinkタグを単純にサブタイトル欄にいれ、<h2>タグは既存のまま一つだけ使用する場合
20031222a.jpg

 背景画像は自作スタイルで指定してあるものです。画像があるため見づらいですが、スタイルが適用されているという特徴はあります。ただし、フォントは変更されていません。

これに対応するソースは以下のような感じです。

<link rel="stylesheet" href="http://siolli.cocolog-nifty.com/blog/style-site006.css" type="text/css"><a href="http://siolli.cocolog-nifty.com/blog/"><img alt="詞織(si olli)扉へ戻ります" src="http://siolli.cocolog-nifty.com/blog/siteimg/banner.gif" width="200" height="40" border="0" /></a><br />si olli novae historiae…

2.自作スタイルのためのstyleタグを単純にサブタイトル欄にいれ、<h2>タグを強制的に挿入して二つに分割する場合
20031222b.jpg

 自作スタイルで指定してある背景画像は表示されません。h2要素のサブタイトルは大きく表示されていますが、これがスタイル適用の結果かどうかはよくわかりません。「詞織」で使用しているスクリプト指定方法はCSS2準拠なので、CMNがこの指定方法を反映させていない、という可能性が高いと思われます。

(タイトル画像:h2要素その1)<img alt="詞織(si olli)扉へ戻ります" src="http://siolli.cocolog-nifty.com/blog/siteimg/banner.gif" width="200" height="40" border="0" /></a></h2>
<style type="text/css">
@import url(http://siolli.cocolog-nifty.com/blog/style-site006.css);
</style>
<h2>(サブタイトル:h2要素その2)si olli novae historiae…

3.自作スタイルのためのlinkタグを単純にサブタイトル欄にいれ、<h2>タグを強制的に挿入して二つに分割する場合
20031222c.jpg

 自作スタイルで指定した背景は適用されています。またh2要素のサブタイトルも大きく表示されています。もちろんこのフォント指定が自作スタイルの影響なのかどうかはよくわかりません。

(タイトル画像:h2要素その1)<img alt="詞織(si olli)扉へ戻ります" src="http://siolli.cocolog-nifty.com/blog/siteimg/banner.gif" width="200" height="40" border="0" /></a></h2>
<link rel="stylesheet" href="http://siolli.cocolog-nifty.com/blog/style-site006.css" type="text/css"><h2>(サブタイトル:h2要素その2)si olli novae historiae…

 よって、現在の当該エクステンションについて、h2要素が二つに分割されてもどちらも表示されている、ということはいえるかと思います。
 上記の3例のうち、どれが「よりまし」であり他がそうでないのか、フルカワには判別できませんが、CMNでは「詞織」はこのように表示されるんだー、と思いました。

 なお、自作スタイルのためのタグを入れずに1.(h2要素非分割)と2.(h2要素2分割)を行った場合、前者は背景画像なしでh2要素は大フォントにならず、2.は背景画像なしでh2要素は大フォントになりました。大フォントになるのはスタイル誘因ではなく、エクステンションの指定ということになりそうです。
 検証例1.と3.はヘッダにlinkタグが入っているので、CMNで強制的にスタイルが適用されてしまって見づらいといえば見づらいということになるでしょうか。個人的には、特に害もないような気もします(記事に適用されてるようなら困るでしょうけどね)。

 2.の結果が「スタイル未反映」を意味しているのだとしたら、可読性の問題からも「詞織」では2.の方法を採用するほうが良いようには思いましたが、なにせCMNユーザーではないのでそのへんはよくわかっていないのでした。

|

(まとめ)validに関する対話の流れ

(注:この記事はあくまでフルカワの視点での流れです。皆様は批判的に検討する自由を保持しています)

 「観測気球」さんがリンク集を作られるご様子なので、それと対応する「詞織」側の年表・リンク集を作ることにしました。

2003.12.02:@nifty、「ココログ」サービス開始

2003.12.03:フルカワ、「ココログ」サービス開始に気づいて登録する

2003.12.04:フルカワ、「適用(1)」をエントリー

2003.12.04:「適用(1)」に対して批判的なスタンスである「自分で定義したスタイルシートを使う方法@ココログ」(「凹日記」さん)がエントリーされ、フルカワがこの記事を見る。

2003.12.05:「適用(1)」に対して批判的なスタンスである「サブタイトル欄でやってはいけないこと」(「風のまにまに心のままに」さん)がエントリーされ、フルカワがこの記事を見る。なおそれまでにも、批判的なスタンスのトラックバックが複数存在する。この時点までは、フルカワはこのようなスタンスのトラックバックを閲覧後削除していた。
 「凹日記」さんと「風のまにまに心のままに」さんの記事を見ながら、フルカワは「適用2」「適用3」といった形でそれぞれの記事に関連した記事、あるいは紹介を行う。

2003.12.09:ぽつぽつとやってくる、「批判的な・しかし改善策を提示してない無意味トラックバック」がうっとうしくなってきたフルカワが、「ウェブログと情報操作」、翌日付で「Weblog使用とスタンス」をエントリー。not validなやり方をなぜ紹介するのか、なぜ無意味トラックバックを削除するのか、その理由を説明。フルカワはこの時点で、「無意味トラックバック」もとりあえず速攻で削除しないようにしておく、と表明した。フルカワ、プロフィールページに「トラックバック・リンクへの対応について」と題した一節を追加。

2003.12.11:自分で定義したスタイルシートを使う方法@ココログ その3」(「凹日記」さん)がエントリーされ、フルカワがこの記事を見る。フルカワはこの記事を読んで「適用4」として紹介。

2003.12.17:@nifty、「ココログ」サービスを外部(新規会員)に向けて開放。

2003.12.17:「観測気球」さん、ココログを開始。

2003.12.19:「適用(1)」に対して批判的なスタンスである「スタイルシート」(「観測気球」さん)がエントリーされる。tsupoさんはこの記事のトラックバック先として「適用(1)」を指定。フルカワが「最近のトラックバック一覧」からこのトラックバックと記事のことを知る。(この時点では、フルカワは「観測気球」さんのトラックバックを、前述の「無意味トラックバック」と理解)
 フルカワはこの記事を読んで、tsupoさんが単に

「詞織: 自作スタイルシートの適用」のように「サブタイトル」に埋め込む方法は、Validator でチェックすると “document type does not allow element "style" here” というエラーになってしまいます。<style> は <head> ~ </head> の間にしか置けません。だからといって、「サブタイトル」にむりやり <head> をつっこんで <style> を入れている人もいるようですが、ひとつの html ファイルの中に <head> が複数存在するのは変です。(「観測気球」さん。強調はフルカワ)

 という形で、特に意味のない(ネガティヴリンクとさえ思われかねない)リンクをしていることに「もにょっ」とした気分を感じる。

2003.12.19:「観測気球」さんのトラックバックに、「ひょっとしてこの人を含む、無意味トラックバックをしてくる人たちは私が意図的にnot validな方法を記事として書いていることに気づいてないのだろうか?」と考えたフルカワは「提案と改善案」をエントリーする。

2003.12.20:validな方法で自分の作ったスタイルシートを使うことに成功」(「観測気球」さん)がエントリーされる。tsupoさんはこの記事のトラックバック先として「適用4」を指定。フルカワが「最近のトラックバック一覧」からこのトラックバックと記事のことを知る。
 この記事を読み、フルカワは

で、Validtor にかけてたところ、無事 Valid のお墨付きがもらえました。やったね!(「観測気球」さん。強調はフルカワ)

 という部分を読んで「もにょっ」とした気分を感じる。
(注:この「もにょっ」とした気分は、tsupoさんがよく言われたような「悪意を感じた」からではなく、validatorをもってきたことと「やったね!」という部分に対してもやもやした気分を感じたのだと自己分析します。)

2003.12.20:気力ゲージがゼロ近くまで落ち込んだフルカワが「無題」をエントリー。この時点では放置して寝ようと思っていた。

2003.12.20:フルカワが復活して「適用4とその周辺」をエントリー。「validな方法で自分の作ったスタイルシートを使うことに成功」に対して、その記事の問題点と、当該記事を含めたvalidな記事を参照しない人間が存在する可能性を、「ばかばかしい・むなしい論駁と思いつつも」書いた。
(注・この論戦そのものの「無意味さ」については、すでに各方面から指摘されてます。こちらとか。もちろん、エントリーした本人さえ「無意味な・ばかばかしい」討論だと思ってるわけですから、なにをかいわんや、ということで)

 この記事のコメント欄でのやりとりで、tsupoさんは「validな方法で自分の作ったスタイルシートを使うことに成功」に対してフルカワが投げかけた「オリジナル性への疑問」「validなページという点への疑問」について、フルカワを説得することができず。両者がお互いに自身のスタンスについて主張しあっているだけであることがお互いに確認される。そのことは、コメント欄でのtsupoさんの

別に誰かを説得しようとしているわけではなくて、invalid なページは他人に迷惑をかける可能性が高いですよ、って言っているだけなんですけど。

にあらわれていると、フルカワは考えた。
これに対し、フルカワは(説得する目的がないんなら、なぜすでにいくつも同じように批判的意見のぶら下がっているトラックバックに新たにトラックバックを付け加えたんだろう?なにかより新たなオブジェクションをぶつけるつもりではなかったのか?フルカワがなぜ「迷惑をかける可能性」について触れつつもあえてinvalidなやり方を紹介しているのか、どれだけ繰り返して言えばいいのか?反駁されたら「いやこれは説得じゃないから」てのは逃げてないか?つかこの人はフルカワの話なんざちっとも聞いてないんじゃないのか?)などと思い、気力が下がる。さらにそれまでは見出せなかったスタンスである(そしておそらくはココログユーザーの大多数の代表であろう)「ボヤキ不定期投稿」さんが記事「スタイルシート」にて、

「私が先にやった」、「あんたのは人のまねだ」とか、
良く分からない世界になっている、
私は、地道に
 "HTMLタグ" だけでやろートッ !!(「ボヤキ不定期投稿」さん)

 とのコメントにフルカワの気力ゲージがゼロになり(void! ^^;)、この実りのない対話を終わらせようと考える。

2003.12.21:フルカワ、「validとinvalid:反応リンク集」および、自身のスタンス表明の再確認ともいえる最終報告「invalidにこだわってるわけじゃないけど」をエントリー。同時刻ころ、tsupoさんが別サイト(かな?)「Activity Memo」において「ココログでの議論」をエントリー。「試合後のエール交換みたいなもの」をお互いが行う。両者の討論は、これらの記事をもってほぼ終了した。

(追記)トラックバックしていただいた「観測気球」さんの「ココログで独自スタイルシートを使う方法 関連リンク集」では、tsupoさんの視点からの流れとこの件に関する多くのリンクがきれいにまとめられていますのでご参照ください。

|

invalidにこだわってるわけじゃないけど

「validなページか?そいつぁcoolだ。で、そいつはIEで見えるのかい?」

 このネタ続けるの飽きました、っていえない性分なんですよねえ。一区切りつけることができそうでほっとしてます。
で、話はここ数日の記事から続いてます。ひとはvalidなページを作るべきか否か。正直言いましてそんなことを考えてHP作ってるひと、今どれくらいの割合なんでしょうね。私は小市民なのでできるだけvalidに近づけたいとは思ってますが、invalidなページが「本当に見えないのかどうか」確証がないので、完全に従ってもいません。

 そもそもこの3段カラムの「詞織」はNetscape4.7では見れませんし。確認までしてますし。でも放置してますし。

 私は全てのブラウザで見れるページをつくろうなどと「だいそれた」ことを考えたことはありませんし、他方で「見れない人が(理論的にも)確実に存在する」ことを疑ってもいませんが、正直「いち個人の私にそこまで求めるか?」て気分です。私は個人的にココログで楽しみたいのです。ネットワーク上のバリアフリー運動に青春をかけてはいません。

 そもそもvalidnessを主張される方々が働きかけるべきなのは、ソースを勝手に書き換えるシロウトではなく、W3Cとかマイクロソフト社とか各ブラウザ提供元ではないのかな?タグを直接打ち込まずにブラウザ画面で全ての設定をいじれるのならば、勝手に書き換える人間というのは自然と少数になると思います。ロビィ活動や啓蒙活動をするなら、まず侍大将を狙ってください。足軽狙ってる場合じゃないです。
 
 そして「主義者」さんたちが御旗に掲げる「世の中IEやOperaやNetscapeで見てる人ばかりじゃない」ですが、これももう私10人以上にはそのコメントとともにリンクされたような記憶があります。

 で、どのブラウザでは見れないんですか?証明お願いします。
 データ証明無しのテーゼは単なる机上の空論です。ぜひ証明をば。
その場合、私は提示してもらったブラウザを、自分で導入するなりしてみて、さらにどのように適用させるか考えたいと思ってます。(今のところ、放置気味ですが^^;)

 私が「適用1」と「適用4」を併記して、かつ「適用1」を採用している理由ですが、「現状において適用4を用いるより適用1を用いた方がサイトを見れる人が多い」という、ごく単純な理由です。「適用4」の、validな、JavaScript制御されたスタイルシートのページを見れる人よりも、「適用1」の,invalidな、bodyにlinkタグをつっこんだページを見れる人のほうが多いのです。マイノリティを排除するな!仰せの通りです。ではマジョリティは排除してもよかとでしょうか?現状ではinvalidな「適用1」のほうが全体的な視認性が高い、というのが私の判断です。


 「世の中IEじゃなくOperaじゃなくNetscapeじゃなくMozillaじゃなく…そのほかのブラウザを使っている人ばかりじゃないんです」。なんだか衒学的コメント返し。

 まあ、この対話での実りがそろそろなくなってきたみたいだし、話が続くかどうかはビミョーですね。

|

validとinvalid:反応集リンク

 信仰告白か、あるいは相互コミュニケーションのための導入としての発言か?

 validかinvalidか?なんて、究極的には重要でないと思っているフルカワですが、足を踏み入れてしまった以上はやはり正面から考えて答えを出すしかないでしょうか…と思いながら、ここ数日はこの話題についての反応をチェックしてました。とりあえず一段落のついたと思われるこの話題のまとめとして、目に付いた限りでこのテーマに言及した記事をクリップしてみます。

・作成ページはvalidであるべきだ派
 「観測気球」さん
  ここしばらくフルカワの討論相手となってらっしゃったサイトさん。「validであるべき」「そうでないサイトにはvalidであるべきと伝えるスタンス」とのことです。ここ数日のやりとりで、フルカワは「そうであるべきかもしれないが、現実問題として『べき』が難しい場合にどうするか」というスタンスから対論させていただいてました。対話自体はほぼ平行線のまま終わったようですね。「適用4とその周辺」のコメント欄でのやり取りもご参照ください。

 「風のまにまに心のままに」さん
  フルカワがはじめて「validであるべき」と主張する記事に対して対提案を考えさせてもらったサイトさん。プロとしての立場からソースつきで記事を書かれ、内容は専門的でフルカワにはさっぱり理解できませんでしたが、試行錯誤するきっかけを作っていただいたということで感謝しています。

 「凹日記」さん
  「適用4」の凹さんも、「validであるべき」と主張されました。このスタンス自体は、フルカワもよく理解できるところです。スタンスの違いはむしろそこから先、「では実際問題としてどうするのがよいのだろう?」というところで分かれるわけですしね。

 「あそびをせんとやうまれけむ」さん
  Tigerさんはいくぶん妥協的なスタンスで、「理想としてはvalidであった方がよいが、現実を考えるとなかなかそうもうまくいかない」という見方に立っておられるようです。

 「本格焼酎忘備録」さん
  しばたにさんは当該テーマそのものについてのコメントを提示されてはいませんが、リンクの記事において「validではあっても閲覧に不具合のあるケース」についての記事を書かれていることによって、結果的にいくぶん中間的なスタンスに立たれていると思います。(とりあえずフルカワもこの問題にはちょっと興味があります)

 「StarChartLog @cocolog」さん
  Stellaさんもこの件で具体的にコメントしたわけではないですが、フルカワが「適用1」「適用4」の間で取捨選択する際にポイントとなった、リンク記事の「RSSがたいへんなことに」は、結果的に「validから離れぎみ」なスタンスの人間を許容するものとなっていると思います。(ご本位ではないでしょうが…。)

「詞織」
 フルカワは以上のプログラムに詳しい方たちから比べると、さらに「左」に寄ってます。つまり、「自分の技術でvalidに準拠させられるならvalidにするが、できなかったりやりたいことに制限を受けるようならvalidにこだわらない」「W3Cの準拠バナーをつけるのはなんだか権威に盲従してるように見えて嫌なので、たとえvalidなページを作ってもバナーは貼らない」などの、あまり論理的ではない実践的・感覚的なスタンスを大事にしているようです。

 「ボヤキ不定期投稿」さん
 今回見つけた中での最左翼、「んなよーわからんことごたごた言ってんなよ、テキトーにやりゃいいじゃん」派さんとしてとりあげさせていただきます^^;
 この記事読んだとき「俺が先に書いたんだ」「いや俺が先に」とフルカワが言ってんだと思われてルー!と(被害者意識的に)嘆いたりもしましたが、まあじっさい「興味のないおおかたの人」にはそう思われるだろーな、最近の記事は…という思いもまた、あります。私自身、トラックバックの話題とvalidの話題をとりあげるとこのように思われるだろうな、という意識があって当初はまったく記事にしなかったわけですし。
 いちおうコメントしておきますと、HTMLタグとXHTMLタグの区別とか、タグ挿入を無意識的に行ってると、「詞織」のようにツッコまれますよ、ということです^^; (気にされないのは、それはそれで各自のスタンスということで)
 

 だいたいのスタンス偏差は以上のリンクで分類できるのではないかと思います。
 ですのでフルカワの立場からは、「重要なことはvalidであるべきだという人たちが、validにこだわることで生じる問題点をvalidであるまま改善し、それを技術のない人が簡単に導入できるように解説し、その方法によって啓蒙すること」であると信じる、と主張申し上げる次第です。「それはvalidじゃない」というのは誰でも言えることです。それ以上を言えるかどうかが「説得」のきっかけになるのであって、「validじゃないからダメ」というだけでは、(一部のかた以外は)見向きもしないだろう、ということなのです。

|

適用4とその周辺

ココログにおけるvalidな方法は編み出されたのか?それはいつ編み出されたのか?
そして、なぜnot validな方法が紹介され続けるのか?

 この記事は「観測気球」さんの「Valid な方法で自分の作ったスタイルシートを使うことに成功」という記事からのトラックバックを読んで書いたものです。

 正直なとこ、他の方の用いられているTipsの問題点を(記事の流れの中におかずに)個別に記事にするなんて、悪趣味だと思ってます。また問題点が「深刻な」(=使用者に直接的な被害を及ぼす可能性のある)ものでない限り、それらは各自の自己責任において許容しうるものだとも思っています。ただ、「not validな」詞織の記事に対して「我こそvalid」などというトラックバックがきた場合、やはりそれに対する私の考えを述べる必要があるかな、と考えました。

 で、私としては「凹日記」さんが記事にされた「自分で定義したスタイルシートを使う方法@ココログ その3」、つまり詞織で「適用4」として紹介させていただいた方法で、とりあえず「valid(正当な・妥当な)」表現の枠内で自作スタイルシートを適用できると思っています。まったく別な方法、つまりJavaScript制御以外の方法でcssを呼び出せる方法があるならば、あるいは紹介するかもしれません。
 ただ、前から何回も言ってますように、「詞織」はもともとTips紹介サイトではないので、類似の方法、たとえばJavaScript制御の枠内のいかなる命令方法で呼び出すか、といった細かなバリエーションをサイト内でいちいち紹介してはいないのです。たとえば「ココログANNEX」さんなど、そのような情報を収集されているココログサイトさんもあるわけで、そちらに集められた情報を見ずになされたと思われるトラックバックのケースがあったのは残念だと思ってます。
 
 で、私が「valid(正当な・妥当な)」表現ができると思ったにもかかわらず「適用4」を使用していない理由ですが、
・JavaScript制御依存の場合、閲覧者によっては「JavaScriptを動作させない」選択をされてスタイルが反映しない可能性がある
・自作スタイルシートによって「Mac&IEでの文字化け」「Operaでの文字化け」などを防ぐため、自作スタイルはできるだけ確実に適用させたい
・もともとデフォルトにシステムから提供されている(=「valid(正当な・妥当な)」に配置された<link>での)スタイルを「確実に変更させる」必要があるため、「デフォルトのスタイルは適用されるが自作のスタイルは適用されない」という、上記のようなケースを生じさせたくない
・「適用4」における独自の問題点の解明がまだなされていない(ように見える)。具体的には、SafariやMac&IEなどでのページ閲覧・スタイル適用ができているかどうか、不透明。私はMacユーザーでないので、この点の確認ができない。
・サブタイトル欄なりマイリストに記入する文字列が長い。(cssの仕組みを理解していない人へのTips・RSSデータへのタグ混入をできるだけ防ぎたい場合の方法としては、扱いが難しいとの考え)

 以上の理由により「適用4」を使用してはいません。私は「仕組みがわかってはいないけどとりあえず変えてみたい人へのTips=適用1」、「仕組みがわかっていて「valid(正当な・妥当な)」表現にこだわる人への紹介=適用4」というふうに、両論を併記しているわけです。このことは「適用4」=「自分で定義したスタイルシートを使う方法@ココログ その3」が方法的にエレガントなものであると私自身が評価しているということとはまた別の問題なのです。

 さて、

「自分で定義したスタイルシートを使う方法@ココログ その3」で使われている方法をベースにして、validなスタイルシート置き換えを実現する方法を思いつきました。(「観測気球」さん)

 と、「観測気球」さんは述べたわけですが、果たしてその方法は「適用4」といかほど異なっているのでしょうか?

JavaScript 部分を <!-- と --> で囲むだけ。あと、<h2></h2> のように空文字列を囲むのを避けたいので、「サブタイトルの内容・その1」、「その2」のようにしてみました。(「観測気球」さん)

 つまり、これは「ベースにした」というよりは「ほぼそのまま流用した」ものだ、とフルカワは理解しました。(=同じものなら、わざわざ紹介しません。)
 さて、「ベースにした」ということでオリジナルな相違点が「validな表現」にとって重要かどうか、ということが次のポイントです。
「観測気球」さんのオリジナルな点は以下の通りとフルカワは読み取ります。

・スクリプトタグをコメントタグ(<!-- -->)で囲む
・<h2></h2> と空文字列を囲むのを避けて文字を入力する(引用元の記事を読む限り、「観測気球」さんはこれをオリジナルと考えているように読み取れます。私の意見は否定的なものです)

 上記2点がオリジナル要素であるということになります。
 
 では、この2点は「validな表現」にとって重要でしょうか?
 
 検証してみました。
 まず「詞織」へのスタイル適用を「観測気球」さんの方法で行います。次に、もはやおなじみ(?)W3Cの正規表現チェックで、「詞織」をチェックしてみます。その際に、「観測気球」さんのオリジナル要素を付加した状態とはずした状態を、それぞれ比べます。

 具体的に、ソースは以下のような感じです。
 
・オリジナル要素が付加された状態のソース
サブタイトルの内容・その1</h2>
<script type="text/javascript">
<!--
var myStyleHref = "http://siolli.cocolog-nifty.com/blog/style-site006.css";
var linkElem = document.getElementsByTagName("LINK");
for(var i = 0; i < linkElem.length; i++){
if(linkElem[i].rel == "stylesheet"){
linkElem[i].href = myStyleHref;
}
}
-->
</script>
<h2>サブタイトルの内容・その2


・オリジナル要素を取り除いた状態(「凹日記」さんのソースと同じ状態)のソース
</h2>
<script type="text/javascript">
var myStyleHref = "http://siolli.cocolog-nifty.com/blog/style-site006.css";
var linkElem = document.getElementsByTagName("LINK");
for(var i = 0; i < linkElem.length; i++){
if(linkElem[i].rel == "stylesheet"){
linkElem[i].href = myStyleHref;
}
}
</script>
<h2>
本来のサブタイトルの内容


 で、チェックの結果です。
・オリジナル要素が付加された状態のソース→valid!
・オリジナル要素を取り除いた状態のソース→valid!

(追記:tsupoさんのコメントに対応して、現在後者の方法でスタイルを関連付けた「詞織」のチェック結果をリンクしておきます。→tsupoさんに確認していただきましたので、スタイルを戻すと同時にリンクを削除しました。)

 …はい?
 
 つまり、「観測気球」さんの方法でのオリジナル部分を取り除いて、もともとの「凹日記」さんの記述方法のみでタグを書いても、W3C Validatorはいずれも「valid(正当な・妥当な)」表現とみなしたことがわかりました
 …てことは、「観測気球」さんの方法は、残念ながら初のvalid!な表現ではなかったということになります。「詞織」において二番煎じを紹介する意志は、フルカワにはありません。

 さらに「Valid な方法で自分の作ったスタイルシートを使うことに成功」のコメント欄でもすでに話題になっていますが、サブタイトル欄にこの方法を記入することで生じる「RSS概要へのタグ混入」問題を防ぐためにはどうするべきか。この「すでに話題になっていた」問題に対して、後発の「観測気球」さんが有効な解決方法を提示せずに

すぐにはいい方法が思いつきません。 ということで、いいアイデアがありましたら、教えてください。(「観測気球」さん)

 と「投げてしまっている」のも、シロウトを落胆させるには充分だと思います。validでさえあれば他の問題点は無視でも良いというのでしょうか?
 変な言い方になってしまいますが、ネット上に流れる情報といったものは真贋いずれの側面を強く持つにせよ、それぞれの「問題関心」「前提条件」をもとにくみ上げられたテキストです。のちのちそれらの情報を評価したり再評価したりするためには、それらの「問題関心」「前提条件」を考慮に入れた上で発言するのでなければ、単なる視野狭窄に陥ってしまうと思います。
 大学の先生が良く使う手ですが「で、先行研究はチェックしたの?」ということですね。
なぜ「それらのテキストがそのように書かれているのか」「なぜ正規でない表現を用いているのか」「なぜか」=砕いて言うならば、「相手の目線にまで降りてくる」ことは、オブジェクション形成の一つの重要な前提だと、私は思います。それは同時に、単なる知識自慢(=ツールとしてのblogの視点)にとどまらない、コミニュケーション関係樹立(=コミニュケーション論としてのblogの視点)のための第一歩なのだと思います。

(追記)Tigerさん、これが私なりの「お返事」になっていれば良いと願っています。
 
(追記2)clairさんのご指摘にしたがって、記事中の「valid(正当な・妥当な)」の訳語を修正しました。感謝です。

|

提案と改善案

トラックバックに必要なのは感想というよりもむしろ、よりオリジナルな提言ではないでしょうか?

 いまだにぽつぽつとトラックバックをいただく「自作スタイルシートの適用」。フルカワ的には「もう初鰹の時期も過ぎたんだし、そんなにこの記事にトラックバックする必要はないんじゃないかな…」と思ったりもしますが、まあトラックバックフリーと言ってる以上は遮断などしないわけです。

 ただ、いまだに不思議なのが、この記事に対する「プログラムが趣味」とか「仕事でやってる」といった方たちからのコメント。だいたい「bodyタグのなかにlinkタグが入ってるのは《文法的に不正だ》《変だ》《気持ちが悪い》」というコメントとともにリンクされてるんで、フルカワは一度拝見したら「ああ、ご意見の違うかたですね」くらいで終わってしまうんですが、いまだにぽつぽつ来る。なにか目新しいことが書いてあるなら「トラックバックされて良かった」とか思うんですが、まあ9割がた《気持ち悪い》とかの感想だけです。これはいわゆるネガティヴリンクってやつですか?あ、17日から新規で会員が増えたのか。それならしょうがないので我慢します。わたしにとっては「また」でも、それぞれにとっては「自分がはじめて」かもしれませんしね。


 ただ。

 まず「適用」の方法が《文法的に不正》であることについては、もはや各所ココログで多くの人が述べてますし、
もちろんフルカワも最初から認識した上で記事を書いたことです。このへんのことはコメント欄ででも、また他の記事においても幾度か取り上げていることです。より正規表現に近いやり方も紹介しています(適用4などを参照してください。)つまり、そのようなオピニオンをトラックバックされましても、それ以上の改善案がない限り、無意味トラックバックです(強いて言えば、この無意味感にフルカワの心がもにょっとなります)。
 わたしがしれっとW3C正規文法遵守のバナーをつけてるとか、そのような場合のツッコミは謹んでお受けしますが、フルカワは文法チェックを受けた上で記事を載せ続けているということをご理解いただければと思います。

 「自作スタイルシートの適用」に対して、コンピュータが得意とかプログラムをなりわいにしているとか、そういう方たちのトラックバックにあまり建設的な意見がないと感じるのは、フルカワの偏見に過ぎないのでしょうか?シロウトであるフルカワがお聞きしたいのは、「ではどうすれば《できるのか》」、「ではどうすれば《より良いのか》」ですね。上記のような無意味トラックバックを送ってる方、ぜひ《改善案》をお願いします。トラックバックを送ってくださる場合には。そして事前により多くのサイトから情報収集をして、ご自分なりの判断をしてもよいのではないでしょうか。

あ、ニフティに要望送る、ってのはもう使用済みですので(10人以上は言ってると思います)。念のため。
 そして更に言うと、「変、とか、気持ち悪い」とか思った人のその「変、とか、気持ち悪い」までは、わたしは否定したくないと思っているということです。さて、わたしが「変、とか、気持ち悪い」と思ったのは何についてか、考えてみてはいただけませんか?

この記事は「観測気球」さんからいただいたトラックバックを見て書いたものです。
 tsupoさん、サイトのリビルドは記事投稿だけでなく、誰かからコメントもらったりトラックバックがついても生じると思いますよ。なので「いちいちアップロード」はたぶん、物理的に継続不可能だと思います。


追記:某記事を読んで(この記事がプログラマ一般に対する誹謗と受け止められたらヤダな…)と思いましたので、ちょっと文章に追加しました。A^^;

|

自作スタイルシートの適用4

日々着々と「自作スタイルシート」の正規化に前進を続ける「凹日記」さんがまた一歩先を行かれました。
 リンク先の記事にあるように、IE6のほか、Firebird [0.7] Opera [7.22] に対応されたとのことです。
 フルカワも確認を取ったところ、さらにMozilla[1.6]とNetscape[7.1] Opera [7.11] でもスタイルシートが反映されました。
 さらに、「凹日記」さんの方法ですとマイリンクにスクリプトを記入することも可能です

 そうなりますと、あとはMacユーザー用ブラウザ(SafariとかIE)での表示確認が取れれば、「より正規表現に近く、不安も少ない自作スタイルシートの適用」が可能となるはずですが、どうなるのでしょう?

追記:
 あとむさんからいただいた情報によると、この「適用4」はMac系のIE5.0では反映されてないようです。詳しくはコメント欄のやりとりをご参照ください。


 なお現時点で「詞織」はまったく別の方法(とはいえ、基本的なスタンスは「適用1」の方法のそれですが)をサブタイトル欄に記入して表示しています。

|

ココログPingServerリンクページ公開

 なにげなくココログナビトップを見たら、ココログPingServerによる更新情報一覧ページがリンクされてました。
 惜しい!サイトタイトルと更新時刻のみか!
 BlogPeopleとか使われてて、ココログサイトメインでリンクつけてる場合はこちらで代用が効くかなと思われます。…フルカワは、できれば「新着記事更新」みたいに記事タイトルがわかったほうがいいです^^;

|

新規記事と追記記事

なるほどこういうことか。
どちらのサイトさんかは忘れてしまいましたが、「記事をアップしたら、ココログナビの新着記事になぜか前日の記事タイトルが表示された」旨の報告をされていたのを見ました。
 で、今回「詞織」でも同様の現象が生じたので報告しておきます。

 今回「つなげるココログ2」に追記して、本日分記事として日時を変更し、トップに持ってきました。
すると「ココログナビのRecentley updated weblogs」には、新規記事としては最新の、前日アップ分である「Weblog使用とスタンス」が…。

 要は、新規記事のために送られたping情報が変更されてないということだと思うので、実害は特にないとは思うんですけどね。しょっちゅう記事日時を変更される方は、別に当日作成ほやほやの日記を同時投稿すると良いかもしれません。

 報告を兼ねて「ぴっくあっぷ」さんの新着記事ピックアップにトラックバックしておきます。

|

つなげるココログ2

(追記:この記事で紹介したサイトさまにトラックバックさせていただいてます。)

 各所でココログに関する企画が始まっているようです。いくつかをクリップしてみますので、興味のある方は覗いていってみてはいかがでしょうか(この記事はときどきアップデートして扉の一番上に移動することがあるかと思います)。

1.ココログの設定に関するTipsを探す
 「ココログANNEX:ココログTips」(「此処録」さん)
  ココログサイトの別館として、管理人さんが今まで収集したTipsのナビゲーション一覧を見ることができます。
 お探しのTipsが見つからない場合、
 「ココログ『WANTED』掲示板」(「TokyoForum」さん)
  でお尋ねになってみてはいかがでしょう。

2.ココログサイトにいろいろ取り込む
 一般にホームページで用いられる「コンテンツ貼り付け」の種類は多すぎる上、私の使わない種類のものも多くて個別に解説する機会はなさそうです。ここでは、これら各種のコンテンツ貼り付けに関する紹介をされているサイトさんをクリップします。

Google検索フォームを貼り付ける(「いかんともしがたい」さん)
BBSを貼り付ける(CGI設置できる人向け1)(「オバチャンの視点」さん)
BBSを貼り付ける(CGI設置できる人向け2)(「LOVE!?@cocolog」さん)
Harboxを貼り付ける(「(`・ω・´)」さん)

|

Weblog使用とスタンス

 この雑感は「ようやく一息。」「ウェブログと情報操作」の続きとなってます。

 ココログに限らずウェブログツール一般に言えることですが、人々があるツールを使うかどうかという「導入基準」はひとそれぞれです。日記を書く人、ホームページの大体として用いる人、ほかにもいろいろあると思います。そしてそれらすべてが「実質的には」排除されない、というのがツールの「一般への普及」であると思っています。極少数の人が、ごく限られた目的のために「のみ」ツールを用いる、という場合、これは普及ではあるかもしれませんが「一般への」普及であるとは言いにくい面があります。それゆえに、「一般への普及」という現象は「テクノロジー原理の無説明化(あるいは、マニュアル化の進行による原理の閑却)」、「テクノロジー原理からの逸脱・偏向」「テクノロジー原理を生み出した、当初の理念・目的意識からの逸脱・偏向」という側面を持っていると思います。
 
 私たちに身近な、小さな例をあげるとすれば、「トラックバック」という仕組みもそうです。トラックバックは「何のために」用いられるのでしょう。自分のサイトをアピールするため?他人のサイトにツッコミをいれるため?理由もなくとりあえず?どれも然り、と思います。原理的には、それらすべてがOKであるでしょう。NGであるのはただ一点…「相手サイトがイヤといったらNG」ということではないかと思います。なぜなら、トラックバックは「コミニュケーション」であるからです。相手が話したくないと思ったら、どれだけがんばっても「コミニュケーション」は成立しません。これはテクノロジーの問題ではなく、コミニュケーションの問題ということになります。

 フルカワが言いたいことは、テクノロジーの原理とコミニュケーションの原理は、まったく無関係ではないのですが別の判断基準によって動き、その結果として双方の原理にかなり大きな「逸脱・偏向」を加えるのではないだろうか、ということです。その「逸脱・偏向」をどのようにして「ココログ使用者が受け止め、考える」でしょうか?それは「悪いこと」なのでしょうか?「そういうもの」なのでしょうか?…何よりも、ただの便利ツールであるはずのココログを使って、そもそも「そのようなことを考える(べき)」でしょうか?
 考えるのも、考えないのも、すべての手綱は利用者本人にゆだねられているのではないかな、と思います。そしてそのような判断基準の表れとして、ひとびとの「ココログ」に対するスタンス・発言が「見えてくる」のではないかな、とも思うのです。

 この記事は、以下の話題を読んで考えたことです。

 ブログはキャズム(ハイテクの落とし穴)を越えてブレイクするのか?(「GoodPic.Com」さん)
 ウェブログと"キャズム"(「NDO::Weblog:」さん)
 外からの目(「此処録」さん)

|

ウェブログと情報操作

昨日の記事の中に日記を混ぜておいたところ、どうもフルカワがウツになったと思われたのか、各所からフォローのコメントとか頂戴しました。ありがとうございました…。って、そういう風に読めたのでしたら、私の書き方が悪かったということで申し訳なく思っています。で、補足的にこの話の続きを書こうと思います。もともとは別の記事でしたが、流れの関係として「続き」扱いの記事ということで。

 まずフルカワが紹介した「自作スタイルシートの適用」ということが、フルカワの発明でもなんでもないことを説明する必要があります。ウェブログツールシステム「MovableType」をいじっていた方はおわかりのように、「ココログ」の「サブタイトル欄」にあたる「description」部分を使って強引にスタイルシートを読み込む「技」は、周知のものであったかとフルカワは認識しています(「知られている」のと「使われている」のは別物かもしれませんが)。おそらくベースシステムである「TypePad」でも当然できるのではないかと思います。フルカワは単に「紹介」しただけ、という自己認識でおりますし、その意味ではべつだんたいしたことしてないなと思ってます(無責任かもしれない)。

 次に、フルカワはこの「詞織」上に文字で示されたほど、自由気ままに「歩いていってそのあとが道になった」わけでもありません。
 むしろフルカワは意図的に「砂利道を突貫工事で敷設しました」。あるいはこの点をご不快に思われた方もいらっしゃるかもしれませんので、この点をお詫びしておきたいと思います。
 というのも「自作スタイルシートの適用」を記事にしたあと、多方面の皆様からトラックバックを頂戴しました。それにもかかわらず、フルカワは「そのトラックバックのいくつかを意図的に削除」しました。「トラックバックを削除するなどモラルに反する!」と思われた方がいらっしゃるのであれば、その方にもあらかじめおわびしておきます。すいません。
 …はい、フルカワは「トラックバックの取捨選択によって明白な偏りをもつひとつのオピニオンを提示しようと」しました(その効果がいかほどあったかは、行った本人にもサッパリわかってませんが)。
 しかし、続々と増えたトラックバック先を見ながら私が望んだのは、「よくわからない人でもとりあえず”やってみて”」もらうことでありました。それからなら『そのことがいいのか悪いのか、良い点とまずい点はなにか』を考える機会がもてるのではないかな、と。「やってみよう!」と思ったときに、「でもそれって良いの?」という消極的なツッコミを「フルカワ自身のサイトから提示する」つもりはなかったのです。少しでもcssの知識をお持ちの方や、反対意見をまず考慮する方は「”やってみる”」前に自分で取捨選択をするわけで、その意味ではフルカワは「とりあえずやってみる」気になった人をターゲットとして「自作スタイルシートの適用」を書き、トラックバックも取捨選択したわけです。”やってみた”あとならば、「でもここがうまくいかない」「ここが不都合だ」と、専門知識をもたずともある程度判断ができるケースも多いです。その点について言えば、フルカワのレッドゾーンは「知らずに行うと明確な危険が生じることが認証されているケース」のみであった、ということになります。

 ですので、私は私と異なるスタンス・意見をお持ちの方のご意見を受けたとき、決して不快にもウツにもならなかったことは明言しておきたいと思います(まあそんなことに気をやむ方がいるとは思わないのですけど、いちおう)。
 私自身が明白にひとつの立場に立って発言をしましたし、その意味で私と私以外のすべてがイーブンであると信じます。私が何かしらの意見に不快感を感じるようなケースがあるとすれば、私自身がその情報なりサイトなりを「訪れなければ良い」わけで、情報収集の手綱を握っているのも「自分自身」でしかないと思っています。
 ですからインターネットで情報収集を行う方は特に…「その情報がいかなる意図の下に発信されているのか」「それに対するアンチテーゼは存在しないのか」「テーゼとアンチテーゼを止揚するジンテーゼを、自分はいかに構築するか」という点について、意識的であって欲しいな、とそう思います(すいません、最後の専門用語は意味もよく理解せずに用いたことを白状しておきます)。

 ただそれにもかかわらず、フルカワに温かい言葉をかけてくださった皆さんには感謝しております(フルカワは温かい言葉をかけていただくのがすきなのです^^;)。

 作成日付の3日ほど前に考えていたこの記事を公開する間に、別話題ではありますがこの記事の思考方法と根底を同じくすると思う記事を読みましたので、あわせてクリップしておきます。

 ウェブログとジャーナリズム(「神々の熱き日記」さん)

(2003.12.10追記)
 さらに、やはり別のテーマではありますが、フルカワが行った行動に対するもっともクリティカルなアンチテーゼについての記事を書かれている(と、フルカワが理解する)下記の記事もご参照ください。

 患者に不安を与える(「手の届く範囲だけでもなんとかしたい」さん)
(追記終わり)

  さて、現時点ではフルカワ自身はといえば、<link>タグをサイドバーのマイリストに入れるというやり方をしてます。<link>タグを<body>タグの内側に含めることは無論「不正規」なものですが、メリットとしては
・「RSS」へ不整合なサブタイトル情報を送らない(かもしれない)。
・JavaScript制御で生じる、「Mozilla/Netscape7」でのスタイルシート未反映を防ぐ
 という点が挙げられます。「できるだけ多くの人がサイトを”見れる”ようにデザインする」という、フルカワのスタンスにもとづくものです(と、フルカワは説明します)。

 さあ、あなたは何を信じますか?

|

その後のサイト内検索

(追記)12月8日p.m.5:00現在にはふたたび検索できるようになっています。謎。(追記終わり)

サイト内検索を導入する」を書いてから二日たちましたが、左サイドバーをご覧になった方はすでにおわかりのとおり、Google検索フォームをはずしてしまいました。その理由として、「詞織」サイト内検索が出来なくなってしまった点が挙げられます。

 先日の設置後、順調に検索ロボットが巡回してきて、検索できるキーワードも次第に増えてきた矢先のことです。急に「詞織」サイト内の検索をしてもまったく何もヒットしなくなってしまいました。それどころか、「siolli.cocolog-nifty.com」そのものがヒットしなくなってしまったのです。

 Google検索の仕組みについてはフルカワはよく理解しておらず、ソースを再取得して再度設置して見たものの、無反応は変わりませんでした。更新によるサイトページ全体の作り変えが原因なのか?アクセス過多による不穏ドメインとして遮断されたのか?単にフルカワの誤字か?(それにしては、昨日一昨日には使えてたんですよね…)

 と、そんなわけで現在、検索フォームは取り外されています。いかなる理由でこの現象が起きたのかが不明だという点と、これにかんして調査する技量がないという点と、2点の理由により、この解説はできないのでした。オチなしですいません。

 しばらくはフォームを付けたり取ったりして状況を観察したいと思います。
…こうなると、現状で安全なサイト内検索の方法を考えないといけないかな。自分自身はサイト内検索ができる(記事作成画面の検索フォームから)ので、不満はあまりないんですけどね。

|

コメント文字化けMac&IE(報告)

先日コメントを募集していた過去記事に、とりあえずの中間報告を終えましたのでこちらで誘導だけさせていただきます。

 →コメント文字化けMac&IE

 現時点では「完全に」文字化けを防ぐことは出来ませんが、ある程度まともに使えるようになったのではないかなーと思っています。…だけどどうやったら「完全に」防げるのやら…さらにスタイルをいじってみようと思ってます。

|

つなげるココログ

今度はココログサイトを検索したりリングに登録してみましょう。

 ココログビや「Recently updated Weblogs」で表示される新着ココログや新着記事は、今が開始直後ということもあってあっという間に流れて消えていきます。自分と同じジャンルや話題を扱っているサイトをさがすのは至難の業ですね。
 そこで現在までに、以下のような解決方法が模索されています。

1.Googleする。
 基本的なものから。「Google」で検索すれば、ヒットするココログ「も」あります。ないこともありえます。自分のサイト内を検索することも出来ます。ヒットしない記事もありえます(Googleの検索ロボットが来るたびに、ヒットする記事は増えると思います)。
 →(ココログへのGoogleの設置についてはこちらの記事を参照してください。)
 Googleでココログサイトだけを検索するやり方については、「此処録」さんのところで「ココログサイトをGoogleで検索」として紹介されています。

2.ココログルする。
 Curryさん作成のGoogleフォロワー・「ココログル」は、ココログサイトの新着記事を検索できるようにした検索エンジンです。

3.「新着記事ピックアップ」を見る。
 検索より、「Recently updated Weblogs」の件数をもっと多く見たい…というばあい、「ぴっくあっぷ」さん作成の「新着記事ピックアップ」をチェックしてみましょう。

4.リンク集に登録する。
 「此処録」さんのうなさんは、cgiを使ってココログサイトリンク集をはじめられているようです。
フルカワも登録させてもらいました。新着リンク集だけでは物足りない方も、登録してみてはいかがでしょうか。

|

見えない記事ボタン

記事を作成するとき、入力フィールドの右上には<strong><em><u><a><blockquote>を簡単に挿入できるボタンがついていることは、皆さんご承知の通りかと思います。

 …え、ついてない?

 そうです。Macユーザーがブラウザを見る限り、このボタンは表示されていないはずです。多分最初に記事としてまとめたのはこちらの方です:

Macユーザーは注意!引用スタイルのTIPS(「AirLog」さん)

 実はMacに限らず、Netscape7.0xでもこのボタンは見えないようです。コメントをいただいて修正しました。見えないのではなく、ボタンは見えてるんだけど押せないとのことでした。Netscape7.1ではボタン機能が使えるようになっています(ぼて猫さん、コメント感謝です)。

ココログとブラウザ(「ひねもすのたりのたりかな」さん)

 さらにさらに、フルカワの確認した限り、Opera7とNetscape4.7でも見えませんでした。…ほとんど見えないってことですか!

 実はこの現象、ココログに限ったことではなく、前身のMovableTypeなどでもさんざん言われていた問題でした。ブラウザ依存の問題のようですので、Macユーザー&Netscape7ユーザーの皆さんは手打ちでがんばってください。
 
 「詞織」で紹介したTipsでは、「引用」がこれに関係していると思います。

|

自作スタイルシートの適用3

(追記:この「3」のやり方が正規で「2」が不正規なのかどうか、どうもフルカワは判断できないようです。この記事のネタ元風のまにまに心のままに」さんでのコメントのSienaさんとfacetさんのやりとりも参照してください。)

 なんとなく「それはルール違反な記述です」と言われる気がするのでさらなる解説を追加。
ちなみにフルカワとしてはこのシリーズ、1(まあ楽だからとりあえず)→2(まあ気になる人はどうぞ)→3(どうしても気になる人はどうぞ)の順にオススメです(え、どれもあまりススメてないですか?)。特にココログで難しいこと考えずに見ためをカッコよくして楽しみたい人は、この手の作業に時間かけるだけ青春の無駄というものです。あ、もちろんスタイルシートを自作するということそのものが手間ですので、そこらへん割り切って使える場合は「1」も絶対必要なものでもないのです。(と、意味のない前書き)

 使用するのは今回もJavaScriptです。「2」ではマイリストのメモ欄にスクリプトを書き込みましたが、さてこれは「正規の」表現になっているのでしょうか?
 

風のまにまに心のままに

 こちらによると、「2」は正規の表現ではないようです。またかよ!とつっこんだ方のために、こちらの記事を読んで解説してみようと考えました。
 …えーと、すいません。フルカワは脳みその容量が不足してるようで、記事の言わんとすることを理解できませんでした。なので、解説無しでやり方だけ書いてみます。適用は各自の自己責任でお願いします。

1.「2」でやったのと同じように、マイリストを活用します。既存でも新規でもよいのでリストを作り、「新規リストの追加」を行ってください。いつものように「タイトル」「URL」「メモ」のフィールドのセットが出てきました。

2.タイトルのフィールドに

<script type="text/javascript">var myStyleHref = "http://siolli.cocolog-nifty.com/blog/style-site006.css";var linkElem = document.all.tags("LINK");for(var i = 0; i < linkElem.length; i++){if(linkElem(i).rel == "stylesheet"){linkElem(i).href = myStyleHref;}}</script><noscript>JavaScriptを使用してスタイル提供してます。</noscript></div><a href="">

 と入力してください(注:改行はせずに、一行で入力してください)。URLはもちろん、皆さんの自作スタイルシートのアドレスに変えます。

3.URLのフィールドに

"></a><div class="link-note

 と入力してください、

 保存して変更が反映されたら、「2」と同じようにスタイルが適用されているはずです。なお原理は「2」と同じなので、これも「Mozilla1.6」では反映されません。(もっとスマートなやり方がないのかなー)

|

自作スタイルシートの適用2

解説してくださいよ凹日記」さん^^;。

興味がある人は、このページのソースを覗いてみてください。(手抜解説)

そんなこと言わないでくださいよ道玄坂茶屋」さん@@;
詳細は「ページのソースを覗いてみてください」とのことですが、おそらくこの週末には、だれかが詳しく解説してくれるような気がします。
私がやれって感じですが、すみません、時間ができたらがんばります。

 しょうがないのでひとさまのソースを覗いて解説してみましょう。
「自作スタイルシートの適用2」です。

 「凹日記」さんが採用したのはJavaScriptです。

 →JavaScriptって何?ってかたはこちらをどうぞ(「とほほのJavaScriptリファレンス」)。

 これを使って作ったスクリプトを「サブタイトル欄」にコピー&ペーストして、フルカワが<link>タグでやったことを再現しているわけですね。もちろん、「サブタイトル欄」に入力するということは<link>タグと同じようにRSS関係で問題があるかもしれませんので、ここは「マイリスト」を使ってコンテンツ内に入れてみましょう。フルカワは「コンテンツ」のimgタグを記入したメモ欄部分に付け加えてみました。
 スタイルシートのcssファイルは、以前と同じようにアップロードしておきましょう。


参考:「詞織」でのスクリプト記述サンプル

<script type="text/javascript">
<!--
var myStyleHref = "http://siolli.cocolog-nifty.com/blog/style-site006.css";
var linkElem = document.all.tags("LINK");
for(var i = 0; i < linkElem.length; i++){
if(linkElem(i).rel == "stylesheet"){
linkElem(i).href = myStyleHref;
}
}
// -->
</script>
<noscript>
JavaScriptを使用してスタイル提供してます。
</noscript>

 <link>と比べてのメリットは、なんといっても「正規表現」の枠内におさまっている(んですよね?)ということではないでしょうか。。<link>タグは<head>~</head>の中に含めておかないと「不正」ということですので(このへん気にされる方もけっこう多いようです)。<link>の「不正規な使用」を気にされてる方は、こちらでやってみてはいかがでしょうか。
 この方法で気をつける点ですが、多少複雑になっている(単にスクリプトが長いだけですが)ので記入ミスに気をつける点、JavaScript機能をオフにしているひとがけっこういるので、<noscript>タグを追加して説明文を加えておいた方がよいという点です。
 なおフルカワが確認した限り、この方法では「Mozilla1.6」「Netscape7.1」でスタイルが反映されないようですので、ご留意を。

|

汎用性の高いテンプレ&スタイル

 自作スタイルシートをさんざん使っていてなんですが、この方法は以前にも書いたとおり、問題がないわけではありません。正規の記述方法にのっとっていないと気分が悪い、という方もいらっしゃるかと思います。
 「できるだけ深く考えず」「それでいてできるだけ多くのブラウザで見れるように」「正規の書式にのっとって」デザインを設定するにはどうしたらよいでしょうか?ちょっと調べてみました。

 まずは現状のココログを利用したときに生じる問題については、私の知っている限りでは以下のようなものがあります。

・特定のブラウザでデザインが崩れる
  特に大きな問題になっているのは、IE5.x以前のブラウザのようです(使用人口の多さのため)。

IE5.5で見えないココログのデザイン問題Tokyo Forum」さん(chikaさん情報提供)
IE5でも見えない…facet-divers」さん

 フルカワの確認した限りでは、NC4.7も崩れます(もっともこのブラウザ、ほとんどどこのサイトも崩れちゃいますが)

・特定のブラウザでフォントが視認しづらくなる
  Operaでは既存のスタイル設定のフォントが読みづらくなります。サイドバーのフォントは文字化けするし小さすぎます。

 →(スタイルシートでフォント変更を参照してください)

・特定のブラウザで特定のブラウザでコメントフォームに入力した文字が文字化けする
  Mac上でのIEがこれにあたるようです。

なんともはや・・・。ぞうさんニフティ出張所」さんのコメントの流れを参照してください。

 →(コメント文字化けMAC&IEで修正に挑戦中です)

 これらの問題の多くは、自分でスタイルシートをカスタマイズして直すことができます。「詞織」では今まで、基本的にスタイルを修正することでこれらの問題を考えてきました。もちろんそこに問題がないわけではありません(詳しくは後日、別の記事で扱いたいと思っています)。
 さて、他の方法はないのでしょうか?これらの問題のいくぶんかでもフォローしつつ、深く考えずに、手軽に、できるだけ多くのブラウザで自分のサイトを見てもらうということはできないのでしょうか?
 難しい問題です。フルカワもこの問いかけに対し、明快な答えを出せません。ここではできるだけ手軽に、できるだけ汎用性のあるもうひとつの妥協案を提示することでご容赦いただきたいと思います。

1.規定のテンプレートは「2列」を用いる。ログの本文は左側に配置されるようにする
 ブラウザによっては、本文が右側にあるとページ下部に移動されて見えることがあります。そこで本文は左側に。デザインの崩れを考えて、段組は2列にとどめましょう。
2.トップページに表示する記事は1件のみ 
 トップページの記事が複数になると、やはりデザインが崩れるケースがあります。最新の1件だけを表示しましょう。
3.サブタイトルに画像を使わない 多くの既存テンプレートでは、サブタイトルに画像を入れると下半分が表示されなかったり、サブタイトルの文字が隠れてしまうケースが多いです。サブタイトルには画像は使わないか、縦幅をできるだけ狭くして調整してみましょう。
4.スタイルを制限する
 既存のスタイルの中で、比較的汎用性の高いものは「エレガンス」ではないかと思います。それよりは低いものの「クリスマス」「システム」「ライン」「ルージュ」「清流」「無地」「Nifty」「Matrix」は、それなりに汎用性の高いスタイルです。これらのスタイルを2列テンプレートと組み合わせれば、比較的多くのブラウザであなたの記事を読むことができると思います。
5.カレンダーは使わない
 はっきりいってこれの調整はめんどくさいです。フルカワもMovableTypeを使ってたときから消してました。どうしても必要だというのでなければ、デザイン上は消した方が楽です。

 「もっといろいろやりたい!」「派手にしたい!」という場合、フルカワのようにスキマ技(見る人から見れば「邪道」ということだそうです)を利用するくらいしか、現状では打開策はないかもしれません。ココログスタッフに要望を送りつけるのも、現状では有効な打開策のひとつだとは思います。

ココログに関するご意見ご要望はこちら(~1/15)

|

コメント文字化けMAC&IE

(まえがき)
この記事は「Macのコメントフォームに文字入力すると文字化けする」というケースの改善策です。閲覧側のMacユーザーのブラウザの設定にかかわらず、一律に文字化けしないようにサイト管理者が対応する、という状況の改善策になっています。
 もともとフォントの文字化けは「MacのIE」ブラウザ設定に依存しているようですので、いちいちCSSを追加したくないばあいの改善策は「Macの文字化け:見る側から」をご参照ください。2004.01.19追記

とりあえずの「コメント文字化けMAC&IE」報告です。
まず、この記事にコメントしてくださった皆様に感謝します。この記事は複数のココログユーザーの善意によって形となりました。もちろん、誤字等の文責はフルカワにあります。

 Mac&IEを使っている場合、コメント欄に文字を入力すると、文字化けするという現象が報告されています。文字化けしても、書き込んでしまえば普通に表示されるようなのですが、入力中に誤字を判読できないのはつらいですね。そこで現時点では、完全なものではないのですが以下のような方法で文字化けを「ある程度」防ぐことが出来ます。

 やり方の基本は、またしても「自作スタイルシートの適用」です。過去記事をご参照ください。→

 要は、コメント入力欄のフォントを指定することで、文字化けを防ごうというものです。自作スタイルシートの下記の太線のような感じに要素を書き加えるか、書き換えるかしてみましょう。

textarea[id="comment-text"] {
width: 80%;
}
#comment-text {
font-family: "ヒラギノ明朝 Pro W6", Osaka, "MS Pゴシック", "trebuchet MS", trebuchet, "verdana", arial, sans-serif; }

textarea[id="text"] {
width: 80%;
}

#text {
font-family: "ヒラギノ明朝 Pro W6", Osaka, "MS Pゴシック", "trebuchet MS", trebuchet, "verdana", arial, sans-serif; }


 MacOSで読めるフォントを含めることで、文字化けを防ぐことができます。もしこれでもなお文字化けるような事例がありましたら、コメントなりいただけると幸いです。

(注2:以下の記事は当初のリライト記事の文末部にありました)
 MacOSで読めるフォントを含めることで、文字化けを防ぐことができます…「初回入力時」には。そうなんです、現時点でのフルカワは、「投稿確認時の入力フォーム」「エラー時の入力フォーム」の文字化けを修正することが出来ませんでした。上記と同じようなやり方を試してはみたのですが。これらのフォームを規定する、

id="text"

 を修正するやり方では、今のところ文字化けを修正できていないようです。
 引き続き、Macユーザーの皆様のコメントに頼ることになると思いますが、「文字化けがなくなった!」という報告があらわれることを期待してます…。

追記:
 記事をリライトし終わって、cssファイルを確認中に「おそろしいこと」に気づきました…Macユーザーの皆様、今も「確認時フォーム」「エラー時フォーム」で文字化けしますよね??そうであってほしい!(いやそうであるのはまずいんですが)。コメントお待ちしてます…。

(注・以下の記述は当初のものです。コメントも当初以来のものとなってます。)

 ちょっと変則的なポストです。

 「詞織」を見てくださってるMac&IEユーザーのみなさま、よろしければこの記事にコメントをつけていただけないでしょうか?
MacのIEだと、コメントフォームに文字を入力するときに文字化けするという話を聞くのですが、フルカワはWinユーザーなので確認できないのですね。
 「詞織」ではいちおう対応済みなのですが、フルカワ本人が確認できないので、皆様からコメントを頂戴したいと思います。コメントをつけてみて「入力時には文字化けする」「そもそもどこでも文字化けしないぞ」と教えていただけると幸いです。情報が集まりましたら、改めて記事としてリライトしたいと思っています。

|

引用する

 「ぴっくあっぷ」さんと「埼玉住人」さんのところで磨かれたすばらしい方法をクリップ。

引用のテスト(ぴっくあっぷさん)
引用をわかりやすくしよう(埼玉住人さん)

 これだと、class="block"を記事で書くときに追加しないといけないので改造です
<style type="text/css"> <!- blockquote { background-color:#CCCCFF; border:1px solid #003399; padding: 5px; } -> </style>

 はい、効果は↑のみたままのとおりです。
 自作スタイルシートを使っている場合、もちろんスタイルシート内にあらかじめ書き込んでおけば、手軽に引用を囲むことが出来ます。

 記事を作成する際には、自分の書いたもののなかに他の方の書かれた文章をうっかり混ぜないよう気をつけてくださいね。

|

サイト内検索を導入する

 「いかんともしがたい」さんがすばらしい記事を書かれたので、クリップしておきます。
 

Google検索窓を設置する

 記事はわかりやすく、変更の必要な場所はすぐに理解できるかと思います。
ぜひチェックしてみて、ココログへの導入をご検討ください。

 参考:「詞織」の場合(1回修正しました。「いかんともしがたい」さんの続報も参照ください。)

<!-- SiteSearch Google -->
<form method=GET action="http://www.google.co.jp/search">
<table bgcolor="#FFFFFF"><tr valign=top>
<td>Google検索<br />
<input type=text name=q size=16 maxlength=255 value=""><input type=hidden name=hl value="ja"><input type=submit name=btnG value="検索"><br />
<font size=-1>
<input type=radio name=sitesearch value="siolli.cocolog-nifty.com" checked> 「詞織」 内を検索<br />
<input type=radio name=sitesearch value=""> WWW を検索
<input type=hidden name=domains value="siolli.cocolog-nifty.com">
</font>
</td></tr></table>
</form>
<!-- SiteSearch Google -->

 ところでフルカワは検索フォームの上にテキストで「Google検索」とタイトルつけてますが、このあとの<br />タグは入れなくともIEでは改行されて表示されるかと思います。Mozillaなどでは改行されないのでご注意ください。

|

オリジナルメニューを作る

 ココログは普通のホームページスペースとは異なって、自分独自のページを作るのが難しいように見えます。「デザイン>表示するコンテンツ」のページを見ても、自作の項目を追加できる部分もないし、そもそもサイドバー部分に手書きでタグ打ち込めないし…と考えてらっしゃる方に、こんな感じの提案です。

「ココログサイトに自分のオリジナルメニューを作ろう!」

 ポイントは「マイリスト」です。
 
1.「マイリストの新規作成」を選びます。「リンク」型を選択してください。名称はお好きなものを。

2. >新しいリストを作成しました。 このリストをウェブログまたはプロフィールページで表示する

と表示されます。ここから表示ページを選ぶことができますが、とりあえずあとまわし。

3.今見ている2.は「管理」タブのはずです。隣の「設定」タブをクリックします。すると「(あなたが設定したリストの名称):設定」というページに移ります。

4.「(あなたが設定したリストの名称):設定」ページの一番下に、

 >メモの表示:テキスト表示 ツールチップとして表示 メモは表示しない

という選択肢がありますので、「テキスト表示」をチェックします。「変更を保存」ボタンを押して、ふたたび「管理」タブへと戻りましょう。

5.「管理」タブの右下には、

>URLを入力すると、新しいリンクを簡単に追加できます。

 と描かれた入力フィールドがあります。ここのフィールドに何も入力せずに追加ボタンを押します。すると何も入力されていない項目が増えましたね。

6.増えた項目のうち「メモ」のフィールドにタグを打ち込むと、表示が反映されるようになってます。イメージタグを描けば画像表示もできます(もちろん画像をアップロードするのをお忘れなく!)。URL欄を空白にしておかないと、リンクが張られてしまいますので、ただのテキスト部分として使いたいかたはお気をつけください。

7.最後に、あとまわしにしていた2.の「ページに表示させる」を行いましょう。
 「ウェブログ>デザインの編集>コンテンツ」に、新規作成したマイリストのチェックボックスが追加されています。このチェックを入れ、「ウェブログ>デザインの編集>並べ方」で配置する場所を決定して変更を反映すれば、オリジナルコンテンツ部分の表示は完成です。

 「詞織」左サイドバーの画像部分はこのやりかたで作成したものです。

 このワザは本家「TypePad」ですでに編み出されていたものの流用版です。これによって、「BlogPeople」なども表示できるはずですので、興味をお持ちになったら挑戦してみてはいかがでしょうか。

ご参考:
マイリストの追加について(ココログのヘルプ)

ブログ更新リスト情報サービス「BlogPeople」について
 TypePadの[Basic][Plus]ユーザーが利用する場合の設定方法 (BlogPeopleホームページ)

 「BlogPeople」については、「LOVE!?@cocolog」(さっちんさん)のところで紹介されてますので、こちらもご参考にどうぞ。

|

タイトル画像を表示させる

 今回のネタは「中途半端なMOBILER」さんの記事からです。「サブタイトル欄に画像タグを貼り付けるとタイトル画像として流用できる」というワザも、ココログサイト内ではやくもメジャーになりつつありますが、IE以外のブラウザでサイトを見ると、画像の下半分が切れて見えたりするという問題があります。

20031204.jpg


 今回はこの問題に挑戦してみましょう。

 さて問題の部分の「詞織」のソースを見てみると、こんな感じになってます。

<body>
<div id=”container”>
<div id=”banner”>
<h1>詞織</h1>
<h2><img src=”http://siolli.cocolog-nifty.com/blog/siteimg/banner.gif”/><br>
si olli novae historiae apparent, quas legere volo. フルカワマサユキblog</h2>
</div></div>

ページの冒頭部分、詞織のタイトル・バナー・サブタイトル・空画像のエリアを規定しているidが<container><banner>であることがわかります。
 既存のスタイルシートを見てみると、

・container:四角いエリア。横幅・下地の色・枠線の色などを規定
・banner:containerの中、頭にあるヘッド部分(詞織だとボーダーで区切られている、長方形の部分)に表示されるデータを規定。縦幅・フォントスタイル・containerとデータの接近度(padding)などを規定。

 つまり、「サブタイトルに画像を配置したのに、ブラウザによっては画像の下半分が切れる」という場合、この「表示されるデータの縦幅」を変える必要があります。自作のスタイルシートを作成し(→こちらを参照してください)、その#banner部分の数値を変えてください。既存のスタイルだと、おそらく40~50くらいの幅になってると思います。詞織の場合、85に設定してあります。
 変更を加えたスタイルシートをアップロードしてみると、どうですか?無事表示されました。
 
 この縦幅のなかに含まれるデータは「タイトル」「サブタイトル」です。「詞織」の場合、「タイトル」「サブタイトルの画像(40ピクセル)」「サブタイトル」と3行をつかってますので、目安にしてみてください。

 ところでなんで画像が切れるの?という点ですが、IEが「むしろ大雑把」という特徴を持っているということから生じています。「Opera」などは厳密にスタイルを適用するので、既存スタイルの「縦幅が短い」を正確に反映してしまうのですね。IEの場合、数値の指定がされてても、はみだした部分を表示するために無視しているわけです。便利といえば便利ですけどね。

*フルカワはSafariやFirebirdをつかってるわけではないので、すべてのブラウザソフトでこのやり方が可能かどうか確かめたわけではないです。他のブラウザを使われてるかたが記事をトラックバックしていただければありがたいです。

|

スタイルシートでフォント変更

 ココログの新着情報見てたら、どちらかのサイトさんで「Operaと相性が悪いみたいで…」というくだりがありました(そのサイトさん自体のアドレスがわからなくなってしまったのですけど

 大半のかたはIEだと思われますので、スタイルについて細かく気にする必要はないのですが、「Opera」ユーザーの方はもうおわかりのとおり、ココログの既存デザインをつかったページ、はっきりいってIE以外では見づらいです。フォントがぐちゃぐちゃになってるのが最大の問題ですね。「見れないことは、まあない」程度かな。

*2004.01.12追記
 最新版の「Opera」ではこのフォントの問題は改善されているように見えます。フルカワは現在ヴァージョン7.23を使用してチェックしています。フォントが崩れてるなーと思われる方、まずはバージョンアップして見てはいかがでしょうか。


 既存デザインでまともな日本語フォントを見れるのは、おそらく「エレガンス」だけじゃないかと思います。(これはこれで色がアレですが)。
 そこでスタイルシートを用いてフォントを綺麗なものに変更してしまいましょう。

  (→自作スタイルシートファイルについてはこちらをどうぞ。)

 既存のデザイン用のスタイルシートは、多くのフォント指定が

 font-family:’Trebuchet MS’,Verdana,sans-serif;

 となっており、日本語フォントの見栄えがあまりよくありません。
そこで、自作スタイルシート各所のこの一行を

 font-family: Georgia,’Times New Roman’,serif;

とか

 font-family: Georgia,’MS Pゴシック’、Osaka,Arial,sans-serif;

とかに変えると日本語フォントの見栄えがましになるかと思います。
もちろん、使用するフォントは汎用性の高いもののほうがいいと思われます。

|

自作スタイルシートの適用

 サービススタートから2日で、はやくもユーザーの皆さんが技をあみだしてるようです。せっかくなので私も、自分とこでやってることをメモしておきます。
 
 自分でスタイルシートを用意すれば、定型テンプレートのため似かよった見栄えを変えることが出来ます。(ただし、すぐできる!というほどではないので、リデザインに多少時間をかけてもいいやって人とか、スタイルシートの仕組みを理解されてる人にオススメです。)

0.スタイルシートってよくわからないけどやってみたい人

「とほほのスタイルシート入門」さんを参考にしてみてください。

1.スタイルシート・ファイルを用意

 (cssファイルを理解されてる方は本項をとばして2.へどうぞ)

 まずcssファイルを用意する必要があります。簡単な方法はtxtファイルにスタイルを記述して、保存したあとに拡張子をtxt→cssに変更するやり方ですね。

 よくわからない!という方は、IEですとブラウザの「表示>ソース」を選択してください。するとページのソースという文字列があらわれます。このソースの上から6・7行目あたりに、

<title>あなたのココログのタイトル</title>
<link rel="stylesheet" href="あなたのココログのURL/styles.css" type="text/css" />

という表記があると思います。このURLをコピー&ペーストして、ブラウザのURL欄に打ち込んでみます。…すると、なんだかよくわからない文字列がずらっと表示されると思います(メモ帳が立ち上がったりホームページ作成ソフトが立ち上ったり、人によってさまざまだと思いますが何らかの形で表示されると思います)。この文字列をすべてコピーし、新規にテキストファイルを作って保存しましょう。
 自作するスタイルシートの名前は、既存のスタイルシートとは異なる名前にしたほうが良いかと思います(のちのち区別がつきにくくなるので)。詞織ではstyles.css→style-site006.cssとしました。
 拡張子がtxtのままでは使えませんので、cssに直します。これでcssファイルが完成しました。

 スタイルの内容、特に<class><id>などについては、既存のテンプレートに適用されているスタイルシートを覗いて見ると参考になります。
 自分のサイトのソースを見ると、適用されているスタイルシートの<class><id>などがわかります。

たとえば「詞織」のソースを見ると、

<title>詞織</title>
<link rel="stylesheet" href="http://siolli.cocolog-nifty.com/blog/style-site006.css" type="text/css">

(中略)

<body>
<div id="container">
<div id="banner">
<h1>


という感じになっています。

 <div id=”container”>の部分を変更したスタイルシートを作ればよいわけですね。

2.自分のスタイルシートファイルをアップロードする

 「記事の作成→写真やファイルのアップロード」から、cssファイルをアップロードします。
 「詞織」ではトップのディレクトリ「blog/」にアップロードしてます。
 
3.サブタイトルを変更

 ここで言う「サブタイトル欄」というのは、ココログ管理ページにログインしたあと「ウェブログ>設定>ウェブログ/サブタイトル名称変更」のページにある「ウェブログのサブタイトル(キャッチフレーズ)」のテキストエリアのことです。ここにcssファイルへのリンクタグを埋め込むことが「サブタイトル欄への記入」ということです。
 「詞織」のサブタイトル欄には以下のような感じで入力しています。
 
<link rel="stylesheet" href="http://siolli.cocolog-nifty.com/blog/style-site006.css" type="text/css" />
si olli novae historiae apparent, quas legere volo. フルカワマサユキblog

 先頭に<link>タグを加えるだけで、自分の作ったスタイルが適用されました。URLはもちろん、2.で自分でアップロードしたcssファイルを指定します。
 
 
 注意点としては、テンプレートに適用されているスタイルシートと同じ<class><id>を利用する癖をつけておくこと、です。追加したcssファイルが重過ぎないくらいに、流用できるところは流用すると良いでしょう。


追記:既存のcssファイルの参照について、解説を加えました(20031206)
    記事中のソース部分をコピー&ペーストできるように修正しました(20031227)
    「サブタイトル欄」について、記事中3.に解説を加えました(20040102)

|

詞織 in ココログ。

 @niftyがウェブログサービス「ココログ」をはじめるらしい、とはじめて聞いたのはいつごろだったかな?気がつけばサービス開始してました。イイデスネ!

 「ココログ」のシステムベースとなっているblogツール「Type Pad」は、夏にロリポップ!で「詞織」を、別のツールであるMovableTypeではじめたとき、最終候補に残っていたもうひとつのツールでした。当時はモニター募集の締め切りが終わったあとで、モブログを兼ね、かつ手軽にはじめられそうなTypePadの印象が非常によかったことを覚えています。

(TypePadについては、南一哉さんのサイトでいろいろわかります)

 ニフでココログがはじまったことで、リアルネームでのブログネタはこちらでやろうかなと思っています。そうでないネタ(創作ネタとかオタクネタとかね)は、ロリポップの詞織でやろうかなと思っていますので、どうかよろしく。
 
 さて、ちょっとさわって見た感じの印象ですが。
「デザイン自由に出来ないな…」ってとこでしょうか。ロリポップの詞織みたいな感じにするつもりでいたら、テンプレートもほとんどいじれないみたいだし。トップの「タイトルバナー」と「背景」の設定はしましたが、このやりかたって厳密に言うとスキマ技という感じがしますね。
 この「詞織」みたいなデザインを狙うなら、「サブタイトル」欄を有効に活用するとよいようです。

 ツッコミを入れてしまいましたが、この「不自由さ」は「手軽さ」と表裏一体です。スタイルの変更も簡単で気分ですぐ変更できるのは大きいですね。MTと比べても、ポイントがこの「手軽さ」に置かれているのは明らかです。MTの設定まわりでつまづいたひとはぜひココログを試してみてください。

|

RSSについて

「詞織」ではまだ未活用状態の「Really Simple Syndication」、略称RSSについてのメモです。

「詞織」はもともとサイト更新情報を追うためのサイトとして計画されたということもあって、以前にちょっと書いた「はてなアンテナ」とか、このRSSのような「サイトの更新情報や概要を配信するシステム」というものにちょっと興味があります。
 ただフルカワ自身がいまだRSSを利用できるアプリケーション、いわゆる「RSSリーダー」を導入してないということもあって、現実問題としてそれがどのように便利なのか、とかどうやって使うのか、あるいはどのような方向に向かっているのか…まだまだ把握していないのですね。
 
 そんなわけで、taroさんがチェックしていたZDNNの記事をメモ。なるほど、いかにもなお話ですね…でも世の中あらゆる仕組みが複雑になってきてはいないか、複雑になっていってしまう歴史の流れは変えにくいものではないのか、問題は複雑になってゆくことではなく複雑でないようにみせることではないのか、などと考えたりもします。

エントリー後の追記は↓以下で。

Continue reading "RSSについて"

|

MTサイト構築のために(初MT。なわけです:2)

さて個人的なきっかけはともかくとして、MTサイトを作るためにどのようなサイトの情報が便利か?ということをメモしておきます。

・MTってなに?ブログ(Weblog)ってなに?
 そもそも私もよく分かりませんでした。ので、大枠についての印象を得るために、

  1.人気急上昇中のウェブログとは
  2.「ARTIFACT」のWeblogツールリスト

  とりあえず上記二つの記事でブログの大枠とMovableTypeがどんなツールなのかわかると思います。ちなみに2.のここにMTの項があります。

 で、私じしんの定義として。
・ブログ(Weblog)とはホームページのいち分類です。
・ブログ(Weblog)ツールとは、ウェブサーバ上に置くホームページ作成ソフトみたいなものです。ホームページビルダやフロントページ、Dreamweaverの仲間みたいなものですね。
・MTとは「MovableType(ムバブルタイプ、かな)」というブログ(Weblog)ツールのことです。
 ということで、MTサイトとは「MovableTypeというツールを使って作られたサイト」のことです。


 …と書くと、私のやってることは「新手のホームページ作成ソフトをつかってホームページを作ってる」ということになります。なんだ今までと同じだね。私の使う単語の羅列が分からなかった人も、これでなんとなくわかった気になってあげてください。


・ホームページの作り方がわからないんだけど
  これについてはどうなんだろう(汗) とりあえず

  3.とほほのWWW入門

  だいたいはわかるけど、スタイルシートがよくわからない。という場合は

  4.とほほのスタイルシート入門

・MTの設置の仕方がわからない
  この項については契約しているスペースによって異なってくると思うので、参考として私も利用している「ロリポップ!」のケースを。

  5.ロリポップでMovable Typeしよう! 
  6.「ロリポップ!」内の設置マニュアル

・MTを設置したはいいけど、なんだかよくわからない。
  初心者むけのインフォメーションとして、

  7.eblog:MOVABLE TYPE入門

・いろいろデザインをいじってみたい。

  8.BLOG質問箱

 とりあえずこの辺のサイトさんから参考にされてみてはいかがでしょうか。もちろん、もっと多くのサイトで有益な情報がみつかることを保証しますよ。

|

初MT。なわけです

 この味も素っ気もないホームページから全てがはじまる、のでしょうか?
ひっそりとフルカワblog「詞織(si olli)をはじめました。
 MTを導入しようとしている同士のために、私が導入するに至るまでの経緯をまとめておきます。

きっかけは加野瀬未友さんがWebログツールについてまとめられたことです。

 そもそも2003年6月ころの時期に、ツヴァイさんが小説サイト更新情報チェックサイト「小説大好き!」の3代目の総支配人を募集するという出来事がありまして、私は気分転換のタネに飢えていた関係からいろいろとそのような「サイト更新情報サイト」構築・運営をどのようにしたら楽にやれるかなー、とヌルいことを考えてぐりぐりとHTMLをいじってたりしたわけです。いわばプロトタイプ「詞織」が6月にはできてました。
 しかし、ブログをご存知のかたでなくとも知られつつある「はてなアンテナ」というサービスが存在する以上、手作業でHTMLを更新したりするのって意味あるのかな?という、なんだか存在意義の根本が揺るがされるような状況に気づきまして、このプロトタイプはいったん頓挫。
 それと同時期に、加野瀬さんがblog情報を次々とエントリーされ、その中でたとえば「昼のWeblog、夜のWeblog」のような、今までのホームページスペース(私の場合@niftyですが)ではやりにくかった、公的な内容と私的な内容の混在を許すようなサイトのあり方について知るに至り、いっちょbloggerを目指してみようかな、という流れになったわけです。

なお「小説大好き!」は現在、3代目の総支配人さんの下で再開準備が進められているようです。かげながら応援してます!

 以上のような流れがあって「詞織」は立ち上がりましたので、加野瀬さんの「ARTIFACT-人工事実-」ならびにツヴァイさんの「小説大好き!」の両サイトに感謝をささげたいと思います。

Continue reading "初MT。なわけです"

|