カテゴリー別アーカイブ: サイトB

Mac OSXのローカル環境(MAMP)上に作成するサイト

サイトB:CSS3のbackground-size:cover;で背景画像をウィンドウにフィットさせる

最早サイトA、B、Cというカテゴリ分けはあまり意味を為していないけれど、当初のカテゴリ分け基準では、滞在感のあるサイトのノウハウをこのカテゴリに蓄積するはずだったので一応。

ブラウザのウィンドウをぴったりと埋める画像を背景として使い、その上にコンテンツを乗せるというやり方は、サイトに滞在感をもたせようと思ったときの常套手段だ。ただ、CSSのヴァージョンがまだ2.xであったころには、これをやるのがなかなか難しく、時にはJavaScriptやjQueryプラグインの力なども借りなければならなかった。

一方、CSS3に対応しているモダンなブラウザ環境を対象としたサイト作りであれば、こういったデザインも容易に実現できる。滞在感が表現できる上、ウィンドウに追随して大きさが変化するという特性からレスポンシブデザインとも相性が良い。

ウィンドウの大きさに追随する背景の指定

CSS3では、背景画像や色を指定するbackground系プロパティのひとつとして、background-sizeというプロパティが追加された。無指定の場合の初期値はautoだが、スペース区切りで値を2つ指定することで、それぞれ画像の幅と高さを決められる。たとえば指定要素に対して幅は50%、高さは200px固定というようにしたい場合の指定は以下のようになる。

background-size : 50% 200px;

また、特別な指定値としてcontainとcoverがある。containは背景画像として利用する画像をアスペクト比を保ったまま拡大・縮小し、クリッピングすることなく要素内に表示できる最大サイズにしてくれる。したがって、指定先の要素とアスペクト比が異なる場合には必ず画像の全体が表示された上で余白が生じる。

background-size : contain;

一方、coverは元画像のアスペクト比を保ちつつ拡大・縮小し、指定先要素の中に余白を生じることなく画像を表示する。したがって、アスペクト比が異なるのならば、画像は確実に一部分がクリッピングされる

background-size : cover;

したがって、ウィンドウサイズに合わせた背景画像を表示するためには、このbackground-size:cover;とmin-height:100%;をhtml要素に指定するという手順となる。

html{
min-height : 100%;
background-size : cover;
}

min-heightの指定が必要であるのは、内包するコンテンツのサイズによってhtml要素の縦の長さが変わるためだ。

ただ、background-size:cover;を指定する場合の背景画像は、抽象的画像や大写しの風景など見切れても不都合の無いものを選ぼう。人の顔などの場合には、見切れてしまうと大変格好悪い。
また、background-sizeプロパティはbackgroundショートハンド(省略指定)の対象となるので、background-sizeを指定した後あらためてbackgroundで指定しないようにする注意が必要である。


Webフォントにそろそろ手を出すの事

WordPressでは、ヴァージョン3.6とTwenty Thirteenのペアから本格的採用が始まったWebフォント(WebFonts)。WordPressでの新技術採用は見切り発車というか地固めというか、1年くらいして各社ブラウザがWordPressに合わせてくるのを待って、次第に導入するのが都合が良い。HTML5然り、レスポンシブデザイン然り。それで、Twenty Thirteenの登場からは1年というタイミング、そろそろ趣味のサイト以外でも採用して良い頃合いなのではないかなと思ったので、なるべく安牌的な導入方法を調べてみることにした。

Webフォントの概要

Webフォントというのは、従来のようにユーザのローカル環境にあるフォントを引っ張ってきてWEBコンテンツを表示させるのではなく、WEB制作者側があらかじめ指定したフォントをユーザ側にダウンロードさせて、ある程度制作者側が想定した通りの表示内容で表示させる仕組み。この仕組みがあれば、font-family : sans-serif;のように指定した結果がWindows環境とMac環境で全く異なって表示されてしまうという、デザイン上の困り事も軽減される。

採用のデメリットは、Webページが重くなること。何しろフォントセットを丸々ダウンロードさせるわけで、特にモバイル環境のユーザに対してはストレスを与える結果になる事が多い。また、サイトの表示が重くなると、SEO的観点からもあまりよろしくない。この辺りは膨大な文字数が必要な日本語フォントでは、とりわけ顕著である問題。

Webフォントの仕組みはCSS3の正式規格で、これ自体をサポートしていないブラウザは切り捨てる方向で話を進める。こういう話のときに取り残されるブラウザは大抵IEなのだが、実は元々WebフォントはIEの拡張規格から来ているので、案外IE4などでも使えたりする。ただ、IE8以前の場合はフォントの規格自体がEOTという独自路線のみ対応なので、場合によっては切り捨ててしまった方が面倒でないだろう。

Webフォントとして使用できる形式

そう、どのタイプのフォントがWebフォントとして使用できるかは、ブラウザ側の対応状況に依存する。TrueTypeフォントやOpenTypeフォントはPC環境に付属する一般的なフォントだが、Firefox、Chrome、Safariともにかなり以前のヴァージョンから対応している。また、Mobile SafariではiOSの4.2から対応している。日本発売のiOSデバイスならば、上限までアップデートすれば全デバイスで表示が可能ということだ。
TrueTypeやOpenTypeを表示できないのが、IE。先程も書いた通り、一貫してEOT形式を採用してきた。そのため、表示したいフォントがTrueTypeやOpenTypeであった場合、EOTに変換した上で、同じフォントをIE用に指定して読み込ませるという方針が考えられる。
TrueTypeフォントのEOTへの変換は、WEBサービスやローカルアプリケーションなどが検索すれば出てくる。代表的なところとしてはココ

.ttf/.otfとEOTの組み合わせ指定の場合

TrueTypeならびにOpenTypeフォントと、EOTに変換後のフォントが揃ったと仮定する。IE以外で未変換のフォント、IEでEOTフォントを表示させるように指定するには、スタイルシートに以下のように書く。

/*mplus-1c-thin.ttfというファイルを元にする場合*/
/*EOTはmplus-1c-thin.eotというファイル名で作成したと仮定*/
 
/*今回使用するフォントにtestfontという名称をふる*/
@font-face{
	font-family: "testfont";
	src: url("mplus-1c-thin.eot");
}
@font-face{
	font-family: "testfont";
	src: url("mplus-1c-thin.ttf") format("truetype");
}
 
/*h1見出しのフォントを全てtestfontにする場合*/
h1{
font-family: "testfont";
}

あらかじめ@font-faceでfont-familyの名前空間を確保しておき、srcでパスを指定する。その後、実際に使う箇所ではfont-familyで呼び出す。何も難しいところは無い。ただ、IE用のEOT指定の場合はformatをつけてはいけないというところは注意だ。
このように.ttf/.otfと.eotの組み合わせ指定をすれば、4以上のIEを含めた大抵のブラウザで表示が出来る。カバー率は高いだろう。

WOFFを使用する場合

ただ、TrueTypeやOpenTypeをそのまま指定する方法には、閲覧者がフォントをそのままダウンロードできてしまうという短所がある。WEB制作者的にそれで困るところはあまりないが、フォントメーカーなどはそれでは困るので、Webフォント用の新規格としてWOFFというのが策定された。最新ブラウザなどは一様に対応しているし、これから主流になっていくであろうフォーマットだ。
WOFFのメリットとして、著作権情報が盛り込めたり、データを圧縮できたりというものがある。特に後者の恩恵は大きい。

/*mplus-1c-thin.woffというファイルを元にする場合*/
 
/*今回使用するフォントにtestfontという名称をふる*/
@font-face{
	font-family: "testfont";
	src: url("mplus-1c-thin.woff") format("woff");
}
 
/*h1見出しのフォントを全てtestfontにする場合*/
h1{
font-family: "testfont";
}

WOFFに対応するブラウザは、IEは9以降、Chrome、Firefoxは割と前のヴァージョンからに対応しているので意識しないで良いだろう。Safariでは、Mac版、iOS版とも対応は5.1からと遅めで、これはOSX10.6 Snow LeopardとiOS5以降となる。iOS5以降ということで、日本発売のiOSデバイスではiPhone3Gが非対応になるし、iPhone3GSでもiOS5にアップグレードしないユーザは切り捨てだ。WOFFだけ指定するのは、MacやiOSにおいてもIE8以前バッサリ切り捨てと同じくらいの決断となる。
WOFFへの対応ヴァージョンの確認はこちらのページが便利だろう。

Webフォントのサブセット化

何とかWebフォントの容量を軽くしたいという場合には、サイト上で使う文字だけを組み込んだサブセットを作成する方法がある。武蔵システムのサブセットフォントメーカーというソフトを落として使うのが早い。サブセット化&WOFF変換をすれば、日本語フォントでも常識的なサイズに落ちてくれる。

とは言え、日本語Webフォント導入の動機は薄いかも

各社ブラウザの対応によって、確かにWebフォント導入への障壁は低くなっている。ただ、そのわりにWebフォントを使ったサイトというのがイマイチ流行っていないのは、やはり日本語の文字数が膨大で、ページ本文のフォントとして使用するのがあまりにナンセンスだからだろう。例に挙げたmplus-1p-thin.ttfというフォントで1.6MB。フォントによっては20MBくらいになるものもあるので、気に入ったデザインのフォントをよく考えないで採用すると泣きを見る。あくまでせいぜいアルファベット程度の文字セットをダウンロードさせようという目論見から来ている規格なのだろう。


サイトB:MAMPの導入と複数サイト運用のための設定

MacOSX上のローカル環境につくる予定のサイトBですが、ローカル環境の構築にはMAMPというアプリケーションを使用します。このMAMPというアプリケーションはOSに影響を与えることなくApache、MySQL、PHPのテスト環境を提供するソフトウェアで、windows用のソフトウェアとして有名なXAMPPと同等のものです。現在ではXAMPPがOSX、Linuxにも対応していますが、MAMPの場合はMacOS用のリリースを以前から行っていたため、OSXの仮想環境ソフトウェアとしてユーザーが多くリファレンスも充実しています。

早速導入をしてみましょう。MAMPのトップページの左側のDownload nowボタンをクリックすると、最新版のダウンロードが始まります。右側で紹介されているMAMP PROは60ドル程度の有料版で、こちらは複数サイトの運営が標準機能として搭載されています。その他にも機能差が存在するのですが、無料版の方もいわゆる機能限定デモのような圧倒的に痒いところに手が届かないという体ではないので安心して使えます。
以前のMAMPは解凍したアプリケーションを手動でアプリケーションフォルダに移す必要がありましたが、現在の最新ヴァージョンではインストーラ形式になっています。便利な反面、販促の為か標準インストールで勝手にMAMP PROまでインストールする仕様になっています。不要ならばカスタムインストールのオプションでMAMP PROのチェックボックスを外しましょう。
インストールが終わったら、アプリケーションフォルダに作成されたMAMPのフォルダを開きMAMPアプリケーションを立ち上げます。

(この部分の画像は000webhostに接収されました)

この画面が出たら正常に起動しています。左下のウインドウにはサーバのステータスが表示されます。また、環境設定のボタンから各種設定をすることができます。

さて、デフォルトの状態でのドキュメントルートは、MAMPフォルダの一階層下のhtdocsフォルダになっています。このままですとサイトを一つしかテストできないので、サイトを複数作成・テストする場合にはhtdocsフォルダの下にフォルダを作成して、そこをドキュメントルートとみなしファイル構成を行います。

(この部分の画像は000webhostに接収されました)

ここではフォルダeをドキュメントルートとしたサイトと、フォルダlをドキュメントルートとしたサイトの2サイトの運用を想定します。フォルダ構成が済んだら、先程の環境設定ボタンで現れるフローティングウィンドウのApacheタブを選択して下さい。そこに記載されたパスがサイトのドキュメントルートになるので、それぞれチェックするサイトのルートフォルダを指定し、その都度MAMPを再起動して下さい。指定したフォルダに、MAMP起動時に現れるページの、アドレス後半部の/MAMP/?language=Japaneseを削ったアドレスでアクセスできるようになります。

(この部分の画像は000webhostに接収されました)

設定を変更後再起動という面倒臭さはあるものの、一応これで複数サイトの運営が可能になります。公開しないローカル環境であることの強みを生かして、実験的なサイトをいくつも作ってしまいましょう。


サイトBコンセプト

サイトBのコンセプトは、訪問者に滞在感を与えるページにするというものです。

ポータルサイトのトップページなどがそうなのですが、リクエストを送って出てきたページが情報量の多い、リンクだらけのページだった場合に、閲覧する人間は何か脅迫感めいたものを感じて急かされるようにリンクをクリックしてしまうという傾向があるように思います。ページビューを稼ぎたいポータルサイトではそれがサイト作りの正解なのでしょうが、一方でコンテンツひとつひとつの質で勝負したいサイトでは、こうした脅迫感を与えない情報量の少ないページ作りをすることによって、コンテンツを何度も読み返してもらえる可能性を得られるだろうと、個人的に思っています。

ひとまずそうした予想が当たっているのかどうかは、このサイトBの制作で検証してみたいと思います。もしそのような傾向が実際にあるのならば、情報量の少ない、滞在感のあるページにすることがサイトの運営上別の利益ももたらし得ます。まず、コンテンツの更新回数がどうしても少なくなってしまう個人サイトの欠点を、繰り返し読んでもらうということで補える。次に、例えば商品の販売をしたい場合に、購入の直前で他のサイトに目移りされてしまう可能性を抑えられる、などです(実例として、Apple Online Storeの見積もり画面なんかを挙げたいと思います)。

話が膨らみすぎてしまったのですが、このサイトBの制作ではそこら辺の技を積極的に開発していきたいと思います。

(やはり、コンセプト的に公開も考えなければならないだろうか…)


はじめまして。何をやろうとしているの?

ファーストエントリーなので、このサイトの意義について書いてみたいと思います。

現在管理人AkisiはWEB制作技能の向上の為に、異なった環境、ツールを用いた複数のサイトを運用しようと考えています。その過程でどのような問題に遭遇し、どう解決したかを書き残しておけば、個人的な行動ログになるので、あとで作業の巻き戻しの必要が出た場合に重宝する。のみならず、それぞれの環境に似た環境をこれから構築しようとする人、あるいは既に構築している人のトラブル解決にも、少しだけ役立つ情報を提供できるのではないかと思っているのです。

そんなわけで現在のところ計画しているサイトは以下の3種類です。

サイトA
レンタルサーバを借りて、データベースにMySQL、テンプレートエンジンにSmartyを使用する。写真をデータベースに登録し、ジャンル、撮影日などで絞って検索できる機能を実現する。
サイトB
Mac OSX用のMAMPというソフトウェアで、ローカル環境上に構築する。データベースはSQLiteを用い、Smartyを使ったサイト作りをする。最終的に公開サイトとしてアップするまでを試したいけれども、先々コンテンツを更新して活きたサイトにするかは微妙。
サイトC(このサイト)
CMSであるWordPressの実験用として。できあいのテーマ、プラグインを追加して拡張していくだろうけど、多少のカスタマイズは考えてみたい。
各サイトの成長記録を追う場合、サイドのナビゲーション(現在はJavaScript製のコンパクトなものが居座っているはず)からカテゴリとしてサイト名を選択すればよいという塩梅です。

それでは、自分のWEB制作日記がどこかで誰かの役に立つことを期待しながら更新をしていきたいと思います。