shortcut Webデザインとかガジェットについてつらつらと書き連ねています

192月/080

behaiviorなるものを使ってみた。

仕事が一向に減る気配がありません…。今年度はずっとこの調子のような気もします…。

とはいっても世間はものすごい勢いで変わっている訳で、先日、ようやくIE7がWindows updateと合わせて配布されました。

まだまだピュアなweb標準的なコードのみでマークアップできる訳ではありませんが、 IE6やそれ以下のバージョンのIEが減ると、対応がずいぶん楽になります。
ちょうどその頃、大藤幹さんの書かれた「CSSベストプラクティス」を読んで、IE6以下でもa要素以外の要素にhover疑似クラスを付加できる「whatever:hover」というIEのビヘイビアを知りましたので、ざっくりサンプルを書いてみました。

a要素以外にhover疑似クラス使うのなんて、プルダウンメニューくらいしかなさそうな気もしますが、それでも相当HTMLの見通しが良くなるので、なかなか気持ちがいいものです。

Filed under: HTML No Comments
62月/080

prototype.jsで角丸を実装してみる

ようやくjsのライブラリに手を出してみます。
もう一昨年の話になりますが、CSS Nite LP2でロクナナの中村さんのお話を聞いて「よし、これからはデザイナーもスクリプトくらい書けなきゃいかん!」と思って一年以上月日は流れ、ようやく覚束ないながらもなんとなく書けるようになってきました。

WebクリエイティブのためのDOM Scripting (Web Designing Books)
中村享介
毎日コミュニケーションズ
売り上げランキング: 25592

これは薄くて読みやすく、理解しやすいので、入門本としては非常によかったです。

まあ、今回はDOMを使えればなんでもよかった訳ですが、普段あまり使う事のないprototypeを使ってみました。
サンプルはこんな感じ。

角丸ボックス<br />

コードはこんな感じ。

HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>addcorner</title>
<meta http-equiv="content-script-type" content="text/javascript" />
<meta http-equiv="content-style-type" content="text/css" />
<script type="text/javascript" src="scripts/prototype-1.6.0.2.js"></script>
<script type="text/javascript" src="scripts/base.js"></script>
<link rel="stylesheet" href="styles/base.css" type="text/css" media="all" />
</head>
<body>
<div id="wrapper">
<div id="main">
<div class="box box01">hogehoge</div>
<!-- /.box -->
</div>
<!-- /#main -->
<div id="sub">
<div class="box box02">hogehoge</div>
<!-- /.box -->
</div>
<!-- /#sub -->
</div>
<!-- /#wrapper -->
</body>
</html>

CSS

@charset "UTF-8";
/* ------------------------------------------------------------
common
------------------------------------------------------------ */
*
{
margin:0;
padding:0;
}
html, body
{
height:100%;
}
body
{
padding:20px;
}
/* ------------------------------------------------------------
column
------------------------------------------------------------ */
div#wrapper
{
width:950px;
margin:0 auto;
border:solid 1px #ccc;
}
div#main
{
width:530px;
float:left;
}
div#sub
{
width:400px;
float:right;
}
/* ------------------------------------------------------------
box
------------------------------------------------------------ */
div.box
{
padding:10px;
min-height:60px;
position:relative;
}
* html div.box
{
height:40px;
}
/* image */
div.box01{background:#faa url(../images/t01.png) repeat-x 0 0;}
div.box01 div.corner{background:url(../images/corner01.png);}
div.box01 div.border_lr{background:url(../images/lr01.png);}
div.box01 div.border_b{background:url(../images/b01.png) repeat-x 0 bottom;}
div.box02{background:#aacdff url(../images/t02.png) repeat-x 0 0;}
div.box02 div.corner{background:url(../images/corner02.png);}
div.box02 div.border_lr{background:url(../images/lr02.png);}
div.box02 div.border_b{background:url(../images/b02.png) repeat-x 0 bottom;}
/* corner */
div.tl,
div.tr,
div.bl,
div.br
{
width:10px;
height:10px;
position:absolute;
font-size:0;
}
div.tl, div.tr
{
height:30px;
}
/* corner-position */
div.tl{top:0;left:0;}
div.tr{top:0;right:0;}
div.bl{bottom:0;left:0;}
div.br{bottom:0;right:0;}
/* corner-image-position */
div.box div.tl{background-position:0 0;}
div.box div.tr{background-position:-10px 0;}
div.box div.bl{background-position:0 -30px;}
div.box div.br{background-position:-10px -30px;}
/* border */
div.l,
div.r
{
height:100%;
width:10px;
position:absolute;
}
div.border_b
{
width:100%;
height:10px;
position:absolute;
}
/* border-position */
div.l{top:0;left:0;}
div.r{top:0;right:0;}
div.b{bottom:0;left:0;}
* html div.b{left:10px;}
/* border-image */
div.box div.l{background-position:0 0;}
div.box div.r{background-position:-10px 0;}
/* ------------------------------------------------------------
clearfix
------------------------------------------------------------ */
div#wrapper:after
{
zoom:1;
}
div#wrapper:after
{
content:'.';
display:block;
height:0;
visibility:hidden;
clear:both;
}

JavaScript

/* ------------------------------------------------------------
add box-corner
last modified 2008.02.05
------------------------------------------------------------ */
function addCorner(){
var cornerBox = document.getElementsByClassName('box');
var cornerClassName01 = [
'r border_lr',
'l border_lr',
'b border_b',
'br corner',
'bl corner',
'tr corner',
'tl corner'
];
cornerBox.each(function(obj){
for(i=0; i<=6; i++){
new Insertion.Bottom(obj, '<div class="'+cornerClassName01[i]+'"></div>');
}
});
}
window.onload = addCorner;

ビジュアルをある程度リッチに作り込む予定だったので、ボックスの4隅(上下左右)と、左辺、右辺、下辺の3つの辺(上辺はボックスに背景画像を指定して表現)の、合わせて7つのdiv要素をスクリプトで動的に生成し、角丸にしたいボックスの周辺に配置しています。

あとは生成したそれぞれのdiv要素のサイズを決めて、背景画像を入れてあげればはいできあがり...。という具合です。

こうやって動的に要素を生成して角丸を表現する場合、メリットとして、ボックスのサイズの制限がなく、トリッキーな背景画像の作成やマークアップを行わなくてすむという事があげられます。

一方、デメリットとしては、表示のパフォーマンスやスクリプトオフ時の表示の差異などが挙げられます。

スタティックな角丸とスクリプトで生成する角丸のどちらかが絶対よいという事はなく、当然ケースバイケースなので、どちらの実装方法も知っておいて、実際にマークアップを行う際に「これはスタティックかな」「これはスクリプト使った方がいいだろ」くらいの判断ができると、仕事のに余裕というか、厚みがぐっと増すような...、気がします。

Filed under: HTML No Comments
199月/070

「デザインする」ことをデザインする

なんだか禅問答のようなお題です。

最近そんなことばかり考えていて、仕事に身が入らなかったりしています。
目の前に山のように仕事があるのは分かっているのですが、どうしても気になる今日この頃です。

ひと昔前までは、お客さんが世間的にいう「クライアント」で、かつ、小さい仕事が多かったので、プレゼンからモノづくりまでほぼ自分の思うがままに仕事していました。
雑誌やニュースサイトなどで大規模サイト向けのクオリティの高い仕事をするための開発手法や評価手法を見ては「いつかこんなことができればなぁ…」と思うこともたまにありましたが、一人でほぼ完全に仕事をコントロールできていたので、気楽な仕事でもありました。

しかし、ここ最近はお客さんが本当のエンドユーザーを指すような仕事が多くなり、リサーチや評価手法はあるけれど、実際に対面することのない人たちに向けてコンテンツやサービスをデザインするようになりました。

さらに、ひとつの仕事にさまざまな職種の人が関わってくるようになってきたため、その利害関係者に対してデザインの仕事内容やデザインの力を説明する機会が増えてきました。

その時に、見えない誰かに向かってデザインをするときに、どこまで責任感と創造性を保てるかという事と、共通言語を持たない人たちに、いかに分かりやすく説明するか、という事をいまさらながら考えたりしています。

特に最近は後者の「説明」とか「アピール」の部分で苦労していたりするので、なんとかうまい方法がないかなぁ、と悶々とする毎日であります。

よく「デザイナーはいいもの作ればいいんだよ」のように、過程をあまり考えずにゴリ押ししてしまえ、と言わんばかりの意見もあったりしますが、根拠なしに「いい」といえるくらいレンジの広いモノができるのを漠然と待つよりは、仕事の周りの環境とかフレームワークとかを変えることで余計な労力を減らせないかと思っています。

Filed under: webdesign No Comments
88月/070

「普通」の定義

先日誕生日を迎えました。31になりました。
気づけばオッサンの仲間入りです。早いなぁ…。
全然期待していませんでしたが、今年は友人と元上司からプレゼントをもらいました。まさにサプライズです。ありがとう。

さて本題。

云々経由で下のエントリーを読んで、自分でも無意識に使っているかもしれないと思い、反省しています。

このエントリーでは「普通」という確実そうに見えて実は限界や制限の線引きを早い段階で引いてしまうだけの言葉を使う事に警鐘を鳴らしています。責任の取り方をよく知っている人や逆に全く知らない人がよく使いそうな言葉ですね。
それももちろん問題ですが、僕は「普通」という言葉がユーザビリティでいうところの「ゴムのユーザー」とも通じるところにも気をつける必要があると感じました。

「普通○○だよ」の「普通」は、概ね発言者の経験則に基づく基準値なので、それが一般常識や定石の範疇なのか、それとも全くブレているかはその発言だけでは判断しづらい事が多々あります。
そこを確認せずに進んでしまうと、後になって言った言わないの水掛け論になってしまうこともあり、それは非常に気まずかったりします。

なので、「普通」は誰にとっての「普通」なのかを意識して、かつきちんとそれが伝わるように話す必要があると思いました。

Filed under: webdesign No Comments
52月/070

webデザイナーのアイデンティティとは?

なんか、以前にも似たようなエントリーを書きましたね。

今回はRIAではなく、HTML側の話。
WEB+DB PRESSの最新号に、こんな特集が組まれていました。

実例に学ぶ [速習]Webデザインパターン

ナビゲーションのパターン化や簡単にテンプレートを作成できるツールを紹介し、デザイナーがいなくてもwebサービスが構築できます、といった感じの内容です。
デザイナー以外の人にもビジュアル以外のデザインを意識してもらえるいい機会だと思うのですが、一方で「コーダーの仕事がなくなるのでは?」と、危機感を募らせている人もいました。

SEやPGに「Webデザインパターン」が広まれば、簡単なwebサービスやサイトの仕事の作業は減る一方、より高度なHTMLによる情報設計や、それを修飾するCSSを書いたりビジュアルを作り込む作業に集中できていいと思うんでけどねぇ。
さらには、今は専らSEの作業になっているwebサイトやサービス全体の情報設計に関わったりできるようになるのではないか? と勝手に想像したりもしています。

確かに、紙とwebの媒体の違いを意識せずにデザインをしているような無頓着な人や、旧態依然としたHTMLコーディングのスタイルを貫いている人達に取っては厳しくなるかもしれませんが、未だにwebデザイナーが「Dreamweaverが操作できればなれる」という敷居の低い職業に見られるのもどうかと思うので、こういう互いの職分を浸食するような動きは良いと思います。

かくいう僕も、ようやくインタフェースの体系的な勉強を始めたところなんですけどね…。

Filed under: webdesign No Comments
1412月/060

expressionでボックスの最小サイズ指定を擬似的に実現する方法

IE7ではmin-widthやmax-widthが実装されているのでもう必要ありませんが、旧ブラウザ対応としてメモ。

WinIE5/5.5/6ではmin-widthやmax-widthが有効にならないため、リキッドレイアウトや内容物の増減で変化するレイアウトを作成すると色々困ることが起きます。
それを解決するためにexpressionというCSS内でJavascriptを実行する方法を使用して、擬似的にIEでmin-widthなどを実現する方法です。

元ネタはこちら。

min-width

div#contentBox {
min-height:100px;
height:expression(
document.all('contentBox').clientWidth < 101?
'100px':'auto');
}

min-height

div#contentBox {
min-height:100px;
height:expression(
document.all('contentBox').scrollHeight < 101?
'100px':'auto');
}

max-width

div#contentBox {
max-height:100px;
height:expression(
document.all('contentBox').clientWidth > 99?
'100px':'auto');
}

max-height

div#contentBox {
max-height:100px;
height:expression(
document.all('contentBox').scrollHeight > 99?
'100px':'auto');
}

値の指定にpxではなくemを使うとすれば、こんな感じっぽいです。

div#contentBox {
min-width:10em;
width:expression(
document.all('contentBox').clientWidth < 10 * parseInt(document.body.currentStyle.fontSize)?
"10em":"auto" );
}

CSSの中にJavaScriptを書くというのは気持ち悪くてグロいし、何よりこんな面倒な事させる前に先にまともにCSSの仕様どおりに実装してほしかったところですが、CSS側だけで対応させることができるので、最終手段としては使えると思います。

Filed under: CSS No Comments
1112月/062

CSS Nite LP2に行って来た。

12/8に北青山 TEPIAで行われたCSS Nite LP2に行って来ました。CSS Niteは回を重ねるごとに風格のあるセミナーになってきましたね。

今回は豪華に12セッションを3会場で同時に進めるかない豪華なセミナーでした。
さらに今回は、セミナーと同時に発行された書籍がセミナーと連動するという面白い試みでした。書籍の企画に合わせたのかCSSよりはDreamWeaver寄りのセッションが多かったです。
実際にセミナーの中で「ここは書籍の~ページを見てください」とかはなされる場面があり、また、聞けなかったセッションをあとで書籍で確認できるので、いい連動の方法だと思います。

推測になりますが、以前に、CSS Niteの拡張版イベントの「Web標準の日」で、後日セミナー内容をmp3で配信して、費用を払って参加した方からクレームがついた事をうけて、書籍をセミナーにバンドルしたのかもしれません。
僕個人としては、この手の情報は速報性と会場で聞くということが大事だと思うので、後の音声や動画資料の配布には異議はないのですが。

と。前置きはさておき、今回は下の4セッションを受けてきました。

コンポーネントベースのWebサイト設計と構築

小久保浩大郎氏

「抽象化」という言葉を使い、意識的に文書構造と外観を分離する事と、それをどうやって作業フローに組み込んでいくかという、現場よりの実践的な話でした。
多分、開発で言うところのクラス設計の話になるかな、と思います。

CSSの抽象化」のような技術的な話かな?とも思いましたが、もっと現場よりの話でした。

大規模サイトの作業を前提としていたので、設計の工程と明文化を重視し、サイトで使われる見出しやリスト、あるいはナビゲーションといったページ要素を「コンポーネント」というパーツにまとめてHTMLコード込みのドキュメントに落とし込み、後工程でのぶれをできるだけ減らしていこうアプローチです。
サイト構築のフローの中で、HTMLのコーディング部分は「原稿さえあればすぐにできる」という印象がつきまとってしまったり、そもそもHTMLコーディングが何であるか理解されにくい場合が多いのですが、それを「マークアップ」という言葉を用いて、うまくフローに納めているのは、bAの経験がなせる技ですね。
非常に参考になりました。

DreamWeaver使いが知っておきたいセキュリティ

太田良典氏

「脆弱性」は「ぜいじゃくせい」と読みます。ここが大事、とのことです。
僕も「きじゃくせい」はよくきいていましたが、「もうじゃくせい」とか「ぼうじゃくせい」は初めて聞きました。日本語って難しいですね。

個人でのIPA届け出数日本一の太田さんによる、セキュリティの話です。
WebSigでの話題と多少重複する内容もありましたが、Dreamweaverでデータベース込みの動的なページを簡単に作れるのは知らなかったので参考になりました。
デザイナー向けの話なのでそれほど突っ込んだ話ではなく、フォースフル・ブラウジングとSQLインジェクションの説明を簡単に説明されていました。

これならいける? DreamWeaverで始めるCSSレイアウト

こもりまさあき氏

DreamWeaverを使ったクラス・ID付けと、CSSでのレイアウトを実演するという、どちらかというと「これからCSSを導入しよう」というくらいの初心者向けのセッションでした。
DreamWeaverでの作業を見られるのはよかったのですが、もう少し突っ込んだ話をしてくれてもよかった…ような気もします。

デジタルアセットマネジメント

境祐司氏

今までテーブルレイアウトを使ってページを作成していた製作会社が、フルCSSレイアウトの作成方法にスタイルを切り替えるためのコンサルテーションを、実際の資料を用いて解説していました。
スニペットを活用して作業の効率化を図る、というのが落としどころですが、そこに至るまでのドキュメントの作り方と、教育方法という点が、とても参考になりました。

一枚絵をFireworksでスライスしてテーブルレイアウトのページを作るという方法に慣れている人からすれば、CSSを用いたコーディングは謎が多くてまどろこっしくてたまらないと感じているように思います。
そこを、現状分析と図解資料を多用して説得・あるいは納得させ、10日間で一通りコーチングするという、ハタから見ると結構強行軍なスケジュールと内容の実例でした。

実際のところ、古くから続いているサイトやサービスがビジネスとしてうまく回っている場合、CSSレイアウトに切り替える事に必要性を感じないという人は今でも結構多いので(本当に必要ない場合もありますが)、その人たちを説得するための方法として覚えておこうと思います。

あと、今回のセミナーの企画を行っていたスイッチの鷹野氏の娘さんの映像(パーティって何?という映像)がセッションの合間合間に挿入されるのが印象的でした。
そしてセッションの合間に、その鷹野氏が、「社内で『こんなに頑張ってまでイベントをする必要はない』と突き上げを食らっている」と、冗談混じりにぼやいていましたが、CSSのようなあまり日の目を見る機会のない技術にフォーカスして定期的にイベントの場所があるのはとても有り難いので、続いて欲しいと切に願います。

Filed under: CSS 2 Comments
512月/060

もっと場当たり的にCSSを直す方法

前のエントリーを見て思ったのですが、なんとなく筋道立てて書こうとしているところが言い訳臭くてダメですね。
そういう訳で、本当に場当たり的に、後のメンテナンスのことなど考えずに、今ここにある問題をしのぐためにCSSを直す方法を書いてみました。

問題箇所をすべて洗い出す。

校正部門とかチェッカーのバイト君とか後輩を泣かせて、各種ブラウザと画面解像度、その他必要な条件での表示確認を行います。
自分で確認すると、今まで見慣れているページなのでどうしても見落とす箇所がありますし、なにより大変なので、できるだけ理由を付けて人にやらせましょう。
問題箇所はバグ対応システムか表に記入してもらい、あとで修正漏れや見落としがないようにします。
人間自分が楽をするのが一番です。

cssファイルをすべて印刷する

cssをページの要素やブラウザごとにモジュール化している場合、非常に見通しが悪くなっていますので、まずは全部印刷し、机に広げて眺めてみます。
そして、適当にあたりを付けて修正しなければいけない箇所をピックします。
インデントのずれやコメントの記述漏れなどに目が行ってしまいますが、今回は場当たり的な対処療法なので見なかったことにします。

とりあえず枠で囲う

下記のユニバーサルセレクタを追加

*
{
border:solid 1px #f00;
}

この状態で、意図せずに枠からはみ出ているブロックがある、枠が表示されない、ブロックの形が意図しているものと違うなどの問題があった場合、そこのクラスやIDのスタイル指定に問題があります。
本当は別の場所に問題がある場合も多々ありますが、ここでは「木を見て森を見ず」方法で進めます。

とりあえず絶対配置にしてみる

floatで悩む問題はこれですべて解決します。他にいろいろ問題が出てくる場合も多々ありますが気にしません。

とりあえずブロック要素を増やしてみる

子要素が親要素を突き抜けたり、marginやpaddingが意図したとおりに表示されない場合は、divタグなどでネストを増やして様子を見ます。それでもだめならもう一重。
度が過ぎるといわゆるdiv厨という奴になりますが気にしません。

あきらめてテーブルレイアウトにする

(表層的には)クライアントの望むものは、構造化された文章のwebページではなく、PCのブラウザでレイアウトが崩れないwebページです。
と、自分に言い聞かせてテーブルレイアウトを取り入れましょう。
フルCSSスタイルの過渡期の頃に言われていた「ハイブリッド型」というスタイルです。

再確認

すべて修正が終わったら、また校正部門かチェッカーのバイト君か後輩を泣かせて確認を行います。
校正の人って、仕事が細かくて地味で神経を使うのに色々文句を言われて大変ですよね...。

Filed under: CSS No Comments
412月/060

場当たり的にCSSを直す方法

気がつけばもう12月です。皆さんいかがお過ごしでしょうか。
会社の近くではイルミネーションとかイベントとかいろいろあるようですが、自分はインドア派なので関係ありません。か、関係ないって言ったら関係ないんだからね!

さて本題。

ここ最近スタイルシートをガリガリ書いたり修正したりとんでもない不具合に頭を抱えたりしていますが、多少作業の流れのようなものが見えてきたので、忘れないうちに書いておきます。
「明日の9時までにデータを納品したければ行けないけどIEとfirefoxで表示が違うのが直らない」とか「昨日旧にIE5に対応してほしいとクライアントに言われた」という場合には役に立つかもしれません。
時間がある場合は文書設計とCSSの構成設計を見直してください。それが一番まっとうで確実です。

1.原因の切り分け

  • CSS表記ミス。そもそもバリデーションが通っていない
  • HTMLの記述ミス。link要素の書き間違い、クラス・ID名の間違い
  • ブラウザの不具合・バグ

css validatorやfirefoxのextensionであるfirebugやIEのDOM inspector2ch CSS バグスレッドなどを使用して不具合の場所を特定します。新しい不具合であれば、mixiに質問を投稿するという手もあります。
概ねIE5.x系のバグだったりしますが、まれにIDとクラスを間違えて書いていたとか、importでCSS内に読み込むCSSが読まれていなかったりする場合もありますので、まずはCSSをいろいろ触る前に原因を特定しましょう。
それでも見つからない場合は、スタイルの指定をひとつひとつコメントアウトなどで外したり、枠線を追加してみて原因を絞り込んでいきましょう。

2.修正の方針を立てる

  • (動的ページの場合)ページの生成時にブラウザ判定を行ってlink要素の出し分けを行ってブラウザ分岐する
  • javascriptを使ってブラウザ分岐する
  • 条件分岐コメントを使ってブラウザ分岐する
  • hackを使ってブラウザ分岐する
  • html文書を修正した上で上記どれかでブラウザ分岐する
  • あきらめてクライアントへの言い訳を考える

分岐の必要のないようなCSSをかけるのがベストで、その次にhackで対応するのが一番楽ですが、hackは文法的に正しくない場合が多いので、閲覧条件に依存しない分岐方法がベストです。というと、動的生成か条件分岐コメント位しかありませんね。
最後の「あきらめてクライアントへの言い訳を考える」は、案件の最初の段階でターゲットユーザーとブラウザを明確に決めた上でHTMLの構造設計を行っていればまず出てこない言葉ですが、そのあたりがぼんやりしたまま作業に入ってしまうと納期直前や検収時に突然「このページNN4.7で見れないんだけど」とか言われてしまうので注意です。

3.修正

直してブラウザで見て、の繰り返しです。
firefoxのWeb Developerを使うとリアルタイムで修正結果が表示に反映されるので便利です。

また、importを階層化したりhackを使うと、Dreamweaverのプレビューは全く当てにならなくなるので、最初からブラウザで確認した方が後でがっかりしなくてすみます。

4.検証

全部修正したら、改めて対象ブラウザですべて確認します。

Filed under: CSS No Comments
119月/062

21世紀美術館のトップページのHTMLを書き換えてみた

更新が遅れていたのは、こっちの作業が進んでいなかったせいです。
それにしてもIEは癖があるなぁ...。

なんかいろいろな所から怒られそうな気がしますが、21世紀美術館の日本トップページをデザイン・レイアウトはそのままにXHTML+CSSで書き換えてみました。

Filed under: HTML Continue reading