タグ別アーカイブ: CSS

box-sizing : border-box　最近はpaddingとborderを幅・高さから引かない

コメントをどうぞ

凄く今更な話だけれども、数年くらいWEB制作から離れていると見落としがちな常識の転換。

旧世代CSS：要素の幅・高さはあらかじめ余白と境界を引いた値にしよう

CSSで要素に対して幅や高さを指定する際に、要素の周囲を囲むborderの太さならびに境界内部の余白paddingの値は、あらかじめ目星をつけておかないといけない。というのも、widthやheightといったプロパティで指定された値に、borderとpaddingそれぞれの幅を加えたものが要素が親要素内で占有する大きさとなるからである。

旧padding,border計算方法

旧padding,border計算方法

上図の例で言うと、要素に対してwidthとheightで指定された幅200px高さ150pxという値は、余白paddingや境界線borderの幅がいくら変わっても保証される。その代わり要素自体の大きさは指定幅に加算されていくので、たとえば親要素の幅が400pxのところにこの.classが指定されたボックスをfloatを使って2つ並べたい場合、paddingとborderの幅を取ってしまうと2つ目のボックスが下に落ちてしまう。
そこで、ボックス落ちを防ぐためにはwidthとheightの値を、あらかじめpaddingとborderにあてがう幅分引いて指定しないといけない。上の例で言うならば、widthを150（200-20*2-5*2）px、heightを100（150-20*2-5*2）pxで指定しないと、ボックス落ちである。そして後々ページの見映えを変えたくて、paddingやborderの幅を変更したくなったらもう大変。変更の都度widthとheightの値を動かさないといけない。うわー面倒臭い。

かつてこんな感じに解決してました

この面倒臭さを解決する方法。一つは、クライアントにレビューの際にIE6を使わせる。IE6の場合paddingとborderはwidth,heightから引くという超モダンな解釈をしてくれる。そこで上の例で言えばwidthを200px、heightを150pxと指定しておいて、後からpaddingとborderを変更してもボックス落ちしない。クライアントには、IE6こそが先進的ブラウザで、その他99.9%のブラウザはゴミですと言い聞かせよう。
と、まあ冗談はさておき。問題を分割して、padding部分だけでも解決する場合。要素内にもう一つの要素を放り込んで、余白部分は内側の要素のmarginで指定するようにする。inner_**とかそういった命名の要素があれば、この問題を解決しようと苦心している可能性が高い。
そしてもう一つスマートな解決法として、CSSの変数を使用するというものがあった。CSS標準のものであれば、CSS Variables。

 
:root{
--tekitou-padding-value: 20; /* 変数名は--から始まる適当な名前 */
--tekitou-border-value: 5;
}
 
.class{
width: calc(200 - var(--tekitou-padding-value) * 2 - var(--tekitou-border-value) * 2);
height: calc(150 - var(--tekitou-padding-value) * 2 - var(--tekitou-border-value) * 2);
padding: var(--tekitou-padding-value);
border: var(--tekitou-border-value);
/* var(変数)で変数を定義された値に展開 */
/* calc(数式)で数式を展開 */
}

このようにすれば、後でpaddingとborderの値を変更しても、自動的にwidthとheightの値も連動する。
ただし、このCSS Variablesやcalc関数については対応ブラウザの問題がある。ベンダープレフィックスをつけないと動かない可能性は勿論のこと、CSS Variablesの方はEdgeの登場によりお役御免となったIEでサポートされてないのが痛い。ということで、変数を使う場合は主にSassやLESSのようなCSSプリプロセッサに頼ることになるだろう（コード例は省略）。CSSプリプロセッサを使う理由の全てがこの変数と数式計算という人も、きっと多いはず。

新世代CSS：box-sizing : border-boxで余白と境界をサイズに含めない

この余白と境界の値をあらかじめ考慮しないとボックス落ちしてしまうという仕様は、レスポンシブデザインにおいてはたいへん都合が悪かった。というのも、画面幅に応じて要素の幅も伸縮するレスポンシブデザインでは、幅の指定にパーセントを使用するからである。ボックス落ちしない余白と境界の値をあらかじめ知るのは不可能なので、デザインに遊びを持たせるか、フラットデザインのようにして影響を最小限にするなどしなければならなかった。勿論、CSSプリプロセッサで多少解決出来る部分もあるけれど、それはそれ。
かつてIE6的な余白と境界の解釈を標準化という錦の御旗のもと根絶してしまってから、実はそっちの方が都合が良かったと気付いたのだ。そこでCSS3ではbox-sizingというプロパティが出来て、余白と境界をサイズに含めない計算方法も選べるようになった。

box-sizing : border-boxを指定した場合の計算方法

box-sizing : border-boxを指定した場合の計算方法

指定方法は、box-sizingプロパティの値をborder-boxと指定するだけ（無指定の値はcontent-boxで、これは今までの計算方法だ）。これにより要素のwidthとheightで指定されたサイズが保証されて、paddingとborderはその値から減算することになる。後付けで値の変更を行っても、影響は最小限だ。

box-sizing : border-boxをどこで宣言するか

ちなみにこのbox-sizingプロパティにはinheritという値もあり、これが指定されていると上位要素で宣言された値を継承する。ページ全体にわたってbox-sizingを有効にする場合、一番簡単なのは、全称セレクタを使って全要素に明示的に指定することだけれども、

 
/* 全称セレクタだけでは疑似要素に適用されないので、beforeとafterもついでに指定 */
/* 疑似要素使わないなら指定の必要なし */
 
*, *:before, *:after{
box-sizing: border-box;
}

ただこれだとcontent-box指定を前提として書かれたCSSを拝借してくる場合などに、対象となる全要素をいちいちcontent-box指定に直すのが面倒臭い。そこで、inherit指定を上手く活用した方がbetter。

 
/* 最上位要素のhtmlに対してborder-boxを指定 */
 
html{
box-sizing: border-box;
}
 
/* 全ての要素のbox-sizingがinheritとなるように指定 */
 
*, *:before, *:after{
box-sizing: inherit;
}

このようにすれば、拝借してきたCSSがcontent-box指定の場合でも、その上位要素に対してcontent-boxを指定し直すだけでよい。

box-sizing : border-box入りのリセット／ノーマライズCSS

全称セレクタで全要素に対して指定をするならば、どうせならリセット／ノーマライズCSSで同時にこれをやってくれるものの使用も選択肢として考えたい。確認した範囲で以下のリセット／ノーマライズCSSが最新版で対応している（リンク先はGitHub）。

  • sanitize.css（全要素にinherit＆html要素に対してborder-box指定）
  • minireset.css（全要素にinherit＆html要素に対してborder-box指定）
  • ress（全要素にinherit＆html要素に対してborder-box指定）
  • Marx（全要素にinherit＆:root疑似要素に対してborder-box指定）

で、上の画像にも付記してあることだけれども、みんな大好きなTwitter Bootstrapではv2.3.2までにはborder-box指定がなく、2013年8月にリリースされたv3.0.0以降からborder-box指定が入る（全要素にinherit＆html要素に対してborder-box指定）。

世代間の壁の存在に留意が必要

そんなわけで、昨今WEB制作の道に入門してくる人達は完全にborder-boxの常識でコーディングを行うだろうし、それ以前の常識で書かれたコードやWEB上のサンプルコードなどはcontent-boxの場合が多い。ここで混乱が起こる可能性がありそう（特にWordPressテーマとプラグインの関係で顕著）。
一応頭でinherit指定を行っておけば世代の異なるCSSコードの付け足しの際、直上の親要素に明示的指定を打って流用することが出来るけれども、付け足しが多数になってくるとあとあと訳が分からなくなってしまう。
そこで、出来ることならば新世代の常識の方に寄せる方向で旧世代コードも手直ししておいた方が良いのではないかと思う。Bootstrap等が軒並み新世代であることや、ブラウザのベンダープリフィックスなしbox-sizing対応がほぼ完了したことも鑑みて（box-sizingの各ブラウザ実装状況）。あと、購入する参考書の発行年などにも今後注意が必要だね。

このエントリーをはてなブックマークに追加

小ネタ：WEBサイトの配色決めに役立つカラーピッカー

コメントをどうぞ

見映えの良いサイトを作成したいけれど、デザインセンスが要求されるので敷居が高い。これから時間をかけて、配色について勉強していかなくてはならないのだろうか…ええと、配色について教えてくれる場所は…美大？

さいわい、WEBデザインの仕事をしている人間が全員美大を出ているわけではない。また、デザインセンスについても、ほとんど皆無なれど仕事をしている人もいる。彼らがどのように仕事をしているのかというと、WEB上にある便利なツールを使って、悩んだりする時間を短縮しているようである。

指定したサイトでの使用色を採取するツール

デザインを決める最も短絡的な方法は、誰か他人のサイトをまねること。気に入ったサイトを片っ端からパクればよい。
ただ、パクるといっても、ページ構造からスタイルから全部のソースをそのままコピーするわけではなく、使用色の組み合わせをいただくのだ。一度は自分の気に入った配色だから、同じ色をベースにサイトを構築していくというのは、地味にモチベーションアップにも繋がる。

そしてその際に便利なのが、WEBサイトのURLを入れると配色を自動的に採取、カラーコードを表示してくれるツール。ネット上に星の数ほどもあるだろうけれど、表示の分かり易さなどから以下のサイトをおススメしたい。

Colours（http://webcolourdata.com）

Coloursスクリーンショット

Coloursスクリーンショット

使用色だけでなく、サイト内で使用されている色の割合の情報も重要になる。このサイトの場合リボン状に使用割合を視覚化してくれるので、端の方のあまり使われていない色は文字やborderに使われている色だな、などと判断がつく。とっても便利。

選択色と組み合わせ相性の良い色を選んでくれるツール

どうしても使いたい色（ベースカラー）が決まっていて、その色との組み合わせで使って違和感の無い色の一覧を出してほしい。そんなケースもあるはず。そういった場合にオススメなのが、以下のサイト。

Paletton（http://paletton.com）

Palettonスクリーンショット

Palettonスクリーンショット

取っ付きにくそうだけれども、いじっているうちに使い方に気付くはず。左上の小さいダイアルのようなボタンで、1〜4色までベースカラー数を選ぶ。あとはカラーピッカーをクリックしてベース色を選択ないし、”Base RGB”という欄にカラーコードを入れる。右のプレビューからマウスオーバーでカラーコードを取得可能。右下の”EXAMPLES…”タブを選ぶと、実際サイトに適用した例を表示してくれる。
このサイトが他のサイトより優れていると感じるのは、”Vision simulation”というメニューから閲覧者が色盲・色弱の場合の見え方を表示してくれるというところ。そこまで痒いところに手が届くカラーピッカーは、そうそう無い。

色の組み合わせツール（日本語）

Palettonは完璧なように思えるけれど、WEBデザイナーが使うには一点だけ不足部分がある。それは、色の組み合わせのデモがアルファベットを使ったサイトであるということ。アルファベットはそこまで複雑な形状をしておらず可読性も高いため、サイトの攻めの配色の一部として使うことも出来る。
Palettonで配色を決めて、いざ日本語サイトに適用しようとすると、吃驚するほど合わないというケースがある。それだけ漢字は複雑で、デザインの一部に組み込むのが難しいのだ。そこで、日本語に対応したカラーピッカーとして以下のサイトも紹介しよう。

ウェブ配色ツール Ver2.0（http://www.color-fortuna.com/color_scheme_genelator2/）

ウェブ配色ツールVer2.0スクリーンショット

ウェブ配色ツールVer2.0スクリーンショット

Palettonに同じく、1色を決めると適当な組み合わせ色を選んでくれる。ただ注意書きに書いてあるように、ツール自体の配色の得手不得手はあるようだから、提示された色をそのままに近いデザインで使って、これなら万人が納得するはず！と思考停止してしまうのは良い結果に繋がらない。そもそもあまりベースカラーに向いていない色などもあるわけで、ツールは過信しすぎず、迷ったら無難な道に靡いていくべきだろうね。

このエントリーをはてなブックマークに追加

サイト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くらいになるものもあるので、気に入ったデザインのフォントをよく考えないで採用すると泣きを見る。あくまでせいぜいアルファベット程度の文字セットをダウンロードさせようという目論見から来ている規格なのだろう。

このエントリーをはてなブックマークに追加

BootstrapとGoogle Maps API同時使用時の表示崩れを修正する

コメントをどうぞ

Twitter社の提供するCSSフレームワーク、Bootstrap。これを使うと、面倒臭いWEBのGUIデザインを、要素へのクラス指定一発で解決することが出来る。以前紹介を行ったとおりCDNでの利用も可能なので、WEBサイトを作成する前にとりあえず（jQueryと一緒に）呪文のように読み込んでおくと、ページ制作中痒いところにも咄嗟に手が届き易い。

もう一つ、企業サイトであれば”会社概要”ページのアクセスマップなどで使われるであろう、Google Maps API。こちらも頻繁に利用されるものに違いないのだが、BootstrapとGoogle Maps APIを同時に利用して地図の表示を行うと、以下のスクリーンショットのように表示崩れが発生する。

Google Maps表示不具合

Google Maps表示不具合

まず由々しきこととして、左端の縮尺スライダーが表示されない。このような状態だと、スクリーンショットを貼っておいた方がまだ良かったのではないかという疑問も湧くだろう。また、右上の地図と衛星写真の切り替えメニューで、カーソルをホバーした時のドロップダウンメニューが少し見苦しい。具体的には、チェックボックスとラベルの間に改行が入ってしまうのである。

Google Maps表示不具合の原因

これらの不具合の原因は、Bootstrap側で読み込むCSSで、img属性やlabel属性など比較的影響の大きいところでスタイル指定を行っているからである。具体的には、

img{
max-width:100%;
width:auto\9;
height:auto;
vertical-align:middle;
border:0;
-ms-interpolation-mode:bicubic;
}
 
label{
display:block;
margin-bottom:5px;
}

といったような記載のある箇所である。問題となっているのは、img属性のmax-width:100%指定と、label属性のdisplay:inline-block指定である。

特に対応せずにGoogle Mapsが表示できているケース

img属性の指定によってマップのスライダーが表示されない不具合については、Bootstrap側としても対応策をとっている（どのヴァージョンからかは、生憎把握していないが）。

#map_canvas img,.google-maps img{
max-width:none;
}

このようなCSSを追加して、Google Mapsのデフォルトで包括要素として使われるdivのid=”map_canvas”以下のimg属性に特別にスタイル指定している。そのため、素直にマップを表示する領域のidを#map_canvasにしている場合、不具合は起こらないはずだ。問題は、別のid名やクラス名をしている場合。Bootstrap側の付け焼き刃的対策では問題が解決しない。

解決策

解決策は、Bootstrapの付け焼き刃解決策と同じように、包括要素以下のimg属性・label属性にスタイルを指定してやれば良い。たとえば包括要素がid=”googlemapdiv”だった場合、スタイルシートに以下のように記述する。

#googlemapdiv img{
max-width : none;
}
 
#googlemapdiv label{ 
width : auto;
display : inline; 
}

また、マップのコントロール部分の上位要素であるclass=”gm-style”以下の各属性に指定する形でも良いだろう。

.gm-style img{
max-width : none;
}
 
.gm-style label{ 
width : auto;
display : inline; 
}

これで正常に表示されるはず。

GoogleMaps正常表示

GoogleMaps正常表示

BootstrapやGoogle Mapsなどの複数WEBサービスを組み合わせて利用する場合、どこかは絶対ぶつかるものだと最初から割り切っていた方が良いのだろう。ちなみに今回の問題はEXIFviewerに機能を追加する過程で確認したもの。そろそろ新ヴァージョンを公開できるはず。

このエントリーをはてなブックマークに追加

Conceptual：OnlyCSViewに、ただ何となくBootstrapを適用

1件のフィードバック

ユーザが指定したCSVファイルを表形式でAjax表示するだけのWEBサービス、OnlyCSView。作成して以来、大して弄ることも無く放置していたのだが、Twitter Bootstrapの雰囲気を掴むために、インターフェースだけ変更しようと思い、手入れをした。

そもよ、Twitter Bootstrapって何？

Twitter BootstrapというのはCSSフレームワークの一つで、かのTwitterが提供する無償フレームワーク。これを使えば、簡単にカラムレイアウトが実現できたり、レスポンシブデザインに対応できたり、Twitterのサービスで使っているようなGUI部品が要素へのクラス指定だけで実現できたり…とそこそこ楽しめる。CSSコーダなど、WEBデザイン・レイアウト方面の方々に知名度はある技術だと思うけど、生粋のWEBプログラマでは、Bootstrapの存在を知らないという場合も多い。

どういう部品が使えるのか、どういう機能が付けられるかについては、こちらのデモページが大変参考になるだろう。
ちなみに、OnlyCSViewでは「表示」ボタンと、テーブルの視認性を上げる奇数行ハイライトで明示的に使っている。それぞれ、class=”btn btn-primary”という指定と、class=”table table-striped”という指定をしているだけ。なお、文字コード選択のセレクトメニューの見た目も変化しているが、こちらはclass指定をせず勝手に変更されたもの。こういったおせっかいもあるので、それが気にならない人間がBootstrapに手を出せばよい。

BootstrapのCDNはよ

こういった仕事で使うにはちょっと…というおもちゃは、すぐに影響なく外せるよう、CDNで利用したい。Bootstrapにも勿論CDNがあるので、魔法の呪文を書いておこう。

<!--Bootstrapの本体（ヴァージョンは適宜）-->
<link href="//netdna.bootstrapcdn.com/twitter-bootstrap/2.3.2/css/bootstrap-combined.min.css" rel="stylesheet">
<script src="//netdna.bootstrapcdn.com/twitter-bootstrap/2.3.2/js/bootstrap.min.js"></script>

jQueryが必須になる。ちなみに、レスポンシブ対応させるには、もう一つ二つファイルを読み込まないといけない。そちらはCDNが無いので、ダウンロードしてくるしかないけど。
ちなみに、このCDNを提供しているNetDNAという会社は、本来はCDNを商売にしている会社なので、急にサービスの停止などされる可能性はある。自己責任で。

OnlyCSViewの機能増えてないけど？

本当は見た目の更新だけでなく、ファイルのドラッグ＆ドロップに対応させようとして、仕組みは書いていたのだけど。ただ、一般的なファイルダイアログを使ったアップロードと、ドラッグ＆ドロップによるアップロードで同じGUIを使うというところに無理があったため、どうしようかと思っている。賑やかしで置いているだけで、利用者もいないだろうし別の開発を優先する予定。

このエントリーをはてなブックマークに追加

overflow:hiddenとページ内リンク同時使用による不具合

1件のフィードバック

以前、floatを使った要素の回り込みを実現する際のおまじないとして、overflow:hiddenを紹介しました。clearfixテクニックを使う方法と比べると手軽で、表示上の不具合に対し応急処置となるケースが多いものですから、私のような横着者はとりあえずどの要素にもoverflow:hiddenを適用しておくよう習慣づいてしまっています。

ただ、この手軽な方法にも落とし穴があります。overflow:hiddenを使った要素内で、URLの末尾に#idという形でパラメータを付与し辿るページ内リンクが行われた場合、当の要素が他の要素の下に潜り込んでしまうといった表示不具合が起こる場合があるのです。この不具合は、overflow:hiddenとページ内リンクの組み合わせで必ず発生する不具合というわけでもないため、長くWEB制作に携わりながら、一度もこうした現象に見舞われたことがない、したがって急にそうした不具合に当たって足下を掬われるといったケースがあり得るかもしれません。

対処法はとりあえず、ページ内リンクをあきらめるかoverflow:hiddenをあきらめるかといった、敗北主義的なものしかありません。幸いfloatの回り込み指定の実現方法はoverflow:hiddenだけではありませんし、ページ内リンクについてはJavaScriptを使ったページ内スクロールに変更して衝突を避けることもできます。ページ内スクロールの実現には、こちらのサイトのsmoothScroll.jsなどが便利です。

この不具合はほとんどのブラウザで共通して発生してくれる優れた不具合なのが幸いですね。仕様的なものなので、あるバージョンから突然修正が入り対処を行った部分の労力が無駄になることもありません。

このエントリーをはてなブックマークに追加