Hatena::Groupweb

vantguarde

6.8

CSS ― CSS 2.1, CSS3 Color, Selectors Lv. 3

| 03:36

はい。

W3C, the standards body for the suite of technologies that together provide an Open Web Platform for application development, today announced new levels of support for Cascading Style Sheets (CSS), the language for adding style to Web content. W3C released an update to the core CSS standard (2.1) to reflect the current state of support for CSS features, and to serve as the stable foundation for future extensions.

CSS 2.1とCSS3 Colorが勧告になりました。

今更といえばそうかもしれませんが、デファクト標準としては極めて理想的とも言えるんじゃないでしょうか。もっとも、デファクト標準ですから、interoperabilityを損なうものはCSS3に持ち越して未定義にするなど結構苦しい部分はあったりします。HTML5も現在のW3C Processが維持されるのであれば、勧告前には似たようなことになるのかなあと。

さて、プレスリリースを読んでいて気づいたのが、Selectorsが勧告されてません。もしかするとISSUE-88が絡んでるのかもですが、さっぱり分かりません。あ、これの詳細についてはAnneのエントリをどうぞ。

なんだろう。まあ、いいか。おめでとうございます。

12.29

)

| 15:40

おおおおお。

ヘッダが主張しすぎな感じとかがちょっと飽きてきたので、ちょっとだけリニューアルした。

物事をシンプルにするます

かわいい!いつも好きです(?

さてさて。

FirefoxやOperaではちょっと変な感じになるので、-webkit-border-radiusのみにした。

たぶんFirefox (3.6)とOperaがパーセンテージの指定にちゃんと対応してないからでしょうね。ただ、別の理由でWebKitもそのうち「変な感じ」になるかもしれません。

というのもこれ、WebKitのborder-radiusの実装がちゃんとしてないから「変じゃない」んですよね。B&Bモジュールにはこういう定義があります。

when two adjoining borders are of different thicknesses the corner will show a smooth transition between the thicker and thinner borders.

Corner Shaping

隣接するborderのborder-widthが異なる場合、それがスムーズに繋がるように描画されるってことになります。Fig. 7, 8を見るとわかりやすいですかね。

というわけで

elem {
  border-bottom: 2px solid black;
  border-radius: 50%;
}

こう書くと、横に向かうに従い細くなるように描画されるはずです(横のborder-widthが0なので)。

ところがWebKitはここが全然できてなくて、スムーズなtransitionもなくぶった切ってくれちゃうんですよね。IEBlogの記事でも比較されていたりします(For a solid border of variable...のところ、右がWebKit)。

Firefox 4やIE9は見たところちゃんとしてる(細い月のようになる)ので、WebKitもこれにマッチすると、ちょっと見た目がよろしくなくなるかなあと。

いちおう、こう書いておけばFirefox 4, IE9, WebKitでだいたい同じになるはず。横に同じ太さのborderを置いて、色はtransparentに。幅広がっちゃいますが。

elem {
  border-style: none solid solid;
  border-width: 2px;
  border-color: transparent transparent black;
  border-radius: 50%;
}

ただ、角のborder-styleborder-colorのtransitionについてはIt is not defined what these transitions look like.と未定義なので、実装によっては変わるかも。なので完全ってわけではないです。たぶん大丈夫だと思いますが。

3.5

“vendor prefixes considered harmful”

| 01:00

そんなことをCSS WGのco-chairが言うってのが面白いですね。

I said it in the past and I maintain my opinion: the vendor prefixes as we manage them in CSS don't make sense.

vendor prefixes considered harmful (was: vendor prefix properties diverging from official properties)

HTML5はまだWD段階なのに、vendor prefixみたいな仕組みもなく要素や属性が使われてるけどどうよ?」といった感じでしょうか。HTML5については、そういう仕組みがHTMLにないというのが大きな理由な気がしますが、うーん。

まあそれはおいといて、いわゆる(?)「-moz-prop -webkit-prop -o-prop って書くのだるい」問題については、あまりいい状況になってないわけです。

とりあえず、vendor prefixについておさらいすることからはじめましょうか。目的は、大きく分けてふたつ。

  • CRより前の草案などを実装する際に、安定していない仕様に基づいた試験実装であることを示す
  • 独自に新しいプロパティを導入するときの、ベンダー固有識別子として利用する

後者についてはprefixをつけるのが妥当でしょうが、前者はどうでしょうか。

つけることの利点は、仕様が安定していない状態から実装できることにあるでしょう。Authors should avoid vendor-specific extensions.* とありますから、後で仕様が変更してもそれは仕方ないと言えるわけです。仕様の変更は border-radiusのサブプロパティやグラデーションなどですでに起こっているので、リスク回避として有効かなと。

しかし、ひとたび仕様が安定し実装が増えてくると、やつらはとたんに面倒なものになってしまいます。prefixは仕様がCRになると落とせるのですが、個々のプロパティではなく仕様全体のステータスに依存するので、安定度が機能毎に異なると面倒なことになるわけです。

この話、去年の5月にもでています。

「Mozillaも-webkit-propを実装すべきか」っていうところから始まるスレッドなんですが、その中で -wd-prop みたく、実験的であることを示す印に一本化するのはどうかという提案が出ています。

なるほど、こうすると書き手や互換性のテストでの手間が減ってよいかもしれません。ただ、問題もあります。

  • 仕様が変わった時の変更を知る術がない(vendor prefixでもそうですが)
  • ベンダーを超えて使われる利点はあるが、実装とリリースの時期がそれぞれ異なる

というわけで、同じ書き方でも解釈に違いが出てくる可能性があるわけです。ただ、名前が共通してしまう分「試験実装だし問題ないだろ」と言いにくくなる感じがしますね。結局のところ試験実装であろうとなかろうと、新しい機能を手間なく使いたいという要求の方が強いでしょうから。それなら、prefixそもそも要らなくなるよねっていう話にもなりますし。

結局は I think that is the real problem: we're too slow.* ってことなのかなと。仕様と実装のコントロールができていれば、大きな問題にはならないはずなので。

で、現時点で出来ることは、プロパティに関して実装状況を各ベンダーが共有して、prefixを落とすタイミングをはかるくらいでしょうか。こちらは下旬にF2Fがあるので、そこでちょっと話されるようです。

とはいえ、こういった状態になってるのも、実装と仕様の両方が進んでいることのあらわれなんですけどね。そう考えるのはポジティブ過ぎるかなあ。

2.5

State of the Browsable Web 2009: CSS Multi-column Layout

| 21:52

さてと。

昨年12月ですが、Multi-column LayoutのCRが公開されました。

「CSS3」とタイトルに入ってないのは、下位レベルがないからです。下位レベルがあるものは「CSS *** Module Level n」に、ないものはLevelを取るという命名指針が結構前に決まってたんですが、ようやくこのモジュールもそれに準じたものになりました。他のもそのうちなってくでしょう。

LCからは、カラム幅より大きな何かが float されている場合の処理が変更になり、それまではカラムを超えてちゃんとfloatがきく予定だったのですが、カラム幅でクリップされてしまうようになりました。

さて、いちばん大きかったのは、column-break が削除されて、break-before, break-after, break-inside というプロパティが替わりに導入された事でしょうか。

もともとは昨年3月のTokyo F2Fで、page-break-* との関連性について議論され、page-break-* と決定されました。プロパティを再利用し、カラム用の値は新しく定義して対処しようという話です。

Resolved: page-break-before, page-break-after: column to force column breaks, other values apply to column breaking as well as pages.

Minutes and Resolutions Tokyo F2F Thurs: Page-breaking, GCPM, Image-resolution, Multicol

It should also be noted that using the page-* propoerties to set preferences on columns is not ideal. However, introducing three new properties to describe column behavior seems excessive.

*

カラムのためだけにプロパティが増えるのは好ましくないという判断でしたが、反論が出たりや問題点が明らかになったりしました。

で、3つの提案が。

  • page-break-* を維持して、足りない値を追加する。
  • column-break-* を復活させ、page-break-* との関係について定義する。また、break-* という、どちらの値をもセットする新しいプロパティをショートハンドとして用意する。
  • break-*page-break-* のエイリアスとして定義する。

で、2つ目のが採用されました。

Resolved: Add three new column-breaking properties and shorthand to combine them with page-break properties per Melinda's email item 2.

Minutes and Resolutions 2009-04-29

しかーし。その後フランスで行われたF2Fでまたもやひっくりかえります。

Resolved: Introduce page-break-* properties as syntactic sugar for new break-*. Rationale: Adding column-breaking controls to page-break-* doesn't make much sense, but the WG wants to avoid introducing a second set of properties.

Minutes and Resolutions June 2009 F2F

page-break-*にカラム系の値が入るのはなんかアレなんだけど、全く別のセットとして定義するのは実装側に好まれなかったというのが理由です。

というわけで、3つ目っぽい決定がされました。CRを見てみましょうか。

Three new properties are introduced to allow column breaks to be described in the same properties as page breaks: ‘break-before’, ‘break-after’, and ‘break-inside’. These properties take the same values as ‘page-break-before’, ‘page-break-after’, and ‘page-break-inside[CSS21]. In addition, some new keyword values are added.

5. Column breaks

In addition, some new keyword values are added. とあるので、1つ目も含んだ感じですね。

さて、いつ実装されますかねえ。

12.17

State of the Browsable Web 2009: CSS3 Backgrounds & Borders

| 01:06

昨年ぐらいから活発になってきた印象を受けるBackgrounds & Bordersですが、CRが公開されました。

追いかけてなかったので、さっぱりです。

というわけで調べたりしました。時間かかった…

box-shadow のドロップ

大きなものからいきましょう。「えっ」という変更ですが、そうなっちゃいました。

Resolved: Drop box-shadow from CSS Backgrounds and Borders Level 3: work on box-shadow outside the module for the time being, possibly re-merge with draft later. Rationale: drop-shadows seem to need a lot more discussion, but the rest of the draft is ready to move on.

Minutes and Resolutions 2009-09-30

とはいえ、10月のLC時点で無くなっていたんですけどね。

なんでドロップされたかですが、他の機能は安定してきてるけど、ドロップシャドウはまだいろいろ話す事があるのでとりあえず別に作業するというそんな理由になります。再統合の可能性も高そうな書き方をしているので

その「いろいろ」ですが、ひとつはborder-imageとの関わりになります。2月のTeleconで、box-shadowborder-imageで上書きされないという仕様が決まったんですが、Brad Kemperがそれに反対したんですね。

Bradは前々からデザイナーという立場から特にこのモジュールに対してコミットしてた人で、その経緯もあってかその後Invited ExpertとしてCSS WGのメンバーになり、またこの仕様のEditorになりました。すごいですねー

話は戻って、David Hyattがborder-imageをマスクにしてはどうかという提案をして、議論が発展していきます。

Rather than suppressing the shadow, what about using the border-image as a mask when deciding how to draw the shadow? In theory it should be possible to intelligently draw a more complex shadow for a border-image object.

Re: Minutes and Resolutions 2009-02-04: box-shadow and border-image

とはいえ、これは「ドロップシャドウ」ではないところが難しいところなんですよね。

議論は続きますが結論が出ない状態が続きます。別に border-shadow という新しいプロパティを設けてはどうかという提案があったりもしました。

とまあ、そんな経緯でとりあえずドロップと。消極的な感じはするんですが、確かに根深い問題です。

現在はBradによるドロップシャドウの提案に話題が移ってますが、このモジュールのスコープ外のような気がするので省略。

ドロップシャドウはSVGのフィルタをCSSから使えるようにするという話との絡みもあるので、興味がわいたらもうちょっと調べる事にします。

ぜえぜえ。

borderborder-image

border というショートハンドがありますが、border-image との関わりが定義されていませんでした。こちらは border から border-image を指定できるように拡張することを行わないことと、ただ border によって border-image がリセットされることが決定されました。

後者には注意しないといけないかもですね。

border-image のサブプロパティ

fantasaiがCSS3.infoでとったサーベイ結果をふまえて、border-image のサブプロパティが導入されました。border-image はショートハンドになります。

追加されたプロパティはborder-image-source, border-image-slice, border-image-width, border-image-outset, border-image-repeat の5つ。結構多い事とそれらの関連を説明する必要があったためか、LCからは独立したセクションになりました。

ちょっと調べてみましたが、サブプロパティの実装はまだ始まっていないようです。あ、それと、border-image の使い方が 「border-image を利用したボックスデザイン」にてとても分かり易くまとめられています。

とまあ、全然ステータスという感じではないですが、気になったものをまとめてみました。Background系にまったく触れてないというね。

Contact: @vant / lepetitcroissant@gmail.com.