html-css – イケサイウェブ制作lab

tableのいろいろUI紹介

ども、忠犬（ではなく中堅と呼ばれたい万年見習い）hashikouです。
本日は海外SBMで話題になってた、tableのUIパターンについての記事をご紹介します。
といいつつ超テケトーなサマリのみなので、「内容が違うぜ！」とあまり怒らないでくださいね。
不安な方はレッツ原文！
原文：Ultimate guide to table UI patterns
※図もぜんぶここからだよ！
—
tableってユーザ―インターフェイスの大事な要素だよね！でもわりと見過ごされがちなんだ。
データを読みやすくしたり解析しやすくりしたりするためのものなのに、退屈でひどいものが多い。
そういうくだらないtableを少しでも減らせればと思って、tableのパターンをいくつか紹介するよ。
1.交互に行のスタイルを変える
奇数行と偶数行で色変えてみやすくするアレ。背景色や背景色を使って、複数の列や行を認識しやすくする。
ヘッダーなどは濃い色を使うなどしてそれと分かるようにする必要がある。

2.全体を選択できる行
行全体をクリックできるようにすると、ちまちまクリックしなくていいから楽だよね的な感じ。
jQueryでかんたん導入できるよ！

3.sectionを使う（内容ごとにグループ分けする）
たくさんの行をグルーピングして項目（=section）分けしたげると見やすくって親切ですな。

4.並び替える
データが膨大で目的のものが見つけにくい場合、しかも明確なキーワードを知らない場合（検索できない）、
似たような情報群で並び替えてあげる。
ヘッダー列がクリッカブルであることが必要。

5.しぼりこむ
こちらもデータが莫大な場合、チェックボックスやラジオボタン、ドロップダウンリストなどで
情報をフィルタにかけ絞り込むことができる。

6.ページ送りをつける
7.途切れないスクロール
8.スクロールしても固定して表示されるヘッダー
9.ヘッダーなし
10.伸び縮みする列
11.列の上で色んな操作ができる
12.複数の列を操作できる
などなど。
（hashikouが力尽きました・・全てを読むには↓のリンクを押してください）
原文：Ultimate guide to table UI patterns
—
tableって色々見せ方あるんですなー。
最初webアプリケーション寄りじゃね？と思ったのですが、よくよく考えると静的HTMLでもtableは普通に使うし、
JS使えば動的に表現できるし、知っといても損はないと思います。
わりとざっくり作りがちですが、こんな細かいところにもちょっとした配慮や見せ方を仕掛けてあげると、
格段に操作性や視認性がアップするのがtableのかわいいところかもしれません。

設計時にふと思うこと

ウエイトトレーニングしたので、体がだるいTAKA-Gです。
今回は少しだけディレクター目線な話をしたいと思います。

ワイヤーフレーム・画面設計・ストラクチャ呼び方は様々あると思いますが、
コンテンツ設計した後には、具体的にページに掲載する情報をレイアウトしていきます。

いつも、これで本当に意図しているページになっているのか？
など疑問を持ちながら作業をしているわけですが、よく自分が失敗するのが

「解説不足、導線不足」です。

どうしても、この業界にいるため暗黙のルールを作り上げてしまっていたり
企画から携わっていると、情報が足りているように錯覚することがしばしば。
そうなると、どうしても使いにくかったり情報不足で訴求できなかったりします。

本当は設計の時にユーザー目線で見られるといいのでしょうが、
自分は苦手なので、チームメンバーにどうよ？と確認してみます。
思いもよらないところを突っ込まれたりして、なるほど！と思ったりできるのです。

設計に正解はないと思いますが、色々な経験して
ユーザー目線、企業目線、様々な目線から物事を見れるようになりたい今日この頃です。

HTML5適当なまとめ

突然ですがこんにちは。副管理人のhashikouです。
前職で管理人ziraiさんと師弟関係だったこともあり、縁あってブログを書かせてもらうことになりました。
ホットでヤングなレンタルサーバー技術ネタを書いていこうと思うので、どうぞよろしくお願いします。
初回なのでHTML5について適当にまとめてみます。
1.HTML5までの経緯
今まで策定されてきたHTML4やXHTML2は、文書構造としてのマークアップ言語であり、主にtext/htmlとしての使い方が大半でした。
しかし通信回線の発達や技術の進歩などにより、googleをはじめとしたWebアプリケーションの需要が高まり、現在のHTML4や諸々を拡張しHTML5の策定をすることとなりました。
2.何が変わるの？
ざっくりざっくりご紹介します。Webアプリケーション系は省略。
・<img>と同じように<video>とか<music>とか使える。プラグイン不要（ただしコーデックでモメてる）
・canvas機能が策定、HTMLでキャンバスを指定してそこにJSでグラフィックの描画など色々できるように
・ローカルにキャッシュもためておけるのでローカルでWebアプリが使える→iPhoneのGmailですでに使っている
・<section>、<article>要素が増え、文書構造をより明確に組み立てられる
・その他<div id=”header,footer”>→<header><footer>というように、よく使うタグとid、classのセットが独立した要素に
・DOCTYPEなどの記述が短くなる
・input typeの種類が増える、カレンダーやスライダなどUIも増加
3.今後どうなるの？
HTML5のすべての実装が完了して正式勧告されるのが2022年などと言われています。。が、ブラウザ側では仕様がある程度決まっているものに対して実装が進んでいるため、一部使ってみることはできます。ブラウザ実装表は以下からご確認ください（1年前の記事ですがわかりやすいです）。
HTML5/CSS3は最新Webブラウザでどれだけ実装が進んでいるか？－ Publickey
ブラウザの実装がまちまちのため、制作の現場ではまだ実感が湧いてこないHTML5ですが、IE9もHTML5に対応するという噂もありますし（しないとそろそろ暴動起きますよね…）、googleやAppleが立て続けにHTML5を採用しアナウンスをしているところを見ると、やはり今後大きく流れが変わってくるような気がします。
近い将来、ブラウザ上で何でもできてしまう時代が来るかもしれません。見た目がどうのこうのというより、動的にアプリを組み込むこともふまえ、総合的な「WEBでできること」をお客さんに提案していく必要がでてきそうです。
もっとわかりやすく知りたい：
HTML5, きちんと。
サンプルが見たい：
HTML5サンプル集 – 株式会社あゆた

テーブルレイアウトを使用しないといっている人へ

久々の更新ですが、いきなり引用。。

　何を伝えたかったかというと，サイトのユーザーさんはソースを見てお問い合わせをしたり，何かを購入したりする訳では無いということです。ですので，十分にCSSを理解していない段階で，より正しいHTMLを書こうとしてデザインを犠牲にしてしまうことと，高度なデザインをちょっとだけtable要素をレイアウト目的に使用しつつ再現することを天秤にかけたときに，どっちがクライアントさんのためになるのかということを考えなければいけないですよね，ということです。

それこそ，事件は会議室ではなく現場で起こるように，マークアップの現場では時として「え！このデザインはさすがに…」とか「この納期ではさすがに…」とか言うことが起こってきます（この辺は，ワークフローの改善などによっても回避することは可能ですが）。例えば，納期中にマークアップを仕上げるということがマストで，そんなにHTMLの厳格さにはこだわっていないという案件があった場合（あくまで，喩えですが）に，CSSがあんまり得意ではないので table要素をレイアウト目的に使用することでしか間に合わないということであれば，そうすることが正義というか，選択肢がそれしか無いということになりますね。

引用元：第2回　CSSレイアウトとか，Web標準とか：ITpro

いやー非常に同感ですね～

自分もHTMLの構造やCSSレイアウトを意識し始めたころは、理想を追いかけてマークアップをしていましたが、いざ案件（仕事）をやってみると、そううまくは行かないことに気づかされました。。大規模案件になればなるほど、多人数制作になればなるほど困難。

要因としては、

1つのプロジェクトでコーディングレベルまで落ちてくる間に、スケジュールが押していることが多く、時間的余裕がない。
CSSレイアウトなど、ハイレベルコーディングをすることにより、他のメンバー（スキルレベルが違う）の作業時間が大幅に遅れる。
運用者が制作者ではなく、クライアントサイド。

などなど、いろいろな要因があると思います。

上記にもあるワークフローの改善もあると思いますが、入れ替わりの激しいこの業界ではなかなか厳しいのが現状だし、必ずしもワークフロー通りに案件が進むとは限りませんし、思いません。

結果。
理想を追いすぎて、クライアントや社内に迷惑をかけるよりも、妥協（現実を見る）をし、スムースにプロジェクトを進めるほうがいいな。
と、悟りました。

でも、マークアップエンジニアとしては自分の理想のマークアップをしたい。。。

今の会社に来て一回もないけど。。。。。。。。

ikesaiだけでも、しょぼいソースを書き直して理想のマークアップにしなければ。

全称セレクタにzoomを使うとバグる

以前から導入してみようと思っていたhaslayoutのzoom機能ですが、導入したらいろいろ不具合が起きてきました。
まずはaタグです。ある環境下でaタグのリンク領域がおかしなことになりました。まぁこれはその部分にzoom: normal;といれてやれば回避できたんですが、olのバグに関してはどうにもこうにも回避できませんでした。症状はというと、ナンバリングリストの番号がすべて1になってしまうというなんとも不可思議な現象です。そこでいろいろ調べてみると自分と同じ症状の人がちらほらいたようで、回避方法も書いてありました。
これで解決！と思いきやこの方法でやると、リスト内の行が2行以上になると最後の行に番号がきてしまう。なので初心に帰りliにzoom: normal;を入れてみるとすべての症状が回避できました。灯台下暗しです。。。

以下がサンプルになります。もちろんIEで見てね

»zoomによるolのバグサンプル1

»zoomによるolのバグサンプル2

»zoomによるolのバグサンプル3

なんとか回避はできたけど、このほかにもいろいろバグがありそうなので、今後は全称セレクタは避ける方向で。。

»TRANS – * { magin: 0;}だけでは物足りない！zoom: 1;を使おうよ！

first-letterのバグ

注釈（※）などをインデントするにあたり、いろいろトラブったのでメモ。

■margin-leftを使うとIE6でボックスサイズが広がるのでプラス側はpaddingにする。

p.indentA01 {
	margin-left: 0.7em;
}
p.indentA01:first-letter {
	margin-left: -0.7em;
}

を下に変更

p.indentA01 {
	padding-left: 0.7em;
}
p.indentA01:first-letter {
	margin-left: -0.7em;
}

■似たクラスを続けて記述すると、スタイルが効かなくなるのでバラして記述する。

div.captionA01 p.indentA01,
div.captionA02 p.indentA01,
div.captionA01 p.indentA01r,
div.captionA02 p.indentA01r {
	padding-left: 0.7em;
}

を下に変更

div.captionA01 p.indentA01,
div.captionA02 p.indentA01 {
	padding-left: 0.7em;
}
div.captionA01 p.indentA01r,
div.captionA02 p.indentA01r {
	padding-left: 0.7em;
}

IE6が本当に使えない。
あとUTF-8で※が文字化けするのってどうやって回避するんだろ。

font-famliyでメイリオを指定するとテキストフィールドがバグる

最近わかったのが、font-famliyでメイリオを指定するとIEやFirefoxのテキストフィールドが想像以上に伸びる現象を発見しました。
これはどうもある条件が重なるとなるようです。
inputのテキストフィールドにsize指定をし、font-famliyにメイリオを指定し、尚且つメイリオフォントがPCにインストールされているとなります。
なのでVistaでは確実におかしくなり、XPでもインストールしている人がいればなります。
で、回避するにはsize指定をHTML側にしない事。なんだけど、指定しないわけにはいけない場合も必ずあるので、font-famliyにメイリオは指定しないほうが良いって事ですな。
先取りしてメイリオを指定している人は確認したほうがいいですねー

»メイリオがインストールされていて、font-famliyにメイリオを指定した場合

CSS セレクタについての参考サイト

WWW WATCHに掲載されているCSS セレクタのリファレンスはかなり参考になります。
CSS3で定義されているものが多く今はあまり使うことはありませんが、覚えておいて損はないはず！

WWW WATCHさんに感謝。

»CSS セレクタに関するおさらい | WWW WATCH

»CSS セレクタに関するおさらい 2 | WWW WATCH

»CSS セレクタに関するおさらい 3 | WWW WATCH

単位に悩みたくない人に

CSS初心者でよく悩みがちなのは単位の算出です。下記のサイトではポイント、ピクセル、パーセント、em を変換した際の近似値をチャートが掲載されています。 12pxの近似値パーセントが分からない、または忘れたなんて場合にとても便利です。

»Approximate Conversion from Points to Pixels

ボックスモデルの仕様で悩む

ネットを徘徊してたら久々にbox-sizingを見かけたのでIE7で試してみた。
ちなみにIEとモダンブラウザではボックスモデルの解釈が違うので本当にメンドクサイ事になるのは周知の事実。
そんなメンドクサイ仕様を回避するべく登場した裏技がbox-sizingと-moz-box-sizingでボックスモデルを制御する方法。

html * {
  -moz-box-sizing: border-box;
  box-sizing: border-box;
}

一行目の-moz-box-sizingはMozillaの独自拡張でCSS3の先行実装。
二行目のbox-sizingはCSS3で実装予定の属性。MacIEは先行実装している。
この技は非常に重宝されて結構みんな使ってたとおもう。

で、IE7で試してみたところbox-sizingは全然効かない。なのでbox-sizingを使って互換モードで作っているとIE7で死ぬって事ですな。
CSS3に実装されるといわれていたbox-sizingも、最近は実装されないんじゃないか？なんて噂も流れてるとか流れてないとか。。。そんな感じだしね～

»box-sizingテスト　box-sizingあり　xml宣言あり

»box-sizingテスト　box-sizingあり　xml宣言なし