Hatena::Groupweb

vantguarde

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-のエイリアスにする変更が行われていたように記憶してるので、そこで変更になったのかなと。

5.4

WebKit ― Honeycomb, Android

| 18:54

HoneycombのWebKit

Optimus PadとXoomをさわってきました。レスポンスは悪くないのでよいかなあと。ただやっぱり重いですね。

Honeycombのインターフェースがそんなによく分からなかったんですが、慣れたら別に問題ないかなあと。ただスマートフォン版Androidと違いが大きいような気も。

スマートフォン版Android向けのアプリやWebサイトなんかがちょっと残念な見た目になりますね。iPadもそうなるけど、過剰なiPhone/Androidスマートフォンへの「最適化」ってどうなってくのかなあと思いました。

それはともかく、さわってきた理由はWebKitのバージョンを知りたかったのです。docomoがAndroid技術者向けFAQを公開してるんですが、その中にドコモスマートフォンのブラウザのUA String一覧があるんですよ。そこによるとOptimus PadのWebKitのバージョンは534.13、なのでだいたいChrome 9くらいに相当します。

Chrome 9レベルというとなにが実装されたのかもう忘れてるんですが、HTML5 parserがChrome 7から有効になってるので、それは確かめとこうと。インラインSVGが表示できたらとりあえず対応してるだろうというてきとーな想定で、MathML and SVG in text/htmlを開いたらちゃんとSVGが表示されてました。おー!

ってかSVGに対応したんですね。

AndroidのWebKit

そういえばChromiumのportをupstreamしているのかとかって話がでてますね。

もうちょっと使ってるバージョンとか、サポートしてる機能が分かればいいんですけど……

2.3

Web Fontsのsame-origin restriction

| 03:52

そんなに明るくないんで、へーと思ったのがこのスレッド。

WOFFの仕様では、異なるoriginからのフォントはAccess-Control-Allow-Originを設定しないとダウンロードされないとかそういう制限があるんですが、OperaとWebKitではこれが実装されてません。

それでGoogleのTabが「これって実装が先行してたからまだSORが実装されてないんだよね」と聞いたところ、Maciejがこんな答えを。

It's not an accident. It has been our intent to willfully ignore this requirement.

Same Origin Restriction on WOFF fonts across WebKit

なんと、意図的だと。さらに別のメールで擬似DRMな仕組みを実装する意図はないとか、SORを要件から外すべきとかも言ってます。Chromeが実装するなら勝手だけど、オプションをつけて無効に出来るようにしてほしいとも。強いですね。

あとはCORSを使うことの疑問なども話されてますね。

利用者としては制限が緩いほうが楽なわけでいいなとも思うんですが、WebKit依存なWeb fontsが増えてしまうのは嫌だなあと。

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.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.と未定義なので、実装によっては変わるかも。なので完全ってわけではないです。たぶん大丈夫だと思いますが。

Contact: @vant / lepetitcroissant@gmail.com.