Hatena::Groupweb

vantguarde

7.8

Firefoxのリリース間隔とか

| 23:55

もうAuroraは7ですか。はやいなあ。

無駄な新しもの好きなのでAurora使いたいんですけど、アイコンが好きじゃないんですよね。Firefoxのと粒度が違いすぎて違和感があるというのもあるし。うーん。

それはそうと、Auroraはもう7ですし、6もBetaが出ました。しかしFirefox 5へのアップデートはまだmoz.dev.planningで議論されてるくらい結構なおおごとになってしまったので、今後どうなるんでしょうね。

とはいえ、おおごとになりすぎた感もしなくないというか、たとえばFirefox 4.1とかそんなバージョンでFirefox 5が出てたらここまでにはならなかったのかなあと。「メジャーバージョンアップにはUIの変更があるべき」みたいなコメントもあったりしますし、バージョン番号に囚われすぎるのも困りもの。

ただ、リリース間隔が短くなるのはバージョン番号に限らず面倒なことではありそうです。さらに、Firefoxはこれまでのやり方を変更して早めているので、戸惑いは避けられない。ぼくも、Fx 3.5やFx 3.6からのアップデートがどうなるのとか、自動アップデートはとか、いまいちよく分かってないことがあります。Mozilla JapanはFAQを出していてとても好感を持てたのですが、もっとそういう説明が事前にあるとスムーズだったかなとは思います。

しかし、リリース間隔が長いと新しい機能とかが使えるまで時間がかかるし、更に速く変化してるWebに対応するには間隔を詰めるしかないとは思うのですよね。

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とかに入ってない理由なのかなあ。

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しているのかとかって話がでてますね。

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

Contact: @vant / lepetitcroissant@gmail.com.