カテゴリ「Webサイト構築 」の記事一覧

画像を使用せずに角丸ブロックを実現する方法

HTMLの構造を直感的に理解する

CSSで画像を拡大表示(アクティブバージョン)

CSS(マウスオーバー)で画像をアニメーション(連続)表示

任意の要素を常に(スクロールしても)画面の中央に配置

CSS で画像を拡大表示させる

マウスオーバーで音を鳴らす

CSS記述規則「プロパティ別整理法」 その二

CSS記述規則「プロパティ別整理法」 その一

:first-letter と :hover の微妙な関係

リモートアシスタンス

ご指摘

Webサイト製作の指南方法

申し訳ありません。

XHTML1.1のMIMEタイプ

画像を使用せずに角丸ブロックを実現する方法

俗に角丸テーブルなどと呼ばれる装飾法がある。その必要がどこにあるのかは良くわからないが需要は高いらしい。しかしそれだけの為にtableを使うのは敬遠されがちだ。その代替手段としてdivを使用した方法もあるが、やはり画像を利用しなければならない為に面倒に感じる人や、装飾の為だけにdivを用いるのを嫌がる人も存在する。私もその中の一人だ。そこまでして角を丸くして得られるものがあるのか疑問だったので放置していたのだが、先日 Nifty Corners というページを見つけた。翻訳とは違うが自分なりに理解した事を書き連ねてみる。誤読も省略も多いであろう事を先に宣言しておきます。正確な情報が欲しい場合はリンク先の説明をお読み下さい。そして以下の説明に大きな誤りがある場合は知らせて頂ければ嬉しいです。

さて、画像を使用せずに角を丸く見せる方法ですが、細かい説明は省きます。なぜそうなるのかはソースを見て理解してください。id名なども変更していますし日本語やマークアップも少しおかしくなりますがご了承下さい。ファイル名やソースなどを変更しているのはわかりやすくする為でもあり、また、どこを変更しても良いのかを示す為でもあります。それでは先ずはDOM(もしくはJavaScript)を利用しない場合の方法です。

<div id="outer">

<span class="rtop">
<span class="r1"></span>
<span class="r2"></span>
<span class="r3"></span>
<span class="r4"></span>
</span>

<div id="inner">
<h1>タイトル</h1>
<p>ここに内部コンテンツを記入します。</p>
</div>

<span class="rbot">
<span class="r4"></span>
<span class="r3"></span>
<span class="r2"></span>
<span class="r1"></span>
</b>

</div>
span.rtop{display:block;background: #fff;}
span.rbot{display:block;background: #fff;}

span.rtop span{display:block;height: 1px;
    overflow: hidden; background: #69f;}
span.rbot span{display:block;height: 1px;
    overflow: hidden; background: #69f;}

span.r1{margin: 0 5px;}
span.r2{margin: 0 3px;}
span.r3{margin: 0 2px;}

span.rtop span.r4{margin: 0 1px;height: 2px;}
span.rbot span.r4{margin: 0 1px;height: 2px;}

div{background: #69f;}

基本的にはこれだけで 実現 できますが、外のdivの背景色と内部のdivの背景色の背景色を揃えたり、span.rtopやspan.rbotとその親要素(おそらくbody)の背景色を揃えたりしなければなりません。少し値を変更してみればどこに対応しているか直ぐに判断できるでしょう。参照先のページでは<b>を用いていますがここでは<span>を用いました。これはインライン要素ならば何でも良いようですが、emやstrongなどだと他のCSSが適用されている可能性があるので、普通はまず用いられない<b>を用いているようです。実際に利用する際は使用しないインライン要素を用いるのが良いようです。ちなみに外側のdivや内部の要素にもCSSは適用できますので自由に装飾が可能です。

本当はもうこれで終了なのですが、これだとまだ内部要素によって崩れるなど色々と問題があるようです。どのような問題なのかは割愛しますが、それほどの問題ではないような気がします。またこれは IE6,Opera7.6,FireFox1.0,Safari1.1 MacIE では動くようですが IE 5.x では動かないようです。まあ個人的にはこれだけでも満足なのですが、無用な要素を記述しなければいけない点と合わせるとやや使用には耐えられないと思うので、DOMを利用したスマートな方法も紹介します。当然の事ながらJavaScriptがオフの環境では角は丸くなりませんが、それによって崩れる事もないようです。margin や padding の取り方に注意しないと崩れる事もあるようでした。

その方法には二つのCSSファイルと一つのJavascriptを必要とします。

そしてこれらのファイルをhead内で以下のように外部から呼び出します。ファイル名は何でも構いませんが、当然のように揃えるようにして下さい。呼び出す順番が関係あるのかは検証していませんが、特に変更する理由がない限りはこのままにしましょう。

<link rel="stylesheet" type="text/css" href="corner.css">
<link rel="stylesheet" type="text/css" href="print.css" media="print">
<script type="text/javascript" src="corner.js"></script>

さてこれで準備は整いました。呼び出すJavaScriptの内容は私にはあまり理解できていません。とりあえずはIE5.x PCを除く判定をし、色々なパラメータ?を吐き出している様ですが、それを新たに指定するためにもう一つのJavaScriptが必要になるそうです。また、セレクタの種類や使用できるidやclassにもある程度の制限があるようなのですが、詳しくはわかりませんでした。複雑なものを用いらなければ平気だと思われます。まあ使用できるのはタイプセレクタ、クラス(class)セレクタ、一意(id)セレクタ、簡単な条件下の子孫セレクタという事だと思います。

それではここからはその新たに必要なJavaScriptの書き方を場合別に例示します。その前にJavaScriptの共通部分の説明をしますと以下のようなJavaScriptを挿入することになります。

<script type="text/javascript">
window.onload=function(){
if(!NiftyCheck())
    return;
/* ここに場合別に記入するソースが入ります */
}
</script>

これは埋め込み型ではなく、外部から呼び出しても良いようです。それでは例をどうぞ。

単純な角丸
Rounded("div#outer","#ccffff","#6699ff");
<div id="outer">
<h1>画像無しで角丸装飾</h1>
<p>ここでは画像を使用しないで角を丸く見せる方法の解説をしています。</p>
<h2>例えばここが小見出し</h2>
<p>おそらく要素は何でも使用できると思います。</p>
<p>ソースを見ればどの部分が重要なのかがわかるようにする為に余計な装飾部分は省いています。これ以後のサンプルではdivのid名などには手を加えていません。</p>
<p>装飾はあくまでもオマケであって、大事なのはJavaScriptの部分です。最初に適用させるボックスを指定して、その背景色を順に指定しています。どちらの色をどこと合わせなければならないのかは続けて書かれているCSSと比べれば容易に判断できるでしょう。</p>
</div>

これが全ての基本です。段々と説明や改変が面倒になってきたので次の例からはサンプルをそのまま使用させて頂きますが、余計な装飾部分をなるべく省いています。しかし何がどう影響するのかはCSSを見れば一目瞭然なのでそこまで厳密に手を加えていません。ソースも実際のファイルから読み取って下さい。レイアウトが崩れている可能性もありますが、それは本質とは関係ないので無視します。

divを二つ
Rounded("div#content","#fff","#9DD4FF");
Rounded("div#nav","#fff","#E5FFC4");
小さな角丸
Rounded("div#header","transparent","#C3D9FF","small");
Rounded("div#box","#FFF","#E4E7F2");
上下で違う色の角丸
RoundedTop("div.news","#FFF","#91A7E3");
RoundedBottom("div.news","#FFF","#E0D6DF");
角丸部分を透過させたタブメニュー
RoundedTop("div#nav li","transparent","#E8F0FF");

説明の上ではタブメニューである必要はないのですが、新たなサンプルを書く気力が無いのでそのままにしてあります。ポイントはタブメニューではなくて背景に画像を用いた場合にtransparentで透過する所にあります。

もう二つほどサンプルはあるのですが、説明が必要だとは思えないので割愛させて頂きました。参照先を見れば直ぐに理解できると思いますし、基本を応用するだけで目新しい物はありません。

どのようなCSSを適用させるのか、どのように利用するのかは割りと自由に設定できるようです。基本的には角を丸くしたいブロックを指定して背景色を指定しているだけなのでそう難しくはありません。最後に一連の流れをまとめておきます。

  1. DOMを使用しない方法があるが、余計なソースを記入しなければならないのと幾つかの環境では使用できない問題がある
  2. そこでDOMを利用して実現させる
  3. 先ずは corner.css print.css corner.js の三つを用意する。
  4. 角丸を適用させたいページで上記三ファイルを
    <link rel="stylesheet" type="text/css" href="corner.css">
    <link rel="stylesheet" type="text/css" href="print.css" media="print">
    <script type="text/javascript" src="corner.js"></script>
    
    のようにして呼び出す。
  5. 新たにJavaScriptを書いて細かい設定を行う

これだけです。説明の便宜上新たに指定するJavaScriptはHTMLファイルに埋め込みましたが外部指定でも平気なようです。またそれは別途装飾用のCSSファイルも同様です。新しく指定する全てのJavaScriptを一つのファイルにまとめておくことも出来るようなので、そうすれば後からの変更も容易になるでしょう。

ハッキリ言って翻訳は適当ですし、説明の為に改変したファイルが全ての環境で上手く動作しているかどうかは不明です。正確な情報が欲しい場合は Nifty Corners から得て下さい。

あまりにも拙い説明で申し訳ありませんが、なんとなくわかって頂けたのではないかと思います。わからない事がある場合にはコメント欄にでも書いて頂ければ時間の許す限りわかる範囲でお答えしたいと思います。それでは最後までお付き合い頂いてありがとうございました。

現状で気がついた問題点

  • margin や padding の取り方に注意しないとJavaScriptのオンとオフとで表示が若干異なる場合もある。
  • 角を丸くしたボックスに対してpaddingを指定するとややこしい事になる。
  • あまり細かい要素に使用するには向かない。
  • つまり他の要素を内包する位の大きさのボックスが望ましい。
  • <h1> や <p> などにも指定できるが padding を指定しないとJavaScriptをオフにした時に読み難い。
  • <p><span>段落</span></p>などとすれば良いかもしれないが美しくない。
  • heightを指定するのにも注意が要る。
  • 画像を用いた方が早い

反省(2005年10月16日01時10分)

随分と前に語り尽くされた話題のようですね。自分で Google博士に訊いてみよう とか言っておきながらなにやってるんだか。

Nifty Corners の発展版もあるようです。


HTMLの構造を直感的に理解する

手動定期巡回先hxxk.jpさん 経由で DIV要素で構造を補強 を読みました。とてもわかり易いと感じました。HTMLをこれから勉強する人というよりも、CSSを勉強しようとする人に対して更に有益だろうと思いました。ただ、一つだけ気になる点がありました。ツリー構造の部分で、

この図でのルート要素は「body」で (通常、HTML文書のルート要素はhtmlになります) 、その下にずらっと各要素が並列に並んでるな。要素で見たら、これは弟の部屋と同じ構造や。これでもどこも間違ってないで、見出しはH1,H2要素、段落はP要素と構造化された綺麗なHTMLや。 DIV要素で構造を補強

となっている箇所についてですが、確かにbody直下に並列に並んでいるのですが、各要素のレベルが違うので弟の部屋のようにそこまで煩雑ではない筈なのです。説明したい部分はそこではないので説明の便宜上、敢えて触れないようにしているのだと思いますが、アウトライン(補強する前にも既に存在している構造)についても少し触れた方が親切かなと思いました。そうしないと全ての要素が同じレベルだ(意味的にも並列である)と思い込んでしまう人や、要素の順番を軽視(意味が無いと勘違い)する人が出てきそうだからです。つまり下記のような記述では意味が異なってきてしまうという意味です。

<h2>9/25日の日記</h2>
<p>今日は無印良品で生活雑貨を沢山買いました。</p>
<h2>9/24の日記</h2>
<p>こんにちわ。今日は朝から雨が降っていて洗濯物が干せなくて困ってます。</p>
<h2>9/25日の日記</h2>
<p>今日は無印良品で生活雑貨を沢山買いました。</p>
<p>こんにちわ。今日は朝から雨が降っていて洗濯物が干せなくて困ってます。</p>
<h2>9/24の日記</h2>

また、これはdivで括ったとしても意味合いが異なります。

<div class="diary050925">
<h2>9/25日の日記</h2>
<p>今日は無印良品で生活雑貨を沢山買いました。</p>
</div>
<div class="diary050924">
<p>こんにちわ。今日は朝から雨が降っていて洗濯物が干せなくて困ってます。</p>
<h2>9/24の日記</h2>
</div>

流石にここまで極端な事は無いと思いますが、日記などのわかり易い物でない場合はこのような事が起こるのも容易に想像できます。これは各要素が属する見出しが、その要素を書く場所によって潜在的に決定付けられるている為に起こる錯誤です。そういった意味では、body直下に並列に並んでいる要素でも、それぞれ属するグループが場所によって既に決まっている事になります。つまり部屋の例で言うのならば、あちこちに物があって重なったりしている状態と言うよりも、床などに綺麗(順番)に並べられている状態の方が近い気がします。まあそもそも部屋にあるものに見出しと段落の差のようなレベルの違いはないので難しいとは思いますけれども、補強する前にも既に存在しているHTMLの基本構造(各要素)の相関についての何らかの説明も含んでいると、より良かったのではないかと思う次第です。

と言うよりもちゃんと最後に

って・・・。ほんとはDIVなんかの話がしたいんじゃなくて、並列に並ぶ要素で繋がりのあるものは適切な要素でマークアップして構造化を強めよう!ってのが書きたかったんだけど、HTMLだとどうしても主役がDIV要素になっちゃうな。

この記事は文書の構造を表すHTMLの基本要素の使い方を覚えた後に見ないと意味が無いかもしれないね。 DIV要素で構造を補強

と書かれていましたね。失礼しました。ちゃんと読まないと駄目ですね。申し訳ないです。やはり真琴さんが

もちろん、ある程度理解が進んでいる方向けに、もっとつっこんだ説明をすることもできる点はありますが、 HTML の構造化というものの理解への導入を促すには充分だと思います。 hxxk.jp - HTML の構造化を分かりやすく解説

と仰っているように、(意味合いは異なりますが)少々邪道だったかもしれません。反省しています。ちなみにあまり関係ありませんが 前にも書きました ように私は div恐怖症患者 だったりします。

自分の為にフォローしておくと今回のタイトルはDIV要素を使った構造の補強ですので、何も間違ってはいませんし、説明するに当たって私がここに書いたような事は邪魔ですので排除したのかもしれませんが、少しだけ気になったので書かせて頂きました。

ところでclassとidの説明はどうなるでしょう。漫画本と参考書の例でもclassとidの説明が出来そうですね。でも違う事象に同じ例を使うのはわかり難くなりそうですし、次は全く同じデザインのクリアボックスをdivに見立てて、中身が一目でわかるように張って置く紙をclassなどとするのでしょうか。それとも設定をまったく変えるのでしょうか。楽しみです。


CSSで画像を拡大表示(アクティブバージョン)

以前 CSSで画像を拡大表示させる でマウスオーバー時に画像を拡大表示させる方法を書きましたが、マウスオーバーしただけで画像が拡大されるのは邪魔くさいかもしれないなと思ったので、今回はクリックしたら(アクティブ状態になったら)画像が拡大される方法について考えてみました。例によって例の如くJavaScriptは使わずにCSSのみで、確認をしたのも 閲覧想定環境 だけです。

マウスオーバーの時は :hover を用いました。今回はもちろん :active です。通常のブラウザならばimg要素に適用させて云々で簡単に済むのですが、やはりIEという禍々しいブラウザが存在します。あまり調べていないので正確ではないかもしれませんが、どうやらIEはa要素にのみ :active をサポートしているらしいです。という訳で a要素 を使用しなければなりません。しかもそれに加えて href属性 も付加しなければなら無いという始末。更に更に href属性 にURIなどの意味のある値を与えてしまうとページを移動してしまうので値は意味を持たないものにしなければならず、この時点でHTML文書の意味的に成り立ちそうもないので諦めようと思ったのですが遊びと割り切って創りました。以下がそのCSSとHTMLです。

/* 元画像の大きさ */
ul.pop li {width: 160px;height: 120px;}

/* 拡大後の大きさ通常ブラウザ用(li要素をクリックした後の大きさ) */
ul.pop li:active {width: 320px;height: 240px;}

/* 拡大後の大きさ。主にIE用(と場所positionのtopやleftはお好みで。でもposition: absolute;は消しちゃ駄目) */
ul.pop li a:active {
	width: 320px;
	height: 240px;
	position: absolute;
}

/* ↑ここでは拡大前も拡大後も全て同じ大きさの前提なのでまとめていますが、
違う大きさにしたい場合はul要素毎、もしくはli要素毎にclass指定をする事で可能です */

/* 元画像(幾らでも増やせます) */
.gij {background-image: url(gis.jpg);}
.eki {background-image: url(tos.jpg);}

/* 拡大後に表示する画像-通常ブラウザ */
li.gij:active {background-image: url(gim.jpg);}
li.eki:active {	background-image: url(tom.jpg);}

/* 拡大後に表示する画像-IE用 */
.gij a:active {background-image: url(gim.jpg);}
.eki a:active {background-image: url(tom.jpg);}
<ul class="pop">
<li class="gij"><a href="#n">国会議事堂</a></li>
<li class="eki"><a href="#n">東京駅</a></li>
</ul>

説明は苦手です。概要を述べますと、先ずはブロック要素にwidthとheight値を与えます(拡大前の大きさ)。そしてこのブロック要素の背景に縮小された画像を用います。次に拡大後の大きさを :active を用いて指定するのですが、ここからIEに対しての分岐が必要になり、わざわざ a要素 を用いなければなりません。そこでli要素をクリックした場合の拡大後の大きさ、a要素をクリックした場合の拡大後の大きさ、li要素をクリックした場合に拡大表示させる画像、a要素をクリックした場合に拡大表示させる画像、と二通りずつの指定をしなければなりません。説明はこんな所です。後はソースを見ればくだらない事をやっているなとわかるでしょう。まあ一応もう少しだけ詳しい説明とサンプルを置いておきます。

利点としてはHTMLファイルに直接画像を置かない事と、拡大前の画像と拡大後の画像を二枚用意する事で通常(大きな画像を無理やり縮小して並べたり、拡大前の画像と拡大後の画像を同時に使用した場合)よりもページの読み込みがスムーズになるかもしれない事ですが(CSS(経由)の読み込みに時間が掛かるかも)、やはりJavaScriptを使用した方が圧倒的にスマートですね。CSSだってオフにされてしまったりユーザスタイルシートを被せられてしまえば終わりになってしまいますし。しかも今回は画像自体をHTMLファイルに登場させていないので、CSSを切られてしまうと画像が表示されずに文字列だけになってしまいます。それをクリックして画像が表示されれば良いのですが、前述したように href属性 の中身に意味のある物は書けないので実現不可です。title属性などを付加して画像の説明を書いておくなんて言い訳がましい方法もありますが、やはり全体的に無理があるような気がします。とても実践向きとは言い難いですね。


CSS(マウスオーバー)で画像をアニメーション(連続)表示

また人の記事を引っ張ってきてしまいました。たまたま観ていたはてなブックマークのCSSでアニメーションができますよ~!という題名に惹かれて覗きに行くとそこには魅惑の世界が。なんでもWebReferenceというサイトでその方法が紹介されていたらしいです。英語は苦手なのですが、まだcat@logさんの所ではサンプルが出ていなかったのでExcite先生に翻訳してもらいながら形だけのサンプルを作ってみました。以前紹介しましたCSSで画像を拡大表示などを併せるなどして応用すれば、ギャラリーなどで上手い具合に使用出来るのではないでしょうか。

実行例の下部に配置されているグラデーション部分をマウスオーバーすると写真が次々と変わると思います(最初は画像の読み込みに少し時間が掛かるかもしれません)。ここでの詳しい説明は省かせて頂きます。と言うのもまだ詳しい説明が出来るほど私自信の理解が深まっていないのです。それから例によって閲覧想定環境のみでしか確認しておりませんので悪しからずお願い申し上げます。割と即席なので不具合も予想されます。

それにしても本当にCSSって色々と出来るのですね。普段JavaScriptをオフにして巡回している、JavaScriptに対して圧倒的に無知な私にとっては嬉しい限りです。


任意の要素を常に(スクロールしても)画面の中央に配置

先日のCSSで画像ポップアップに続いて再び弄ってみました。実用性は確かに微妙ですね。でも各所フォーラムを回っているとこの手の質問も少なくないので意外と需要があるかもしれません。まあ大抵の場合はテーブルレイアウトで解決してしまう場合が多いのですが。

色々書くのはスペース的に無理がありますし、実際にこのページで表現するにしては事情が特殊なのでサンプルを置いておこうと思います。もちろん同じ物を書いてもただのパクリで何の意味も成さないので手を加えています。e-luckさんのサンプルでは、おそらくスクロールが生じた時に画面中央には表示されなくなってしまうと思うので、その辺りを中心に加工してみました(アイディアだけ貰って勝手に利用してしまってすいません)。最初に断って置きますが閲覧想定環境のみでしか確認していませんのでご注意下さい。

<p id="cent">
中央に表示させたい要素
</p>
<div id="waku">
fixedが効かないIE用の擬似bodyの様なもの
</div>
html,body {
    margin:0px;
    padding: 0px;
}
body {
    background:#fff;
    height: 100%;
    _overflow: hidden;
}
div#waku {
    overflow: auto;
    height: 100%;
}
p#cent {
    position:fixed;
    left: 50%;
    top: 50%;
    border: 1px solid blue;
    _position: absolute;
    width: 160px;
    height: 120px;
    margin-left: -80px;
    margin-top: -60px;
}

何の説明も無いのは不親切なので簡単に書きます。中央に表示させたい要素はp要素でなくても構いません。先ずはFirefoxやOpera向けに要素にfixedを当てています。しかしIEには効かないのでハックを利用してIEにのみabsoluteを与えます。この時に基準となるbody要素にheight:100%;を指定し、これまたハックを利用してoverflow: hidden;を指定します。しかしこのままではスクロールが不能になってしまうので、p要素以外の(別にp要素を含めても構いませんが)要素をdivで囲ってスクロールを出来るようにしてやります。

また、p要素にborderが付いているのはわかり易くする為なので必要はありません。htmlやbodyのmarginとpaddingも必要に応じて調整して下さい。p要素のwidthやheightはボックスとして認識させた方が、ずれることなく画面の中央に表示させる事が出来るからです。ネガティブマージンについてはLucky bagにも書いてありますが、left: 50%;やtop: 50%;はその要素が始まる位置を指定する物で、要素の内容が縦に伸びたり横に膨らんだりすると中央からズレてしまいます。そのために要素の大きさと、そのネガティブマージンを調整してやる必要があるのです。

これで説明は終わりですが、特にハックの箇所などを中心に、とてもスマートと呼べる代物ではありません。もっと上手く書く事も可能でしょう。こんな方法や書き方があるというトラックバックがあれば嬉しいなと思います。ついでに言えばあ、今確認したら Opera ではうまく行かないみたい。というのは私のサンプルでも同様です。どうやらOpera特有のバグらしく、似たようなものでこんなバグはあったのですが、それとは少し違って、絶対配置要素のtopプロパティの値を相対値にしても上手く動作しないという感じなのですが、誰かこの解決方法を教えて下さい。


CSS で画像を拡大表示させる

私の中ではかなりの革命です。なぜ今までこれに気が付かなかったのか。きっとIEのhoverに対する実装が甘かったせいかもしれません。なにか 本家 とはCSSの書き方や画像の表示のさせ方が違いますが、一応動作しているので細かい詰めの部分は後で考えようと思います。表示させる場所や、拡大した後の周りのレイアウトの崩れを気にしないのならばpositionによる細かい指定は不要のようです(私はこちらの方が好み)。クロスブラウザかどうかはわかりませんが、閲覧想定環境 では意図通りに動作しているので良しとします。

追記(2005年11月24日01時10分)

何の影響なのか定かではありませんが、Firefox1.0.7では上手く動かなくなりました。

お気付きの通り、画像の大きさに関する指定はCSSで一括してしまっているので、画像毎に大きさを変えたい場合は不便です(その都度class指定を加えて行けばできますが。画像の大きさを指定するだけの別のCSSファイルを用意してみても良いかもしれません)。しかも代替縮小画像を用意せずに大きな画像を縮小して表示しているのでファイルサイズが大きな画像の場合は注意が必要です。しかし何かの画像付きのチュートリアルや、サムネイルを並べて写真を展示する場合など、画像の大きさが一定でも構わない場合などでは使い道があるのではないでしょうか。私には目からウロコでした。

ちなみにこの方法で最低限必要なのは以下の記述だけです。

a:hover
{
	background-color: 適当な背景色(transparentだと駄目みたい);
}
a:hover img
{
	width:拡大時の横幅;
	height:拡大時の縦幅;
}
<p><a href="パス"><img src="画像パス" alt="代替" width="最初の横幅" height="最初の縦幅" /></a></p>

説明すると、a:hoverに対する背景色の指定はIEできちんと動作させる為に必要なのだそうです。最初に表示させておく画像の大きさもCSSで指定してしまう事も出来ますが、CSSをオフにした時の事や、class指定を用いて複数の指定をする場合には不便なので画像の属性として直接指定した方が得策なようです。そして親要素やa要素、もしくはimg要素にclass指定を用いる事によって、a:hover img.photo などのセレクタに width:拡大時の横幅; height:拡大時の縦幅; を新たに指定してやれば、拡大後の大きさも個別に指定できます。


マウスオーバーで音を鳴らす

とても面白そうだったので あれこれポップアップ に続いて導入してみたのですが、ActiveX の受け入れ状態によっては面倒な事に。なんだか色々な実験をする為のブログになってきた感じがします。

ところでこの操作の核となる JavaScript なのですが、何をどう書き換えて良いのかわかりませんでした。一応それっぽく書き直してみたのですが不安です。どこかに迷惑がかかっていなければ良いのですが。特に下方の超重要!!下のテキスト内のURLを自分がswfファイルをアップした場所の絶対URLにすること!!!!の意味がわからず、どこも書き換えていません。なぜかと言うとvar swfURL = "soundunit.swf";と最初に定義していて、必要な箇所はvalue="' + swfURL + '"とかsrc="' + swfURL + '"ってなってるし。元のJavaScriptのファイルを見ると、var swfURL = "soundunit.swf";が無くて、必要な箇所にそれぞれURLが入っているので、私の予想では仕様を変更した時に注意書きを消さなかっただけなのかなと思っているのですが、そんな勝手な推測は止めてどなたかに助言を求めた方が良いかもしれません。

と言う訳で、なんとも身勝手で傍迷惑な話ですけれどもリファラとトラックバックを送ってみて、何か迷惑が掛かっている様ならばご指摘を頂けるようにしてみておく。使い方が間違っている可能性もあるのでとても心配だ。まあそんな目的よりも実際に利用しているページが紹介サイト以外に見当たらないので、何かのサンプルになればと思っている。ついでに書くと、ActiveXを無効にしている場合は動作しようとしないようにするのと、音がウルサイという人の為にオンとオフが簡単に切り替えられるようになれば良いかなと思う。私的にはJavaScriptはオフの状態なのでどちらでも構わないのですが。JavaScriptやActiveXをページ別に設定してもらえれば良いだけの話ですし。しばらく様子を見て評判が芳しくなければ中止しようと思う。

ところで私はこれが素晴らしい技術(アイディア)だと思うのですが、実際のところはどうなのでしょうか。(極簡易的な)○○メソッドよりも面白いと思うのですが、それに比べて反応が少な過ぎるように感じます。JavaScriptやFlashもあまり使用しない、Ajaxのなんたるかも知らない私が言う事ではないのかもしれませんが。さらに加えるならば fladdict.net blog には他にも面白いアイディアが豊富にある。例えば カラーピッカー などは非常に興味深いです。実際のサイトで利用するかどうかはわからないですけど、Webサイトを構築する場合の配色決定に用いる事もできます。コンポーネント指向Ajaxの世界 ではさらに想像を広げていらっしゃいます。残念ながら私の知識では全くついて行けていません。なにせ私は簡単なJavaScriptですら書くことができないのですから…。

追記です。私のFirefox(1.0.4)だとしばらく音で遊んでいると落ちます…。何かとの相性が悪いのか、私の使用法が間違っているのかは不明です。それからアクセス解析も異常な数値を返してきます。様子を見て続くようならば考えようと思います。


CSS記述規則「プロパティ別整理法」 その二

昨日書いたものにいまいちしっくり来ないので一晩置いてから考え直してみたのですが、どうやらグループ分けという言葉に対してややズレがあったようです。まあそれは大した問題ではなく、もっと重要なのはプロパティ別整理法を用いた場合に、その利点 が、図書館方式の欠点が本当に補われているかという点でした。

例えば本当に「君の名は問題」が発生しないのか?これはCSSファイル内のグーループ分けに置いてはプロパティ別に整理されているので発生しないと思われるが、もう一歩踏み込んで実際に編集する時に、ここの margin を変更したい、margin についてはここにまとまって記述されている。とここまでは他の利点として挙げられている 並び順はプロパティのアルファベット順に基づくため、自明である。変更対象が巨大なCSSであったとしても、変更すべきプロパティさえ認識していれば変更個所の探索は容易である。 の通りであるが、しかし結局は「この部分ってどのdivだっけ?」となるのではないだろうか。それは結局CSSファイルが膨大になればどちらにしても起こる現象で、結果的にはきちんとした class や id による名前付けと把握が必要になるのではないかと思う。つまり、余計な一手順を踏むことになってしまうのではないかと思う訳だ。最初から div.hoge を探せば良かった所を、先ずはプロパティを探して、そこに列挙されているセレクタから div.hoge を探さなければならない。これは本当にメンテナンス性が向上し、無駄な時間が省けるのだろうか。どうやらここが一番引っ掛かっていた所らしい。なんとかスッキリした。

よく読むと同じ意見があったりする訳でなんとも…。これまでに書いたことは以下の意見に集約されるようです。

要するに機能分割やネーミングなどをちゃんとしてないからグチャグチャになるってことじゃないかしら? atsushifxの七転八倒

これに対して あきやんさん は 機能分割やネーミングにかかる時間がもったいない、と考えています。 と応えていらっしゃいますが、div に対して class や id を付けるのと同じだと思うので気にするほどの時間がかかるかどうか疑問です。つまりは以下のような意見です。

要はCSSの記述の仕方をどの程度まで厳密にルール化し、またそれを維持するかってことに尽きるのではないかと思います。特にid/class属性値の命名規則とか、mozilla.orgのCSSファイルで話題になった同一セレクタ内でのプロパティ登場順、といった部分のルール化ですね。覚え書き@kazuhi.to

さらに究極を言えば下記の通りです。

これは面白い! わくわくしてきます。当サイトの扱うレベルにおいては、CSS は作ってお終い、メンテナンスという段階は存在しません。だから当サイトで今後、プロパティ別整理法をフィーチャーする機会はほとんどないでしょうが、ヘビーなカススタイラーの方々には、非常に魅力的な提案だと思いますね。ウェブサイト製作のステップと CSS 記法の選択

以上の事から言えることは、私が昨日から今に至るまでに書こうとしていた意見は既に出されていたという事ですね。義務教育の時に「○○君と同じです」「□□さんと一緒です」などという答えはしてはならず、例え同じ意見でも一字一句同じという事はないのだから、必ず自分の言葉で意見を言いましょうと教育された結果がこの状況なのでしょう。それが正しかったのか間違っていたかの議論は今は関係ありませんが。

それからこのエントリーを記述するに当たって、引用部の CSS などを弄っていて気が付いたのですが、私はプロパティをまとめるのが苦手らしいです。例えば margin にしても一括指定すれば良い所を margin-top などを用いてみたりしています。background などにしても同様ですね。ですからプロパティで選別する時に margin という括りを作った場合、そこには他の top right bottom left も作らなければならず、より一層複雑化しそうです。まあこれは私に限った極小数の意見でしょうけれども。

それにしても本当に新鮮な提案で、その実益の有無や賛否に関わらず、こうやって何か新しいものについての自分の意見をまとめるのはとても楽しかったです。そういった機会を与えて下さった あきやんさん に感謝します。

それでは末尾になりますが、昨日のエントリーで あきやんさん のお名前が あきひこ となっていた事を深くお詫び申し上げます。直ちに訂正させて頂きました(置換作業時のミスでした)。本当に申し訳ありませんでした。また、該当エントリーについて あきやんさん ご本人から丁寧なメールを頂戴いたしました。とても嬉しく思い、しっかりと読ませて頂きました事をここにご報告します。


CSS記述規則「プロパティ別整理法」 その一

CSSの記述の仕方として プロパティ別整理法 なるものを見つけた。なるほど。なかなか面白い提案だと思う。ただ、実用的かどうかはそれぞれの判断(個別の感覚や技術レベル、マークアップ)に任されるのではないかと思う。最初が肝心、でももう遅い のような状態の場合には有効なのかなと思うが真偽の程は不明だ。(たまたま最近読んだ記憶があっただけの紹介ですいません)

何かを推し進めたり提案したりする場合は、先ずは否定的な要素(もしくは欠点)を示し、それについての対処や、その問題点が取るに足らない物であるとのだと説明して行き、それを潰した上で、どのような利点があるのかを説明すると、より効果的だ。その際には既存他法と比較をして、その優位性や特異性を示したりするのが得策である。その時に気をつけなければならないのは既存他者をなるべく否定しないことだ。基本的にしていい否定は客観的な判断から浮き彫りにされる欠点だけだろうと思う。というのが持論です。ってちょっと話が逸れました。要するに プロパティ別整理法 は良く書けているのではないかと言いたかっただけです。特に共感できる部分としては、反応リンク集 において色々な意見を掲載している所です。ただ、何かの宣伝広告のように好意的なものばかり載せると逆効果になってしまうところが難しいかもしれません。

そんなこんなで実際に試してみようと思ったのですが、私にとっては図書館方式のデメリットよりもプロパティ別整理法のデメリットの方が大きい。とりあえず図書館方式のデメリットについて書いてみる。

「君の名は問題」が発生する。
私は必要以上にグループ分けをしないのでこの問題は殆ど起こらない。
スタイルを記述する際に、どのグループに含めるか考える必要がある。その判断は、製作者に委ねられる。
上に然り。body直下か、せいぜい二つのグループ分け程度に収まっている。
「こうもり問題」が発生する。
同様。後から新たなグループを形成する事は殆どない。そうなる場合は全てを見直す時。
「複数属性問題」が発生する。
う~ん。グループ分けを主としないスタイルの記述をしている人には上記も合わせて問題とは思えないのかも。
そもそも、どんなグループ or グループ名が存在するのか忘れてしまう。
一つや二つだと忘れません。
問題が顕著化したとき、スタイル変更時に変更対象の探索が困難になる。
いや、感覚的に把握しているのでむしろわかり易いような。しかも上部から順に記述する訳ですし。
変更対象が巨大なCSSの場合、変更個所の探索は困難を極める。
無駄な記述、詳細なグループ分けをしている場合は確かにそうかもしれませんね。
継承するスタイルの場合、HTMLに入れ子構造を採用しているとどのレベルで定義されているのか把握し辛くなる。
これはあります。こっちのスタイルを変更したはずなのに向こうのレベルのスタイルが継承されていてなんて事も。
CSSが巨大になるとグループ分けが機能しなくなり、グループの中での並び順が重要になってしまう。
上(外)から順番に書いて行くので…。

え~っと。そういう訳で私には図書館方式で充分な様です。どちらかと言えばプロパティ別整理法のデメリットである あるセレクタに対して、どのようなスタイルが指定されているか一望出来ない。(ただし、Grep検索によって解決することができる) の方が私にとっては辛いです。Grep検索で出来るといいますが、こちらの方が編集に時間や手間が掛かるような気がします(秀丸エディタを使用していない人はどうするんだろう)。それから 感覚的とはいえない。 これも痛い部分です。

私がスタイルを変更する時にはあるブロックに対してどのようなスタイルが設定されているか、またそのブロック内の要素にはどのようなスタイルが設定されているかという順で把握している。つまりはセレクタ毎に考えている訳で、ここの背景はこれで、ここのボーダーはこれで、そこのマージンはこれでなどとプロパティ毎に考えていない(いや、だから今回の話題はそうしませんか?という提案なんですけどね)。これはその方が圧倒的に便利で把握し易く、編集にも時間がかからないからだ。つまりは私にとってはプロパティ別整理法の方が無駄な時間がかかるのだ。これは慣れとかそのような問題ではなく、感覚的な問題であって、それを覆すのは無理であろうと思う。いや、そもそも覆す必要も無ければ、その時間や労力が無駄だ。

以上の事からおそらく私は 例外ケース に当てはまるのであろうと思いますが、そもそもCSSが膨大になるような書き方っていかがなものでしょうか。そういう書き方をしてしまう人の為のメンテナンス性の向上のツール(提案)としては最初に述べた通り、面白いと思います。ただし、自分で書いたものを把握できない状態で、並び替えられた物を把握できるかどうかは疑問ですが。

本当は以上で終わろうと思ったのですが、誤解が無いように繰り返し書いて置こうと思います。以上の事はあくまでも私が例外ケースに当てはまるだけの事であって、世間に広まったら面白いのではないかと思います。そしてその際には Grep検索 が利くようなツール、つまり編集時に瞬時に自動(相互)変換してくれるようなエディタがあれば尚良いのではないかと思います。

ただそれでもやはりこの『プロパティ別整理法』を 導入しなくてもいいように、より例外ケースに近づけて行くべきではないかと思う訳で、そういった意味では最終的には“提案”で留まってしまうというのが悲しい性なのではないかと思う次第です。

それからこれは直接は関係ありませんが、プロパティ別整理法に近い例 として紹介されている ユーザースタイルシートのススメ ですが、これはあくまでも“ユーザースタイルシート”の記述方として紹介されているのであって、サイト構築におけるスタイルの記述方とは根本的に異なるものではないかと思うのですがどうなのでしょうか。ユーザースタイルシートのススメの執筆者である そふぃあさん がこの記述方を採用していたり、推奨しているのなら良いと思いますが、例として既存の物を挙げているだけならば、あきやんさん ご本人が過去に作成したCSSと整形した結果のCSSを提示しているのでそれで充分だと思う。

ところで あきやんさん ご本人も例外ケースとして挙げているが、無難なマークアップ(無駄なグループ分けをしない)をしている場合はCSSの量はそれほど多くもならないし、複雑にもならない。この場合は図書館方式の方が優位なようだ。そこで あきやんさん 本人のマークアップやCSSはどうかと思い拝見させて頂いたが、ややグループ分けが多いように感じられるものの、(私が言うのも難ですが)簡素で綺麗なマークアップをしていらっしゃるのではないかと見受けられます。CSSのサイズも大きくないですし、図書館方式でも充分に行けるのではないかと思うのですがどうなのでしょう。やはり感覚的な問題でプロパティ別整理法の方が性に合っているのでしょうか。この提案の為にわざとプロパティ別整理法を用いていると見るのは穿ち過ぎでしょうか。


:first-letter と :hover の微妙な関係

ちょっとバグ?発見。長い文章を読むときに、ずっと同じ大きさの文字だと段落で区切ったとしてもなんとなく目が疲れる。それを解消するためにありがちな、段落の最初の文字を大きくして色を変えるなんて事をやろうと思って、CSS の first-letterプロパティ を用いようとしています。ただやはりブラウザの CSS対応状況によって仕様が異なるので使い難いのです。と言う訳で既知だと思いますがいくつか気が付いた物を。

とりあえずこんな所です。上記二つは解決策があるが、三つ目 についてはなかなか痛い。段落の先頭にリンクを持ってこなければ良いのだが、そういう訳にもいかない。見出しのリンクで first-letterプロパティ を使用したいと思うことは多々ある。解決策は ないことはない らしいが、やはり いまいちスッキリしない。書かれた記事の日付から考えるとそろそろどこかで解決されててもおかしくなさそうなのですが、どうなのでしょうか。

試行錯誤の結果。個人的であやふやな方法ですが、見出しの方はなんとかなったようです。ただ、段落の方は line-height や letter-spacing を調整してみても“ピコピコ”点滅したりします。display:none; にしてみたりしてみましたが駄目でした。なにか有効な回避方法がありそうなのですが見つかりません。


リモートアシスタンス

以前 Webサイト製作の指南方法 でリアルタイム通信添削について触れた。その実証については SSさん が実際に行った記録 がある。やはりなかなか難しいらしい(まどろっこしい?面倒?)。

話が前後するが、今日はにわか雨に降られて本屋で雨宿りをした。その時にPC系の雑誌に リモートアシスタンス でパソコンを遠隔操作する方法が載っていた。記事は実家などの遠く離れた所にあるパソコンを実際に操作してトラブルを解消するというものだったが、これを応用できないだろうか。

あまり深く考えてから書いている訳ではないのでいくらでも問題点はあるだろう。skype と比べた場合の問題点やそうでない問題点もある。思い付くままに挙げてみる。

とまあ簡単に思い付くだけでこれだけのデメリットがある。逆に「メリットは?」と問われれば大して思い付かない。同じ画面を見て説明が出来るが、これは Webカメラ があれば他の方法でも可能だし、唯一と言えるのは相手のパソコンを動かせる事だが、これがハッキリとメリットかどうかと問われればまた答えに窮する。

という訳で、こんな方法もあるんだなという個人的な思い付きでした。実際に取り入れる気も検証する気もないです。


ご指摘

当サイト について Weblog において 三宅 龍太郎 さんから大変貴重なご意見を頂戴した。ご指摘はごもっともな事ばかりで反省の連続だ。これからは修正に時間が取られる事になりそうだ。どのような事だったかのかは実際に該当記事を見て貰えればわかる。それについての私の言い訳はコメントさせて頂いたのでそちらを読んで下さい。

それにしても当サイトのような端サイト(稚サイト)に意見を述べて下さるなどとても嬉しい。それと同時に自分の無知無学 (未熟な部分) を曝け出しているという事実を改めて感じ、恥ずかしくもある。人に何かを説明するという事は、ある一定以上の理解を求められるということであり、当サイトは自分の技術向上を主目的としている部分もなきにしもあらずなので、このようにご指摘を頂けるとそれが私自身のレベルアップに直接繋がるのでありがたい。これからもたくさんのご指摘を頂けるようなサイトを目指したいと思う。

XHTML1.1のMIMEタイプ で調べた物の続きという事になるかもしれないが、後の為にメディアタイプについての説明が書かれているページを載せておこうと思う。今は勉強する時間がないが、何とかしなければならない問題だ。私の頭では理解が出来ないかもしれないと心配である。

ん?これで良いのかな? Content-Typeを振り分けるいくつかの方法


Webサイト製作の指南方法

初心者への教え方がわからない という記事を見つけた。読んでいていちいちその通りだと納得する。Web Kanzakiの30分間HTML入門 が素晴らしいと言うのにも同意だし、最初に出会いたかったとも思うが、創り始めの頃の事を思い出すと、やはりこれではとっつき難いのではないかと思う。今読めばこれほどわかり易い物はないのではないかと思うが。

さて、本題はそこではなく、Momomoさん が仰られている『2つのHTMLファイルと1つのCSSファイルをまっさきにZIPでダウンロードさせて、テキストエディタでソースを見ながら覚えていくタイプだ。』という部分だ。なるほどと思う。まだ私の脳にインプットされたばかりなのでその形は見えてこない。二つのHTMLファイルには何を書いておくのか。リンクの説明 (主に相対パス) をどのようにするのか。画像の使用法の説明はどうするのか(必要ないと言われればそれまでだが)。問題は山積だ。だがアイディアとしてはとても面白いと思う。もしかしたら使わせてもらうかもしれない。なんとか具体化できないだろうか。これならば間違いなく同じ環境を創る事が出来る。でもやはり説明の仕方が難しい。そこでこんな面白い記事 SSのMovableType もあった。『skype等のP2P電話を利用したリアルタイム通信添削』だそうだ。面白いが、やはり有料でないとやっていられないだろう。仕事ならば引き受けても良い。しかし私にはそのようなスキルは無いのがネックだ。

# ところで今度、うちのサイトを SSさん に批評してもらおうかと思っているが、何とも怖いと言うか恥ずかしいと言うか。ちなみにリンクもさせて頂いた。

Momomoさん も仰られているが、他になにかこれはというアイディアはないだろうか。方向性が違うと全てを創り直すことになる。私も現在 Webサイト作成支援を目的としたサイト を構築中だが、何をどこまでどのように教えるのかに苦悩している。どこまでを教えるべきなのか、どれくらいの表現で理解してもらえるのか、どのような見栄えならば受け入れやすいのか、とにかくわからない事だらけだ。初学の頃の自分を呼び起こしてみるが、無駄な知識が邪魔をする。そして結局は既存乱立のサイトと変わらぬ物が出来てしまっているようだ。

まあ個人的に、と言うよりも長くWebサイトの運営を続けている人ならば思うことだろうが、決して諸学の頃の遠回りは無駄ではない。しかし無駄もある。言っていることは矛盾しているが、出来るだけスマートに学べる環境が出来れば良いと思う。もちろん入口は広くなければならない。きっとここが問題なのだろう。『難しそう』と少しでも思わせてしまったら失格なのだ。やる気のある人間ばかりではない。何となくやってみようかなと思った人が、やって行くに連れてはまって行き、凄いものを創り上げる可能性もあるからだ。その機会を奪うのは得策ではない。だから入口は広くしたいが、あまりにもおそまつ過ぎるのも結局は先に進むのに時間が掛かったり、学び直す気力が必要になる。楽しさを与え、興味を引き出しつつ、正確な知識を始めから植えつける教え方。なかなか見つからないと思うが、これからも模索していかなければならないと思う。

SSさんも 仰っているが、オーサリングツールや“トンデモ”なマークアップで、納得する表現が出来てしまった場合に、その満足から抜け出し、HTMLを学ぼうとするのには大きな壁がある。その障害を取り払うのは難しい。幸い私は IE と NN の表現の違いに愕然とし、それが勉強のきっかけになったが、HTMLを真面目に学ぼうという気にさせるのは並大抵の事ではない。閲覧環境には様々な物があり、特に障害者の事を考えたり、アクセシビリティについて知る機会があれば何とかなるとは思うが、それでも確実ではない。90%を超えるIEのシェアがそうさせているのかもしれない。

話が戻るが、いきなりCSSを扱わせて理解させる方法がちょっと難しそうだ。でもこれから私がやろうとしているのはまさにそれなのかもしれない。頑張らなければ。


申し訳ありません。

昨日メールフォームから連絡を頂いた。出来ればメールでの返信をと仰られていたが、やはりメールは苦手なのでこちらにした。きっと読んで頂けるであろうと信じている。

メールの内容は http://www.star-wish.com/user/hajimeteweb/pc2/phf2.html の画像が表示されないので改善して欲しいとの事でした。画像が出ていないのはパスのミスか、アップロードのし忘れだろうと思い早急に対処しようと思ったが、どういう訳か画像がどこにも見当たらなかった。ソースを見る限り f1.gif などと数字を打って順に画像に名前を付けている所を見ると、後から画像を挿入しようとして忘れたのではなく、何らかの理由で画像を紛失したと見るのが正しいようだ。おそらくパソコンを新調した時に不手際が起こったのだろう。こういったページは他にも多数存在すると思うが、残念ながら今は凍結中のコンテンツなので手を加える気はない。しかしながら公開している以上はそれなりの責任は必要だと考える。かといって急に閉鎖する訳にもいかない。ジレンマだ。

結局は何が言いたいのかと言えば申し訳ないけれども改善は不可能だという事だ。理由は作成時の環境が今はこちらに整っていないのと、当時の思考が思い出せない事だ。それに時間もない。ただ、それではあまりにも申し訳がないので参考になりそうなサイト様をいくつか挙げておくので勘弁して貰いたい。

それからもう一つ COSMO GATE の内容について砕いてもっとわかり易く出来ないかとの事ですが、個別のCGIの解説について説明する気はありませんので悪しからず。加えて言うのならば、KENTWEB様 にはしっかりとしたサポートコーナーもあります。そしてこれが最大の理由ですが COSMO GATE はこれ以上ないくらいに易しく噛み砕いて説明してあり、これ以上の説明が必要だとは私は思いません (もしくは説明できる技量も時間もありません)。それから根本的な事を申し上げますと、いったいどの部分がわからないのでしょうか。それを示さずにいるという事は全部を解説して欲しいという事なのでしょうか。それは無理です。特にこの部分が…と言うのであれば、解説しているサイトを紹介する事、もしくは簡単な説明を差し上げる事は可能かもしれません。ただ、全体的にと仰るのならば勉強不足ですとしか言い様がありません。


XHTML1.1のMIMEタイプ

現在は新サイトの構築に励んでいる。概要が出来てきたのでサーバーにアップロードしてみて問題がないか確認する。と言っても使用するのはAnother HTML-lintだけだ。ez-HTMLを使用しているので、ローカルでのチェックも頻繁に行う事ができ、問題はないだろうと思っていたが、以下の三つのエラーが出た。

このエラーはサイト改装の時にも出ていたがその時は考えている時間が無かったので <meta http-equiv="content-type" content="application/xhtml+xml; charset=Shift_JIS" /> という記述を省く事で解決していた。これは元々 XHTML1.1では <meta http-equiv> を記述すべきではありませんとチェックされていた物だったので特に抵抗はなかった。しかしながら漠然とした疑問が残ったので調べてみる事にした。


Copyright © 2005 rara All Rights Reserved.