Hatena::Groupweb

vantguarde

8.26

linear-gradient()とかradial-gradient()のあとにはbackground-colorも別に書いとこう

| 01:33

Windows Phoneが発売されましたが、「スマートフォン」と一括りにされて既存のスマートフォン用サイトに飛ばされたりしたとき、問題になるものがちらほら出てくるんじゃないかと思うので、ちょっと書いておこうかなあと。

タイトルで説明できてるんで冗長ではあるんですが、まあこういうことを言いたいのです。

.nanka {
  color: white;
  background: -webkit-gradient(linear, left top, left bottom, from(darkgray), to(gray));
}

これで完結してるCSSが結構多いんですよね。-moz-とかが書かれてることもありますが、それは置いといて。

これだと、WebKit以外だとbackgroundが無視されちゃうんでWebKit以外で文字が見えなくなります。*1

で、ただ背景色を書けだと、なぜかこう書いてしまう場合もあるらしく……

.nanka {
  color: white;
  background: -webkit-gradient(linear, left top, left bottom, from(darkgray), to(gray)) gray;
}

backgroundにしちゃってるケースです。これも当然WebKit以外だと悲しいことになります。なのでbackgroundに含めないで(含めてもいいですが)、backgroundのあとにbackground-colorで指定します。

.nanka {
  color: white;
  background: -webkit-gradient(linear, left top, left bottom, from(darkgray), to(gray));
  background-color: gray;
}

背景色には、文字色とコントラストのとれるものであれば何でもいいかなと。基本的にはグラデーション内の色が楽だとは思います。

というお話でした!

あ、-moz-, -ms-, -o-も書いておけばそうしなくてもいいってわけじゃないです。ブラウザ売ってるわけじゃねぇんだから「このブラウザで見てください」はありえんよ。っていう話です。*2

*1:継承した背景色が白に近い場合の話ですが、かなり頻発するかなと。

*2:元発言の文脈は違いますが。参考: http://togetter.com/li/178609

6.14

-webkit-text-size-adjustがiOS以外でも効いてしまうらしい

| 23:27

Androidの方がWebKitのアクセシビリティ関連機能が動かないサイトを調査してたら、WebKitの-webkit-text-size-adjustの挙動にぶちあたったらしいです。

それでアクセシビリティのためにこのズーム機能を(AndroidのWebKitで)無効にしようと検討していて、それにあたってそもそもこれ何よっていうおはなしです。

そのスレッドでAppleのSimon Fraser(CSS WGにいますね)が関連するWebKitのバグを教えてます。

どうやら-webkit-text-size-adjustはデスクトップのSafariにも効いてしまうようで(しかも意図しない挙動をとる)…知らなかった…

で、バグを読んでくと、もともとこのプロパティは-apple-text-size-adjustとして追加され、それが-webkit-に変化して今まで生きているようです。*1

で、デスクトップに影響するのはアレなので、iOSだけに有効になるパッチが出されたんですが、Safari RSSで使われているらしく残念なことに。ENABLEマクロでどうにかできないのかというコメントがGoogleの方からついてますが、ならないんですかねえ。

iOSでもこれを便利に使ってる人っていないように感じるんですけどねえ。

*1:接頭辞は以前、-khtml--apple--webkit-のエイリアスにする変更が行われていたように記憶してるので、そこで変更になったのかなと。

1.6

gradually improved

| 06:37

WebKitがCSS Image ValuesのグラデーションをサポートしたってのをPeter Beverlooのエントリ経由で知りました(さっすが!)。

パッチや該当するbugを見るに、repeating gradientsはこれかららしいです。

グラデーションはもともとWebKitが拡張として追加して、その後Geckoが違う構文で追加して、Image ValuesでGeckoに近い構文になるもあんまり進んでなかったっていう状態だったんですが、re:gradients, and won't change again. I PROMISE.との報告を受け実装に動いたようです。

-webkit-gradientはたぶんなくならないでしょうけど、新しいものに移行していったほうがよさそうですねえ。prefixがすぐ外れるとは思わないですが。

12.14

selector { property: value

| 20:15

もともとコードをがっつり書くようなひとじゃないので、書いたものがついルーズすぎるコードになっちゃいまして。

そんなルーズなコードから見つけたWebKitのバグを。

<!DOCTYPE html>
<style>body { background: red; background: green</style>

これ、greenになるはずなんですよねえ。

ただこっちは動きます。

<!DOCTYPE html>
<style>body { background: red; background: green </style>

style要素最後のスペースに注目。スペースひとつで変わるので、CSSパーサに問題があるんでしょうか。

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があるので、そこでちょっと話されるようです。

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

Contact: @vant / lepetitcroissant@gmail.com.