section:after,
article:after,
div:after,
ul:after {
content: “”;
clear: both;
display: block;
}

display:tableやdisplay:flexをつかうようになってそもそもfloatをあまり使うことがなくなったのでそのうちこれもいらなくなるかなとは思うんですが、でもまぁ文字の回り込みとかには使うよね。

その昔はIE対策でもっとながい記述が必要でしたが、最近は対応ブラウザのバージョンもあがっているのでこれにしておりました。

よくclear使う要素にあらかじめおまじないをかけておく方式ってやつですね。

これでhtml側のclass=”clearfix”から解放されます。

・・・っておもってたら思わぬところでひっかかりました。
しかもfloatじゃなくてdisplay:flexで。

flexをかけてかつjustify-content：space-between；で均等に幅をあけようとおもったら最後尾にへんな隙間が。右ぞろえにならないぞ。
なんだこれって検証した結果このclearfixでつくっている疑似要素分の隙間でした。

というわけでおまじない方式を使う場合
・flexでspace-between適応した要素のafterをdisplay: none;
・おまじないはdisplay: none;にしといてfloatをつかった時に親要素afterにdisplay: block;
のどちらかの対応が必要ということに。
flexをよく使うようになったからこそ1行増えるってのが皮肉ですね。

やっぱりflexをよく使うようになった今はおまじないはやめて
.clearfix:after {
content: “”;
clear: both;
display: block;
}
でfloatつかったら親要素にclassをつけましょうってことにしたほうがシンプルなのかもしれない。

The post 最近使ってるclearfix（2017年版） first appeared on Star Penguin Studio.

どうも幅100%＋padding(border)の幅を描画しちゃうらしい。
解決策としては
input[type=”text”]{
box-sizing: border-box;
}

というふうにbox-sizingをbordrやpaddingも含めて100%にするように指定すればOK。
最近では最初のresetとして全要素にbox-sizing指定してます。

The post ios safariでinput[type=text]の幅が100%だとはみだす first appeared on Star Penguin Studio.

Togetter – CSS Nite LP18「その先にあるjQuery」

中級者向けということで、jsメインなサイト制作時に問題になってくる高速化や
JSアプリケション制作の設計方法についてのセッションでした。

jQuery高速化

西畑（＠KazumaNishihata）さん
モバイル環境でjsを使う場合などにパフォーマンスを意識しないといけないのですが、その方法について。
・まずはベンチマークで計測しよう
・遅い箇所にポイントを絞って高速化

具体的には
・eachメソッドをfor文へ
・DOMアクセスから正規表現へ
・変数に代入してセレクタをキャッシュ
・querySelectorAllの利用
・DOM操作をできるだけ避ける（最後に一回だけ操作するような書き方）
・不要なAjaｘリクエストの破棄 abort()

などなど実践的なTIPS満載でした。

Rich JavaScript Application

前半は徳田(＠5509)さんのjqueryの新しい機能やライブラリのお話。
noriさんは大阪の.coder以来だったんですが、ボケがすべてすべっててかっこよ(ry

・jquery Deffered
・jquery template
・custom event
・Event delegation

jquery templateはPHPのsmartyぽいし、
custom eventとかdelagationとかは他のオブジェクト指向言語をやってる人にとっては馴染み深いかもしんないです。
多言語かじるのも大事だよねぇ、とかいいつつ私も概要くらいしか理解できてないのでもっと勉強しないと。。。

後半は高津戸(@takazudo)さんのぽちってもうたーというウェブサービスを例にあげて、
開発時の設計、開発工程について。

UIごとのパーツ分け（ウィジット化）、
ウィジットをメソッドとイベントをもった単位にして他パーツと連携する
機能とデザインの分離、
それによってテストのしやすさ機能変更や追加のしやすさ
といったメンテナンス性の向上につながるというお話でした。

このへんはウェブアプリケーションを他言語で作られた経験がある人は無意識にやっちゃってる気がするけど、
オブジェクト指向な実装ってことをすごくわかりやすく説明されてました。

あと個人的にいつか使ってみたいなっておもったのがDavis.js
jsの状態をアドレス分岐する方法として、
他にハッシュ（location.hash）で分岐させるやりかたがあって、
そっちでもいいかもだけどURLとしてやっぱ気持ち悪いなーと思ってたもので。

The post CSS Nite LP, Disk 18に行ってきた first appeared on Star Penguin Studio.

Osaka.cssは@konitterが主催されてるHTML＋CSSコーダー向けの勉強会です。
参加者全員でディスカッション形式でした。

話題にでたもので個人的に気になったもの抜粋

コーディングガイドラインの策定について

id class名についてこれを使えではなくて、協力他社（他者）が決めた名前とかぶらないようにこれは避けてね的意味で仕事を依頼するときにわたしてる。

→前の会社では社員やサイト規模の大きいものが増えてきてから、一から社内統一ガイドラインをつくったのですが結構大変でした。でも制作保守含めて関わる人が多いようなら絶対必要ですよね。結構人によって書き方の好みとかがあるので難しいですけど。上記みたいに最低限だけでも決めとくといいかも。
ちなみに前の会社ではid class名から画像の名前のつけ方とかまでやりましたよ。そうするとサイトによってデザインの詳細がちがっても、同じレイアウト構成・パーツ構成だとhtml＋cssを使いまわせたりして効率あがるので便利。

最終的に、フッターリンクやぱんくずリストなど、どのサイトでもよくあるパーツについてコピペだけで作れるようにモジュール化してましたね。

命名とSEOの関係について

googleでは、多くのサイトでどういう名前で使われているかを統計していて、例えばメインメニューだったらclass名にnavigationが使われているとかをみてこれはメインメニューとgoogleは判断してたりするらしい。なので極端に変な名前するとかはしないほうがいいかもね。

→googleさんならやってそう。まじか、しらなかったなーってググってみましたがソースが不明。どなたかご存知でしょうか？

逆に重要でないコンテンツをクラス名で判別というのをyahooの例で見つけました。
ウェブページ内の重要性の低い要素を検索エンジンに通知
へーへー、しらなんだ。まぁyahooのエンジンかわるから今後どうなるかわかんないけど。

CSSプロパティの順番

CSSプロパティの書く順番をfirebugで表示される順にしている

大半の人はmozillaの「ボックスモデルによる記述順番」を採用してるみたいでしたが、firebugで探すのがめんどうなのでfirebugの表示順にあわせてるという方がいてへーと思ったり。
あとはオレ基準でレイアウトにからむwidthやheightなどが上とか、floatとか影響力があってよく参照するのが上とか利便性重視という声も。

ＣＳＳのライブラリ

YUIのresetとfontを使っているという人多数。
ちなみにわたしはYUIのresetとfontをベースに独自改造したものをリセット用として使ってます。
なんか問題でたら直す感じ。
（このサイトのはhtml5用リセットってことで人様のを利用させてもらってますけども＾＾；）

グリッドシステム系は960.gsがおすすめ。960 CSS Framework

→グリッドシステム系はなんとなく今まで食わず嫌いでスルーしてたので、一度ちゃんと見てみようかな。

パフォーマンスを取るか製作コストの削減を取るか

パフォーマンスについてYSLowでリクエストの速度はわかるけどレンダリング自体の速度を測るものがない。知ってたら教えて。

CSSファイルをひとつにまとめるかどうか。まとめてリクエストを減らしたほうがパフォーマンスはいい、けど長くなると管理しづらい。

CSS　Spriteの話やファイル圧縮の話なんかもでました。バランスのいいところを見極めないとねー。

デザインと工数の話

角丸デザインの実装方法の話題から、そもそも角丸デザインって必要か？てな話になったり。
要は「実装に工数がかかるデザインだった場合、デザイン修正するかどうか？」というところ。
だいたいコーディングが制作フロー的にいつも一番実装時間を削られてしまっているわけで、その少ない時間をよくわからないデザインのこだわりによってコスト（作業時間）がかかるのは嫌だよね。

クライアントからの要望の場合、それをするためにこういうコスト（時間・費用）が余計にかかりますけどと説明して納得してもらう。その交渉はディレクターの仕事。

自社のデザイナーだったら説明して直してもらったりするけど、外注だと修正のその労力を考えてそのままの場合も

必要あるデザインかどうか、これじゃないとだめという説明が理論的にできるならコストかけるのは当然と思う

コーディングしやすいデザインを考えているといつも似通ったデザインになる可能性が。なので考えないでデザインしたほうがいいこともあるかも。

などなど一番盛り上がった話題でした。
ウェブデザイナーはコーディングの基本をわかった上でデザインすべきと思ってます。よいデザインって何かって考えたときに、実装できないデザインなんてのは論外ですけど、制作コストがかかりすぎるデザインってよいデザインだと思えないのですよね。クライアントとしても、デザインにはこだわりをみせてもコーディング部分は軽視されちゃってますし、コーダーが涙をのんで余計なコストかけるのがよいこととは思えません。

日ごろコーディングしてて思ってたこと、あるあるばなしを一杯きけて、やっぱみんな同じなのだなーと思うところひとしきり。大変おもしろかったですね。

次回Osaka.cssは10/30に開催とのことです。

The post osaka.cssに行ってきました first appeared on Star Penguin Studio.

こちらの方とかあとこちらの方のエントリーがわかりやすかったです。
詳しくはそっちを見てね。。。で終わってしまうのもなんなので以下私が気づいた点をいくつか。

firefoxでmargin:0 auto;が利かない

2カラムレイアウトとかで中央よせになってるデザインがよくあると思います。今のところdisplay-boxを指定してあるとmargin:0 autoを指定しても中央に来てくれません。
親要素にtext-align:center;を指定すると中央に来てくれます。IEみたいな挙動ですね。。。

かってに横幅が拡張される

親boxにdisplay:boxとともにwidthをきっちり指定してる場合でも、子ボックスの横幅合計がその数値を超えるとその分指定幅を無視して横にひろがります。webkit系とfirefox両方でそういう挙動ですが、微妙に広がり方がちがっています。

これだと意図しないカラム落ちはしませんが、floatを利用した時のように指定幅を超えたら自動で折り返して二段目に、みたいな実装ができないわけですよ。
なにか方法ありそうな気もするけど。。。

floatでいいんじゃない？

ユーザー数の一番多いIEで未対応なので、対応環境にＩＥを含める場合なにか対策を考える必要があります。今回うちではスターハックでIEのみfloatにしてます。

残念ながらoperaさんには犠牲になってもらったよ。。。(オペラの最新版でいままでのオペラ用ハックが使えなくなってたりして、これ以上((複雑怪奇かつ将来性が保障されない))ハックつかうのやだー。display：boxにとっとと対応してください。大丈夫君ならできる。IEとはちがうのだよ、IEとはっていうところを見せてry）

また現在対応しているのはfirefoxとwebkit系のブラウザですが、display：boxの指定にそれぞれのプレフィックス、余白の挙動が違ったりするのでそれの対策用の記述などが必要です。
まだ色々策定中なのでしょうがないともいえますが、裏をかえせば今後のバージョンアップで挙動がどう変わるかわからないというメンテナンス上の不安が。
そこまでして使うメリットがいまいちなような。

The post display:boxの挙動 first appeared on Star Penguin Studio.