非常に地味な display のお話です。
なお、flexboxの話をし出すと、それだけで1エントリーくらいの分量になってしまうので、css2.1までの話をします。
flexbox関係は昨日担当の富田さんがまとめてくれてるので、そちらを参考にしましょう。
flexboxの旧仕様、改定仕様、現行仕様の一覧 « LINE Engineers’ Blog

では、まずブロックとインラインを理解するためにボックスモデルから復習していきます。

ボックスの種類

w3cの仕様書では先に「ブロックレベル要素とブロックボックス」次に「インラインレベル要素とインラインボックス」といった感じで説明されていますが、ちょっと趣向を変えて、ブロックとインラインを対比しながら見てみます。

ブロックレベル要素とインラインレベル要素

ボックスのレベルの話。

ブロックレベル要素

ブロックレベル要素は、ソース文書でブロック（段落など）として視覚的にフォーマットされた要素のことです。
‘display’プロパティの’block’、’list-item’、’table’値は、要素をブロックレベルにします。
御存知の通り、ブロックレベル要素は縦方向にスタックされていきます。

インラインレベル要素

インラインレベル要素はソース文書のうち新しい内容ブロック整形しない要素であり、内容は複数行にまたがります。（たとえば、段落内の文字強調や、インライン画像など）。
‘display’プロパティの’inline’、 ‘inline-table’、’inline-block’値は、要素をインラインレベルにします。

ブロックボックスとインラインボックス

実際に生成されるブロック整形コンテキストに関わるボックスの話。

ブロック

ブロックレベルボックス

ブロックレベルボックスは、ブロックレベル要素によって生成されたボックスです。
各ブロックレベル要素は、子孫ボックスや生成されたコンテンツが含まれており、また、任意の位置決め方式に関与するボックスである主ブロックレベルボックスを生成します。

一部のブロックレベル要素（’list-item’要素）は、主ブロックレベルボックスに加えて追加のボックス（マーカーボックス。簡単に言うと’list-style-type’とか’list-style-image’で決めるもの）を生成することがあります。この追加ボックスは主ボックスを基準にして配置されます。

ブロックコンテナボックス

置換要素とテーブルボックスを除くブロックレベルボックスは、ブロックコンテナボックスでもあります。
ブロックコンテナボックスはブロックレベルボックスのみを含むか、**インラインレベルボックスのみを含みます（匿名ブロックボックスと匿名インラインボックスの話）。
ブロックレベルボックスとブロックコンテナボックスは別で、すべてのブロックコンテナボックスがブロックレベルボックスとは限りません。
非置換テーブルセルや非置換インラインブロックは、ブロックレベルボックスではありませんが、ブロックコンテナでです。

ブロックコンテナでもあるブロックレベルボックスをブロックボックスと呼びます。

非常に雑な言い方をすれば、ブロックレベルボックスがボックスの外側の話でブロックコンテナボックスがボックスの内側の話と言う感じでしょうか。

（置換要素：img, button, input, object等、当該要素の属性に入力される値などによって内容が置き換えられ、その寸法で認識される要素）

インライン

インラインレベルボックス

インラインレベルボックスはインラインレベル要素によって生成されるボックスです。 これは、インライン整形コンテキストに加わるために、ボックスとして定義されたものです。

インラインボックス

インラインボックスは、インラインレベルボックスであり、それらのコンテナのインライン整形コンテキストに加わるボックスでもあります。 ‘inline’の’display’値を伴なう非置換要素は、インラインボックスを生成します。

atomic インラインレベルボックス

インラインレベルボックスであるが、インラインボックスでないもの（置換要素、インラインブロック要素、インラインテーブル要素等。幅・高さの指定できるインラインレベルボックス）は、単一の不透明なボックスとしてインライン整形コンテキストに関与するため、atomic（分割不能・不可分な）インラインレベルボックスと呼ばれます。
atomicインラインボックスは、インライン整形文脈内で複数の行にわけることが出来ません。

匿名ブロックボックスと匿名インラインボックス。

匿名ブロックボックス

次のようなHTMLマークアップされた文書で:

<div>Some text<p>More text</p></div>

<div>はインラインコンテンツとブロックコンテンツの両方を持つように見えます。しかし、整形の定義のわかりやすさのために、”Some text”の周囲に匿名ブロックボックスがあるとみなします。

言い換えれば、ブロックコンテナボックス（上記の例では<div>に対して生成される）が、内部にブロックレベルボックス（上記の例で P）を持つ場合、ブロックボックスの内部はブロックレベルボックスのみになるよう強制することになります。

匿名インラインボックス

次のようなHTMLマークアップされた文書で:

<p>Some <em>emphasized</em> text</p>

<p>は内部にインラインボックスを持つブロックボックスを生成します。”emphasized”のボックスは、インライン要素（<em>）によって生成されたインラインボックスですが、他のボックス（”Some”と”text”）はブロックレベル要素（<p>）によって生成されたインラインボックスです。後者は、関連するインラインレベル要素を持たないため匿名インラインボックスと呼ばれます。

display

ここから、cssプロパティのはなしです。

displayは要素に使用されるレンダリングボックスの種類を指定します。 HTMLでは、デフォルトの表示プロパティの値は、HTMLの仕様か、ブラウザ/ユーザのデフォルトのスタイルシートに記述から取られています。

初期値：上記の通り
適用対象：全要素
継承：しない
アニメーション：不可

: none

要素を整形構造に出現させません。すなわち、視覚メディアにおいて要素はボックスを生成せず、レイアウトに影響しなくなります。
不可視のボックスを作成するわけではなく、ボックスを作成しないのです。
子孫要素もいかなるボックスも生成しません。要素とその内容は整形構造から完全に削除されます。この動作は、子孫での’display’プロパティの設定によって上書きされません。
なお、当然ですがDOM上は存在します。

: inline

1つ以上のインラインボックス要素を生成します。

: block

ブロックボックス要素を生成します。

: list-item

コンテンツのための主ブロックレベルボックスに加えて追加のマーカーボックスを生成します。

: inline-block

インラインレベルボックスコンテナを生成します。 先で説明したatomicインラインレベルボックスです。
MDNに「単一のインラインボックスであるかのように周囲のコンテンツの流し込みが行われる、ブロックボックス要素を生成」と解説されていましたが、inline-blockはブロックコンテナではありますがブロックレベルボックスではなくインラインレベルボックスなのでブロックボックス要素とは呼べず、誤りです。。

: table

<table> 要素と同じように動作、つまりブロックレベルのテーブルを生成します。

: inline-table

インラインレベルのテーブルを生成します。
またMDNに「インラインボックスとしてではなく、ブロックレベルボックスとして動作します。」とありますが、ブロックコンテナのインラインレベルボックスです。

: table-row

<tr>要素と同じように動作します。
指定要素はセルの行となります。

: table-row-group

<tbody>要素と同じように動作します。 指定要素グループが1つ以上の行となります。

: table-header-group

<thead>要素と同じように動作します。 行グループは、常にすべての行と行のグループの前に、かつ任意の上部のキャプションの後に表示されます。 テーブルが ‘display: table-header-group’ をもつ複数の要素を含む場合は、1行目のみヘッダとして描画され、他の行はあたかも ‘display: table-row-group’ を持つかのように扱われます。

: table-footer-group

<tfoot>要素と同じように動作します。 行グループは、常にすべての行と行のグループの後に、かつ任意の下部のキャプションの前に表示されます。
テーブルが ‘display: table-footer-group’ をもつ複数の要素を含む場合、1行目のみフッタとして描画され、他の行はあたかも ‘display: table-row-group’ を持つかのように扱われます。

: table-column

<col>要素と同じように動作します。
指定要素は、セルの列を記述します。

: table-column-group

<colgroup>要素と同じように動作します。
要素グループは、1つまたは複数の列があることを指定します。

: table-cell

<td>要素と同じように動作します。
要素がテーブルのセルを表すことを指定します。

: table-caption

<caption>要素と同じように動作します。
テーブルの説明文を指定します。’display: table-caption’をもつすべての要素はテーブルにおけるcaptionのように描画されなければならなりません。

display: table、inline-table、table-xxxについて

これらの’display’値をもつ置換要素は、レイアウト中にその指定されたdisplay型として扱われます。
たとえば、’display: table-cell’に設定される画像は使用可能なセル空間を埋め、その寸法は通常のセルと同様に、テーブルのサイズアルゴリズムに貢献するかもしれません。

‘table-column’または’table-column-group’に設定される’display’をもつ要素は、レンダリングされません（’display: none’をもつ場合とまったく同じ）が、それらが表す特定の列のスタイルを風洞する属性を持つかもしれないので、有用らしいです。

なお、最近ではいつまでも地雷臭が抜けないflexboxの代わりに、レスポンシブなサイトを作る際に順番を入れ替えたりするのにも使われたりもしているようです。
初日げこたんの2位参照：僕の好きなCSSのプロパティ2013 – < /gecko >

: run-in

・run-inボックスにブロックボックスを含むなら，run-inボックスはブロックボックスを生成します。
・run-inボックスの後に，フロート配置でも絶対位置決めでもない弟ブロックボックスがつづく場合，run-inボックスはそのブロック内の最初のインラインボックスになります。ただし弟のブロックがすでにrun-inボックスで始っているか，run-in自身なら例外です。
・それ以外では、run-inボックスはブロックボックスになります。

run-in要素は視覚的に後続ブロックボックスの一部のように見えるにも拘らず，それでもDOMツリー上にある親からプロパティの値を継承します。 すなわち，一見して親であるかのように見えるブロック要素から値を継承される訣ではない，という事です。

: compact

面白いんですが、Operaがレンダリングエンジンをprestoからwebkitに変えたことで、対応ブラウザがなくなったので割愛します。

以上、W3Cの仕様書を日本語訳しただけのようなエントリーでした。

明日、8日目はくぼしょーさんです。
お楽しみに！

2席開いていて直ぐに座れた。

店員は、店主と助手の2名だった。

食券に100円添えて、うずら卵をお願いした。

着席して6分ほどでラーメンできあがり、助手の方からトッピング訊かれて、 ニンニク少な目ヤサイアブラをお願いした。

小ラーメン+うずら卵 ニンニク少な目 ヤサイ アブラ 800YEN

さっそく、いただきます。

ブタ、
良く煮込まれた感じで、トロットロにトロけるほど柔らかいもの。
二切れ。ひとつは特大

麺、
モソモソとした蓮爾らしい麺。小麦を強く感じウマい。

汁、
醤油と豚の甘み旨味が絶妙なバランスで利いている。
うんめ～。

完飲。ごっそさんです。

明日のラーメン Advent Calendar 2013の記事

●2013/12/08 : SOUさん

予告どおりギャンブルの定番スロットゲームです。

前回のフリースローで学んで、回転速度を相当遅くしてみたのですがどうでしょうか？
MAXBETボタンとコイン枚数の表示は飾りです。1枚しかbetできませんし、コインは返って来ません。そんな飾りはあるのにコイン投入口はありません。

大当たり（大したことないですが一応）は777だけです。謎の小当り的なもの（パネルの表示がちょっと変わる程度）が結構あります。

いつも通りChromeのみの動作確認です。

適当な解説

基本的にはフリースローと同じ

小見出し通りです。元々、こっちを先に思いついて作っていて、後でフリースローにも使えると思って作った感じなので、コチラのほうがフリースローより地味と言えば地味です。トリ前なのにスミマセン。

ただ、フリースローが上・中・下 or 左・中・右の3種のボタンの順序切り替えなのに対し、こちらはリールの数字１つずつで10種のボタン切り替えなので面倒です。とはいえ、CSS上は似たようなことの繰り返しなのでsassで処理させてもらいました。

ボタンの切り替え速度が速いので、結構ズレます。数字が揃っていないくてもアタリになったり、揃っていてもアタリにならなかったりすることが稀によくあります。仕様です。

リールの回転はstepsで

リールの作り自体は既にコロプラさんというか@mattari_pandaさんが、『CSSアニメーションでスロット風くじを実装：後編』として良い感じに説明してくださっているので、見た目の感じなどはほぼ丸っと参考にさせていただきました。

ただし、今回はnoJSですのでリールがいい感じに滑ったりはしてくれないため、普通にアニーメーションしてしまうと中途半端な位置で数字が止まり、どの数字で止めたのかわからなくなっています。そこでanimation-timing-functionをstepsで指定することで、カクカクにはなりますが、ちゃんと数字が中央で止まるようにしています。

実際、stepsを指定したときとしていないときの差は、2日目まとりさんの『CSS Stopwatch』にて、カウントスタイルを切り替えてもらうとわかりやすいと思います。

<input type=”reset”>

ちょっとした新機軸はresetでしょうか。今まではリセットするときはリロードで誤魔化すことが多かったですが、「スロットで毎回リロードはなぁ」と考えていて思いつきました。というか、こんな単純なこと何故今まで思い浮かばなかったんでしょうか。

ただし、毎回resetで全てのinputからcheckedを外してしまっているので、コイン枚数の計算などが出来ないという少々残念なことにもなっています。

前回作る予定だったパズルは、このresetを利用して、上海を作るつもりだったのですが（選択中の牌のペアになる牌以外はresetになっていて、他の上海同様に選択中の牌の解除が容易にできるモノ）、上海は2枚一組で牌を消していくゲームであるものの同一牌自体は2枚以上あることに気づき「これでreset使ったら消した牌まで復活しちゃうじゃん…」ということでポシャりました。

電光パネル

パネルは5509さんの『電光掲示板をあのmarqueeとCSS3のグラデーションで』の色を調整したくらいです。

今回見た目に関しては、本当に色々な方を参考にさせていただきました。

SCSS

最初の方に適当なmixinが書いてあるのは、jsdo.itがcompassに対応する前に作り始めて珍しくchrome以外でも見れるようにしようと思ったのですが、面倒くさくなって途中で辞めた名残です。

最初にも書いたボタンの重なりの切り替えに関して、scssファイルで言う500行目過ぎからなんですが、keyframesも@forで処理しています。keyframesの%前に変数を使った場合、%をそのまま%と書くとエラーが出ます。今回は $per: unquote(“%”); なんかを先に作って #{$per} で出しましたが、 多分 #{‘%’} あたりでも大丈夫なんじゃないでしょうか。似たようなことをする場合、適時処理してやってください。

見た目

大当たり時に出る画像以外は全てCSSで表現しています。前述のとおり、色々な方を参考にさせていただきましたし、見た目が一番頑張った気がします。

次回予告

明日はいよいよ最終日、我らが（？）jsdo.itチームさんです（ まさかここ？いや、多分この辺かな？）。
まとめと言いながら、何か凄いものを作っているらしいので期待しましょう。

さて、今日は元々宣言していたパズルがポシャったのでかるいやつを、ということでCSS Loupeを作りました。JSでたまにあるこういうもののPure CSS版です。

クリスマスっぽい画像を探したら、全体的に赤でちょっと拡大がわかりにくくなってしまったでしょうか…

フィルターかけるボタンとかつけようかとも思ったのですが、付けたところでルーペとしてどうにかなるわけではない（という言い訳で若干面倒くさい）ので辞めました。

適当な解説

画像の上にdivを敷き詰めて、hoverするdivに合わせてルーペが移動。拡大画像はルーペの背景画像になっていて、同じくhoverに合わせて背景の位置が動く仕組みです。元画像と拡大画像の端を合わせるのがちょっと面倒くさかったです。いつも通り、細かいことは、ソース見て下さい。

CSS3でマウス追尾/Mouse Following Arrowあたりと似たような感じのはずです、多分。

コードは短くしよう

できる限り精密に動くように、1×1のdivを敷き詰めようとしたのですが、divの数が云万になり空divとは言え尋常じゃないくらい重くなってしまいました。更に、cssの方はsassさんというかrubyさんというか兎に角その辺に「でかすぎてコンパイル出来ねーよ」と怒られてしまいました。そんなことが起こることを初めて知りました。expandedでコンパイルしてどれくらいだったのでしょうか。単純に考えると10×10の公開作品で6000行なので、1×1なら100倍して60万行？

自動生成できるからといって、サイズが大きくなりすぎるのはやはりよくありませんね。気をつけましょう。（htmlも元はJSで作ったのは秘密）

結局はdivを徐々に大きくしていき、10×10で作りましたがwebkit以外だと未だにかなり重いと思います。

CSSプログラミングについて

作ったものがかるいので、CSSプログラミングの制作について話します。

制作にはどれくらいかかるの?

リアルで人に会うとちょくちょく聞かれます。

実際の作業に関して

「大してかからないんですよ」と答えていますが、実際仕組みを作るということに関しては大してかかりません。特に最近はCSSプリプロセッサーがあるので、CSSプログラミングでよくある面倒くさい繰り返し作業もサラッとやってくれます。

今回の作品群は割りと仕事の空いた時間等でちょこちょこ作っているので何ともいえないのですが、CSS Minesweeperあたりは土日の2日で大体作った気がします。まぁ、二桁時間もかかっていないでしょう。更に、あれは実際にゲームをクリアして作りやすそうな座標をさがすとか、その座標をチマチマhtmlに打つとかそういった作業に時間を食っています。座標打つのは苦痛以外の何モノでもありませんでしたｗ

CSS Minesweeperは動きがないのでそういった感じでしたが、前回のCSS FreeThrowやCSS Baseballはボールの動きや時間配分を調整するのに時間がかかりました。特に、CSS FreeThrowはボールもCSSで作ったので、その辺や、メーターとボタンの連動に関するデバッグというか調整というか、そういうことに割りと時間をかけています。

まぁ、そういった感じで、CSSプログラミングとはいえ実際の作業は、仕組みを作るより装飾などのほうがよっぽど時間が掛かっています。実際、そこをある程度凝らないと結構な仕組みでもパッと見、大したものに見えなくなりますし、個人的にはゲームとして作ることが多いので見た目をある程度凝ったほうがウケもいいです。そういう意味では、装飾に命をかけたCSSのみで作ったアイコン等のほうが、実際の作業時間としては長いかもしれません。

1%のひらめき

プログラミングにかかる時間は9割が考えたり調べたりする時間で、実際にコードを書くのは1割くらい、などと言う話を聞いたことがありますが、CSSプログラミングに関しても似たようなものです。

ただ、CSSプログラミングにおいてはどう作るかと言うよりは、何が作れるかということを考える時間が長いです。まぁ、「作れるものを考える≒仕組みを考える」みたいなものなんですが。

普段は思いついた時に作るのでいいのですが、今回のAdvent Calenderでは期限が決まっているため、一体何が作れるだろうかと、Flashゲームやスマホゲームを見まくりました。見ても何も思い浮かびませんでしたが…

逆に言えば「あっ、これはCSSで作れそう」というひらめきがなければ、一生作れないかもしれません。

なんでJS使わないの？

ロマンです。

CSSプログラミングをする利点は？

本来の使い方か否かは別にして、CSSには詳しくなれます。また、思わぬバグを発見できたりします。バグを見つけることが利点か否かは置いておくとして、知っておくのはよいことだと思います。先日もテスト用に::before、::afterを使おうとしたら予想以上に面倒くさい現象に出会いました（inputに対する::before、::after）。知らずに実務で遭遇すると詰むようなことも、事前に知っておけるというのは良いことです。（実務で使わないような事のほうが多い気もしますが）

次回

明日は、Tenderfeelさん（16日ぶり2回目）です。急遽名乗り出てくれました。よろしくお願いします。

自称CSSプログラマーのげこたんじゃない方、力技に定評のある1026です（今自分で考えました）。

最近はinputでほげほげ以外の方法も増えていますが、定評のあるあくまでinput:checkedに頼った力技でCSSフリースローゲームを作りました。環境によって読み込みが遅い・重い可能性があります。いつも通り、chromeでしか確認していません。

適当な解説

メーターとボタンの連動

CSSでこのメーターの位置はとれません。そこで、横は左・中・右の3種類、縦は上・中・下の3種類のinput（ここでは其れに対応するlabel）を重ねておき、メーターの動きに合わせて重ねたinputのz-indexが入れ替わり、メーターの位置に相当するinputが一番上にきて押すことが出来るという仕組みです。この「ボタンは重ねておいて必要なのを一番上にすればばいいじゃん」という発想はno JS Loop Sliderあたりでも使いました。
inputが順番にz-indexで入れ替わる仕組みは、CSS Minesweeperのときのランダム風な動きと同じ要領です。サムの動きのanimation-durationとボタンになっているinputのanimation-durationを同じにしてやればいいわけです。

inputは高速で動くとcheckedが入らない

CSS BASEBALLの時に学びましたが、動いているinputは非常に押しにくいです。ましてやこれはコンマ何秒という速度で入れ替わっているので、そのままでは、とてもクリックを認識してくれません（checkedはJSでいうMouseUp時につきます）。そこで、CSS BASEBALLの時に教えてもらったようにactiveになると動きを止めるようにしています。止めるのがボタンだけではメーターとずれるので、勿論メーターも止めています。checkedだけでなくactive等に関してもlabelとinputが連動していて助かりました。それでもcheckedがつかないことがまれによくあります。

動作の不具合を作りの緩さを誤魔化す見た目

そんな不具合や画像を使わない作りこみのなさを誤魔化すための、安いゲーム風の見た目です。寂れたサービスエリアのキーホルダー売り場に売っているようなゲームですから、ちょっとやそっとのバグはお気になさらずに。両方のメーターが止まってもボールが飛んでいかない場合は、後から押した方のボタンをもう一度押すといいはずです。

結論：ソース見ろ

いつも思うんですが、僕のCSSプログラミングの解説はまったく解説になってませんよね。でも、inputで云々というCSSプログラミングお決まりのパターンを繰り返しているだけなので、ソース見てもらえばいいと思います。

おまけ

ちなみにsass先生に大活躍していただきましたが、画像をdateURIにしたわけでもないのexpandedでコンパイルしたら3000行を超えていて気持ちが悪くなりました。

次回予告

個人的

最低あと2回は記事書きますが、1回は今回同様の仕組みで作るアレです。twitterでネタバレしたアレです。

全体的

13日目の明日は…（あれ？また？）…げこたん（5日ぶり3度目）です。大丈夫なのでしょうか。