そんな中、StyleDocco、KSSはともかく、kss-nodeのデフォルトテンプレートが非常に残念な感じになっており、「悪くないのにこれじゃあ導入しにくい」なんて方もいらっしゃるのではないでしょうか。

かくいう私も、先日twitterにて「kss-nodeのデフォルトテンプレートが微妙すぎるのに、探しても全然見つからない。もっと、みんな作って公開すればいいのに。githubのとかいいよねぇ」的なことを話していたところ、CSSプログラマーに「おぬしがつくれば」と言われてしまいました。
その場では聞こえないふりをしたのですが、結局作ってしまいました。

kss-node-template-such-as-github

kss-node-template-such-as-github

GitHubのようなkss-nodeテンプレート。何のひねりもない名前です。

kss-nodeとはなんぞやということや、使い方は割愛します。
知らない方はググってください。

石本さんがgrunt-plugin化したgrunt-kssを作っていたんで、grunt導入済みの方はそちらをご利用になると便利かもしれません。

微妙に余計なpタグが入ってきていてinlineにしてやったりと、無理やりっぽいところはありますが、とりあえずKSS・githubのスタイルガイドにそっくりです。
素敵です。

著作権とかライセンスとか的なところが気になりますが、とりあえず公開します。
なにかあれば、適当にPull Requestでも送ってくださっても、自分だけこっそり直して使っていただいても構いません。

怒られたら消します。

非常に地味な 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日目はくぼしょーさんです。
お楽しみに！

というわけで、細かい話 は、ほぼ table系にはposition:relativeが効かない ( http://gyauza.egoism.jp/clip/archives/2007/11/071129-tablepositionrelative/ ) にあった内容を引っ張ってきて、文調と表現を若干変えてうちのブログに合わせただけです。許可も取ってませんが、お許し下さい。

Firefoxが正しい

<td> や <div style=”dispaly:tablec-cell”> の中身を絶対位置で指定したいなー
↓
親の<td> や <div style=”dispaly:tablec-cell”> に position:relative を指定
↓
chrome や IE で確認、よし出来た？
↓
あれ？ Firefox では position:relative が効いてないぞ

<div>
    <table>
        <td>
            <div class="left">左上</div>
            <div class="right">右下</div>
        </td>
        <td>
            <div class="right">右下</div>
            <div class="left">左上</div>
        </td>
    </table>
</div>

div {
    position: relative;
}

td {
    position: relative;
    width: 200px;
    height: 100px;
    border: solid 1px #000;
}

.left {
    position: absolute;
    left: 5px;
    top: 5px;
    color: red;
}

.right {
    position: absolute;
    right: 5px;
    bottom: 5px;
    color: blue;
}

サンプル

あると思います。

これは Firefox のバグではなく、 Chrome(webkit・blink全体？Androidでは効かないという情報あり) や IE が独自の実装をしているのです。効かない方が正しい表示です。
「Androidでは効かないバグかー」といったようなツイートを見かけたこともありますが、どちらかと言えば効いている方がバグみたいなものです。

細かい話

CSS2.1 Visual formatting modelによると

The effect of ‘position:relative’ on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined.

CSS2.1 – Visual formatting model – 9.3.1 Choosing a positioning scheme: ‘position’ property

テーブルの中身系に対する position:relative の指定は、定義されていません。よって、この通り実装している Firefox では無視されるわけです。

尚、親の table や display:table; に position:relative; を指定しても、そこを基準に絶対配置はしてくれません。御存知の通り、 position:absolute を指定した要素は、祖先の包含ブロックに position:static 以外を指定したとき、そこを基準に絶対配置するのですが、どの要素が包含ブロックを作るかは決まっていて、最初の包含ブロックは viewport、ようするにブラウザの表示領域ですが、それ以下の要素に関しては

For other elements, if the element’s position is ‘relative’ or ‘static’, the containing block is formed by the content edge of the nearest block-level, table cell or inline-block ancestor box.

CSS2.1 – Visual formatting model details – 10.1 Definition of “containing block”

block-level / table cell / inline-block が、この包含ブロックを作りますが、table はブロックレベルのような振る舞いをするだけで、実はブロックレベルではないらしく、包含ブロックは作れないようです。Tableの項を見ると

In terms of the visual formatting model, a table can behave like a block-level (for ‘display: table’) or inline-level (for ‘display: inline-table’) element.

CSS2.1 – Tables – 17.4 Tables in the visual formatting model”

正に「tableはブロックレベル（やインライレベル）のように振る舞える」だけでブロックレベルではないようです。

おわり

最近は display:table-cell とか非常に便利ですが、この辺は理解しておかないとドハマリするよ、ということで、毎度あげさせてもらっていた記事が消えていたので、勝手にそこだけ復旧的な記事でした。

[ incomplete ] CSS Invaders

インベーダーを作りたかったというのはわかっていただけると思います。

敵の横移動が絡むと予想以上に自機の動きや位置が綺麗にできず、面倒くさくなって投げちゃったってとこです。

打つシステムとしては、敵をラッピングしているlabelを縦長に伸ばして、敵を直接クリックせずとも、その延長線上をクリックすると打った風になるという感じです。
この説明では何を言ってるか全くわからないと思うので、ソース見てください。

こういった、クラス名だけ変えて延々繰り返しみたいなコードを書くときはSCSSはほんとうに便利ですね。人力では絶対書きたくないです。

お暇な方、興味のある方は、forkして調整・機能追加してみませんか？
『皆で作ろう、CSSインベーダー』

まず、げこたんがスコアつけてくれたよ。
スコアをつけました forked: [ incomplete ] CSS Invaders

昨日ゴロドクさんが改めて丁寧に解説にしていましたCSSのみ画像不要の吹き出しの作り方。
せっかく丁寧に説明されているので、基本的な作りからはそちらを御覧ください。
CSSのみ画像不要の吹き出しの作り方を若干丁寧に解説してみる

影の付け方

せっかく吹き出しなので「影も付けて更にそれっぽくしたいたい！」と思う方もいらっしゃるかと思います。
ただ、これには割と癖がありませして単純にdrop-shadowをかければいいというわけではありません。吹き出しの▼部分に影がなかったり、影が被ったり、ずれたりしてしまいす。

パターン1：影を隠す

「影が▼と被ってしまうなら、被ってしまう部分を上から隠そう」という方法です。
こちらは以前Zumaさんが紹介していた方法です。
以下Zumaさんのブログを御覧ください。
影付きの吹き出しをスマフォ向けにCSSだけで作る方法

パターン2：影を別につける

「影が被ってしまうのなら、そのまま付けなければいい。別に付けてやろう」という方法。

擬似要素の片方でborderではなく、ボックスを transform の rotate と skew を使って吹き出しの▼部分を作成。元の要素自体には影を付けず、余った擬似要素を元要素と同じ大きさにして影を作成。z-indexで元要素の影→▼→元要素と重ねてやる方法です。

サンプルで力技と書いている通り、本来は高さを指定したほうがいいです。<br>等による改行なしの場合は、content: に吹き出しの中と同じテキストを入れてやり、font-size、line-height を元要素と同じにしてやるとどうにかなります。

面倒な箇所としては、▼の部分をrotateで回して実現しているので、元要素と同じ数値で影を指定すると違う方向に出てしまいます。見ながら調整が必要です。

以前、要素の重なりの話で解説しましたが、元の要素がスタックコンテキストを生成するとこの方法がとれなくなるので注意。

また、影用の擬似要素には元要素と同じ背景色を設定したほうが綺麗に出来る気がします。透明にしてしまうと、元要素と影の間に微妙に隙間ができるような…

パターン3：filter: drop-shadowを使う

現状ChromeとSafari6しか使えませんが、ゴロドクさんの方法で▼をつけて、▼に filter: drop-shadow で影をつけてやる方法です。

box-shadow ではボックスに対する影なので、一部ボーダー見た目上消して▼を実現しているゴロドクさんの吹き出しの作り方では▼とは違う位置に影が現れてしまいますが、 filter: drop-shadow ならコレが解決できます。
webkitさんは本当に優秀やで。

まとめ

というわけで、CSSのみ画像不要の影付き吹き出しの作り方を三種列挙してみました。

今すぐ使わなくとも、今後「あれ？吹き出しに影が上手くつけられない！」みたいなことが起こったときのために、こんな方法があるというくらいに頭にとめておくのも悪くはないのではないでしょうか。

というわけで、実は割りと複雑な要素の重なりについて書きます。そこまで意識しなくとも支障がでることは滅多にないと思いますが、知っておいて損はないはずです。
ちなみに、昨今CSS3なるものが流行していますが、この記事はW3CのCSS2.1勧告（と付録）を元に書いています。
基本的な内容であり、目新しいことは特になにもありません。

スタックコンテキストとスタックレベル

用語と概念から。
ある意味、ここが一番よくわかりませんが、ここがわからないと何もわかりません。

スタックコンテキスト（スタッキング・コンテキスト）

簡単に言えばauto以外のz-indexと位置（static以外のposition）を指定した要素によって生成される階層構造を形成する固まりです。ただし、ルート要素（html）はルートスタックコンテキストを整形するので、例えz-indexを一つも指定しなくとも、スタックコンテキストは存在することになり、各ボックスは何らかのスタックコンテキストに属することになります。

スタックコンテキストはその内部に追加のスタックコンテキストを含むことができ、z-indexに整数値を指定すると自身のスタックレベルを0としたローカルスタックコンテキストが生成されます。しかし、スタックコンテキストは各階層における構造によるものなので、あるボックスが同時に複数のスタックコンテキストに股がって属したり、他のスタックコンテキスト内のボックスが任意のボックスの間にくることはできません。

スタックレベル

ボックスは同一スタックコンテキスト内でのz軸の位置となるスタックレベルを持ちます。まぁ、z-indexで指定する数字です。

同じスタックコンテキストに同じスタックレベルを持つボックスがある場合、構造内での順番に従って背面から前面へとボックスが積み重ねられます。

基本的な重なり

基本的に以下のレイヤー順番で重なります（スタックコンテキスト内での子孫の塗装順序）。W3C勧告に倣い、先に書いたものが下層、後に書いたものが上層になります。

1. スタックコンテキストが整形する要素の背景とボーダー
2. 負のスタックレベルをもつ子スタックコンテキスト
3. インラインレベル以外の位置（position）を指定していない要素
4. 位置（position）を指定していないフロートしている要素とその子孫
5. インラインレベルの位置（position）を指定していない要素（但しインラインテーブル・インラインブロックを含む）
6. z-indexがauto又は0の要素とその子孫
7. 正のスタックレベルを持つ子スタックコンテキストとその子孫

以上の基準に基づきながら、同レイヤーに存在する・同スタックレベルを持つ場合は後から書いたものが上層に、先に書いたものが下層に配置されます。

z-index

注：z-indexはブラウザによるバグが少なくなく以下に書くように動作しない場合があります。

z-indexは垂直位置を指定する

z-indexはボックスの重なりの順序を指定するプロパティであるとよく言われていますが、垂直（z軸の）位置を指定するプロパティと考えた方がよりわかりやすいのではないでしょうか。x軸・y軸の位置をtop(bottom)・left(right)で指定するのと同様にz軸での位置をz-indexで指定するのです（スタックコンテキスト内で）。

よって、x軸・y軸の位置を指定するときと同様にpositonにstatic以外（relative、absolute、fixed）を指定しなければいけません。

z-indexにはpositionが必要⇔positionあるところにz-indexあり

z-indexを指定するには position: static; 以外の指定が必要といいましたが、逆に、position: static; 以外を指定すれば自動的にz-indexが指定されていることにもなります。ある要素に、あなたがposition: static; 以外を指定すると、その要素は自動的にz-indexの初期値である auto が指定されたことになります。

普段意識せずに使っているかもしれませんが、positionを指定した要素がz-indexを指定せずとも以降の要素の下に隠れないのは、これによるものです。

先ほどのリストを思い出して下さい。

「z-indexがauto又は0の要素とその子孫（つまり、positionを指定した要素）」は「正のスタックレベルを持つ子スタックコンテキストとその子孫」を除き、その他の要素より上層のレイヤーとなります。これにより、absoluteやfixedでのナビゲーション固定などをz-indexを指定せずとも自然に実現できているわけです。

実際のコードとサンプル

z-index: auto; と z-index: 0; の違いとスタックコンテキスト

z-index: auto; を指定したボックスのスタックレベルは0であり、上記のようにスタックコンテキストを作成したかのように要素を扱いますが、実際に新しいスタックコンテキストを作成しているわけではなく、親スタックコンテキストの一部と考慮されるます。対して、z-index: 0;はスタックコンテキストを生成します。

どちらも色の薄い方に z-index: -1; を指定しています。
実際のコードとサンプル

z-index: 0; を指定した要素はその指定した要素の背景が最下層となりますが、z-index: auto; を指定した要素はそうではありません。先ほどのリストを見ると、スタックコンテキストの最下層はスタックコンテキストが整形する要素の背景であることから、z-index: auto;を指定した要素は実際には新しいスタックコンテキストを作成しているわけではないことがわかります。

尚、これは::before、::afterといった擬似要素にスタックレベルを指定した場合でも同様の動きをします。擬似要素の元になる要素がスタックコンテキストを生成した場合、::before・::afterに関わらずそのスタックコンテキストに属することになります。よって、CSS3によって流行りとなった紙が捲れたような影を付ける場合などは、元の要素にz-indexを指定して新たなスタックコンテキストができてしまうと、幾ら擬似要素にマイナスのスタックレベルを指定しようとも影が元要素の背景より上に出てしまいますので注意が必要です。

実際のコードとサンプル

新たなスタックコンテキストが出来る出来ないという結果を見てもう一つわかることは、このスタックコンテキストというものがあることにより、z-indexを指定したからといえ完全に好きな階層に置けるわけではないということです。スタックレベルは同じスタックコンテキスト内での順序を決めるものであるため、そのスタックコンテキスト外では機能しません。

例え先祖要素であってもより近い先祖要素にz-indexを指定した場合、その要素の背景より下層に配置することはできませんし、もちろん、先述した通り他のスタックコンテキスト内の任意の層に配置することも出来ません。

逆に言えば、余計なところにスタックコンテキストを生成しなければよいわけですから、不必要にz-indexを指定するのを避ければよいということにもなります。

ちなみに、有名なバグとしてIE7ではz-index: auto; でもスタックコンテキストを生成します。割りと困ります。

z-index以外のプロパティのスタックコンテキストの導入 〜 opacity

z-index以外でもスタックコンテキストを導入することが認められており、実際にz-index以外でもスタックコンテキストを生成するプロパティは既に存在します。

例えば、CSS3で加えられた透明度を操作するopacityはスタックコンテキストを生成します。つまり、z-indexを指定しなくとも、opacityで1未満を指定（基準値の 1 ではスタックコンテキストが出来ない）した場合、その要素をスタックレベル0としたスタックコンテキストが生成されてしまうので注意が必要です。

どちらも色の薄い方に z-index: -1; を指定しています。
実際のコードとサンプル

z-index以外の重なり

先ほどのリストで示した通りなのですが、一応サンプルを用意しました。

span → float → p の順に記述。pのみ color: white;
実際のコードとサンプル

p よりも span floatさせた要素の方が先に記述されていますが、リストの通り、spanやfloatさせた要素の背景の方が後に記述された p の背景より上層にきています。
ここで難しいことは、位置（position）指定されていない要素の階層はそれ自体（主に背景とボーダー）のものであり、子孫要素や内部のテキスト等はまた異なるレイヤーに置かれるます。よって、上記の図でもわかるとおり、背景はリストに従い span のものが上層にきていますが、内部のテキストは後から記述された p の内部のものが上層にきています。

正直、この辺の細かい正確なレイヤーは勧告と付録読んでもイマイチ完璧に把握できないところがあります。自分、馬鹿なのかなぁ

このように、後から書いたものだからといって、より上層になるとは限らないのです。（尤も、重なりを意識するのは大抵ブロックレベルの要素なので、ここまで意識する必要があるか微妙ですが。）

おわりに

擬似要素のz-indexの効き方に疑問を覚えて調べていたらこんなになってしまいました。z-indexに関しては「使用頻度が低いために曖昧にしか覚えていなかった結果、ちょっとハマる」なんていうことが無きにしもあらずなのではないかと思います。この際、覚えておいて損はないのではないでしょうか。

ちなみに、ここまで偉そうに解説しましたが、勧告を読んで私がこう理解したというもので、実は違うなんてことが無きにしもあらず…

ちなみに、IEでは最初に生成しなくても効いている気がします。

::first-letter が最初から生成されてないと :hover::first-letter 効かないっぽい？

— xl1blueさん (@xl1blue) 9月 2, 2012

使いたい場合は、::first-letter{ color:inherit; }あたりで見た目は変わらないものの生成だけは最初にしておく感じにすればいいんじゃないでしょうか。