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

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のエントリをどうぞ。

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

5.26

Browsers ― Mango IE9, UI improvements in Firefox

| 01:12

Mango IE9

Quirksモードやめたい!(自動でキーワードに設定できるんですが手動でリンクしました)

それはさておきMangoが発表されましたね。楽しみです。

日本語周りとかはすでに紹介されてた記事があったのでまあいいかなと思って、IE9をちょっと見てみました。見てみましたといってもほんとにこれIE9なのかってのを確かめた程度ですけど。

で、Windows Phone Emulatorからnavigator.userAgentを調べたらこんな感じ。

デフォルト
Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0; Microsoft; XDeviceEmulator)

7.1なのに7.5。ぎりぎりまで検討されてたんですかね。でも、んー?

それで、X-UA-Compatibleを入れていろいろ試したら、もうひとつモードがありました。

IE=7以下
Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.5; Trident/3.1; IEMobile/7.0; Microsoft; XDeviceEmulator)

IE7モードがあるようです。現行のOSに搭載されているIEがIE7ベースというのは聞いたことがあるので、まあそれとの互換性のためなのかなと。このバージョンに依存するコンテンツってどれだけあるんでしょうかね……

XDeviceEmulatorはエミュレータ固有でしょうから、この部分が何かに置きかわるんですかね。あー、調べるの忘れちゃった……

で、これで済むかとおもいきや、SettingsからDesktop versionなるものが選べました。その設定に応じてUA Stringも変わります。

デフォルト
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; XBLWP7; ZuneWP7)

IE=7以下
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/3.1; XBLWP7; ZuneWP7)

デスクトップ版と似てますね。こっちも実際に送られるUAとはまた違いそうですが。

2011-09-06追記: 8/29にIntroducing the IE9 on Windows Phone “Mango” User Agent Stringなんて記事がWinodows Phone Devloper Blogに投稿されてます。

FirefoxのUI

Firefox 5がBetaになったのでアップデートしたんですけど、いいですね。きびびとしてます。

CSS Animationsは永遠にAppleの独自拡張の域をでないと思ってたので、Geckoで実装されたのは結構おどろきでした。

ちまちまとUIの方も改良されているのでちょっと紹介。

たとえばFx5はChromeみたく、タブを閉じてもマウスを動かすまではタブの大きさが変化しないようになります。

Fxはtab overflow(でいいんだっけ)があるのでどうなんだろうと思ったんですが、それもちゃんと考慮してくれてるようです。素敵。

×ボタンを2回クリックしないと閉じられないことがあるのですが、再現条件がよく分からないんですよね。直ってくれるかしら。

あと期待しているのが、いま開発中らしいタブが移動するときのアニメーション。SafariやChromeみたくするっするっと動くようになるらしいです。

モックアップがFxのみなのは、JavaScript 1.8が使われてるからなんですかね。一番早くてFx7になるのかな。楽しみです。

追記:Aurora 8でするするします。

Fx5よりは、matchMedia()やらelement.dataset, CSS3のtext-decorationが入ってきそうなFx6の方が楽しみだったり。リリース方針が変わって、どの機能がいつ来るか分かりやすくなったので、そんなに首を伸ばさなくてもよくなったのが素敵ですね。

5.13

Android smartphone ― qHD display

| 04:21

来週はdocomoとauの発表会らしく、いろんなところでカタログのリークやら、先行発表やらがあります。

OTAもしくはMacでアップデートできるようになってくれたら買いたいんですよね。I/Oで結構なベンダーがアップデートの保証はしてくれましたけど、OTAとかMac対応については分かりませんし……

それはさておき、気になっているのがqHDの端末が最近出てきていること。qHDとはHDの1/4という解像度、つまり540×960になります。HTCのPyramidとか、夏モデルではシャープの端末がqHDみたいです。

はい、540なんです。

これまでAndroidスマートフォンの主流は横が480で、縦が800もしくは854でした。で、これら標準ブラウザーって、幅が320のiPhone 3やそれに依存したサイトとの互換性をとるために、1CSSピクセルを1.5デバイスピクセルで描画しています。(iPhone 4も1CSSピクセルを2デバイスピクセルで描画しています。)window.devicePixelRatioなんてプロパティやdevice-pixel-ratioなんてmedia featureを拡張してるブラウザもあります。

しかし540です。480であれば480/320=1.5でまだきりよく割れていたのですが、540/320=1.6875になっちゃいます。なので、1CSSピクセルが1.7デバイスピクセルくらいで描画されることになりそうです。1.5では丸めのせいか、描画が2pxや1pxになってしまう問題があるようですが、1.7だとどうなんでしょうかね。

でもこれは、端末がhdpiグループに属してればの話で、実際どうなのかがわかりません。Androidのドキュメンテーションを読むと、たぶんhdpiだと思うんですが。

hdpiでも、それはそれで問題がありそうです。シャープの夏モデルを例に取ると、3Dとかそれ系の端末は画面サイズが4.2インチで、もう片方のケータイみたいな端末は3.7インチです。画面サイズが違っても解像度は同じ、というわけでピクセル密度が違うんです。前者のは260くらいですが、後者は300に近いです。IS05も290くらいだった記憶があるのですが、こうなるとむしろiPhoneとかIS03とか、その他xhdpiな端末に近いんですよね。

なので、これまでのhdpi(240dpi)をターゲットにしたコンテンツが、実際のピクセル密度が300dpi近い端末でどれくらい耐えられるのか(小さくなりすぎてないか)が気になりますね。綺麗ではあるんでしょうけど。

んーややこしい。ベストプラクティスどころかプラクティスさえ曖昧なのが、ややこしく作ったり考えたりする原因ではあるんですが。

qHD端末、どれくらい増えるんでしょうね。レターボックスなしでHD動画を再生できたりする利点がたぶんあるので、テレビ系のブランドを冠したAndroidスマートフォンなんかはqHDを採用してもおかしくなさそう。

Internet Explorer ― Market Share, frameborder

| 01:25

関係ないけど読んでおきたい

さてさて。

2ポイント

Microsoftが公開してるIE6 Countdownですが、これ月の始めにシェアが更新されてるんですよね。過去を遡れないのが不便ですが。

で、3月に公開された当初は、全世界のシェア(2月時点)が12.0%でした。そして先月更新の3月時点では11.6%、今月始めの更新の4月時点のシェアは11.4%となってます。

これだけだったら「ふーんちょっとずつ減ってるんだ」くらいにしか思わないんですが、奇妙なことが。各国のシェアを見ることができるんですが、日本のシェアが2月時点では10.3%、3月は10.1%と変化があまりなかったのに、先月4月時点のシェアが8.0%と2ポイント以上下がっているという。

地震の影響なのかと思いもしたんですが、それであれば3月から影響でてもおかしくないわけで、よく分かりません。リースの絡みで4月からリプレイスが始まっているとかも考えられますが、そういうのも4月に一斉に変わるのか謎ですし。なんだろう。

ひとつ考えられるのは、データの取得に変更があったこと。このデータはNet Applicationsのものらしいんですが、ときたま計測方法とかを変えてシェアの推移が変化します。今年2月にCIAが提供する国別インターネットユーザーのデータが更新されたのでそれを反映するって変更があったのですが、そしたら中国の影響が大きくなって、結果としてIE6の減少が鈍化しています。

ただ、単に何かがおかしいってだけかもしれません。台湾は2月に10.7%、3月は8.7%、先月は9.4%と、ちょっとよく分からない増減(幅も他の国の変化とくらべて大きい)をしていますし。

まあ、8%であれ10%であれどちらにせよ大きいというのは変わらないですねえ。とはいえ、残りは90%以上あるわけで、それらが何であるかも、そしてこれがどう動くかも同じくらい見ないとなあと。

週末

そうそう、Statcounterのシェアだと日本でもなかなかにIEが低くて面白いです。さらに面白いのが、日別シェアをプロットしたもの。週末になるとIE6のシェアが下がって、他のブラウザやIE8がすこし上がっているという。企業のポリシーでアップデートできないというのがわかるというか。

ちなみにUSのだともっと顕著です。さすが極端な国というか。こっちはIE8も減ってますね。

iframeのframeborderとborder

ゆるい書き方ができたりbitarget=_blankは使えたりしますが、HTML5はちゃんと書くとStrict以上に厳しい言語仕様になっている気がします。

さて、ソーシャル系ボタンが増えてますけど、あれ結構iframeを使ってますよね。そしてその中にはほぼ確実にframeborder属性が書かれています。何で書かれているかというと、IEでiframeの枠がborderプロパティからいじれなかったからです。

ただHTML5ではframeborderはやっぱりnon-conformingです。なのでHTML5+ソーシャルなページとか基本的にアウトになります。

そんなわけで「borderでいじれるようにしてよ」ってバグがIE8のころからあります。

5.5

HTML5パーサの検出

| 18:04

さて、「text/htmlでSVGが表示できた、じゃあそれはHTML5パーサを搭載してる」なんてのは怪しいもんです。IE9はHTML5 parserではありませんがインラインSVGには対応してますし。

だから、innerHTML<svg></svg>つっこんでそのnamespaceがSVGのそれかどうかを確かめるようなテストでHTML5パーサの検出を決めるのって、不十分なんですよね。HoneycombのWebKitの場合は、WebKitのバージョン的にHTML5パーサが入ってることからじゃあインラインSVG見られるだろうという想定で確かめただけなので、すべてに当てはまるわけじゃない。

とはいえ、「こういう挙動だから、これは間違いなくHTML5パーサだ」というひとつの機能って存在してないのかなと。各ブラウザがこれまで持ってたパース処理とどこかで互換性をとるように作ってるわけで、固有の挙動がありすぎると、それに依存したコンテンツに影響がでてくるので、それはそれで問題なわけです。なので、HTML5パーサを検出するには、複数のテストを組み合わせた結構長めなものになるんじゃないかなと。

そんなことを前のエントリを書きながら思っていたんですが、検索したらHenri Sivonenさんがそんなものを書いてました。しかも去年ブックマークしていたという。

ここで使われてるdetect-html5-parser.jsがそれです。やっぱり複数のテストをして判断してますね。<div<div>をつっこんでdiv<div要素になるかとか、textareastyle中の<!--の扱いとか、いろいろ面白そう。

ある機能の検出にしては大きいし、HTML5パーサをちゃんと検出する意義がそんなにないのが、Modernizrとかに入ってない理由なのかなあ。

|
Contact: @vant / lepetitcroissant@gmail.com.