Firefox – HTML5Experts.jp https://html5experts.jp 日本に、もっとエキスパートを。 Sat, 07 Jul 2018 03:14:05 +0000 ja hourly 1 https://wordpress.org/?v=4.7.19 Mozilla JapanはなぜWebDINOに？瀧田佐登子さんに聞くMozilla・オープンソースコミュニティ、そしてWebの未来 /shumpei-shiraishi/23984/ Tue, 08 Aug 2017 01:00:24 +0000 /?p=23984

編集長の白石です。

Web技術者であれば一度はその名を耳にしたことがあるであろうMozilla Japanが「WebDINO」と名前を変えた（プレスリリースへのリンク）ことを受け、WebDINOの代表である瀧田 佐登子さんにいろいろと話を伺ってきました。

瀧田さんはWikipediaにも紹介ページがあるように、日本のWebシーンを裏で支え続けていた立役者。90年代の第一次ブラウザ戦争時代にはNetscapeの開発者として活躍し、その後Mozilla Japanを設立して、Mozillaコミュニティを日本に根付かせた方でもあります。

本記事では、WebDINOへの名称変更の裏側のみならず、Netscape時代のエピソードやオープンソースコミュニティへのこだわり、そして今後のWebのビジョンまでお聞きしてきました。 読み応えのある対談になったかと思います。お楽しみください〜！


■瀧田 佐登子さんのプロフィール
国内大手IT企業で UNIX・インターネット事業に従事した後、1996年より米国 Netscapeの開発現場でブラウザの国際化・日本語化を担当。Netscape日本法人撤退後も、米国本社所属のプロダクトマネージャとして国内の金融関連サポートおよびプロモーション業務を担う傍ら、Webブラウザ技術のエバンジェリストとして国内でのコミュニティ活動を行う。2004年、米国Mozilla Foundation の設立を機に、同財団の公式支部であるMozilla Japanを設立。代表理事としてMozilla製品・技術の普及活動、Web標準技術やオープンソースの推進、Webの新たな可能性の探求や人材育成などに取り組む。
2017年7月に、Mozilla Japanを一般社団法人WebDINO Japanへと社名変更。現在は、Webとオープンを軸にした、産官学・コミュニティをつなぐ非営利組織として、テクノロジーの普及とイノベーション拡大を目指す活動を行う。
2007年より慶應義塾大学非常勤講師。2009年より中央大学大学院 理工学研究科 兼任講師。日経ウーマン・オブ・ザ・イヤー 2009 リーダー部門受賞。2009年度日本OSS貢献者賞受賞。第9回北東アジアOSS推進フォーラム特別貢献者賞受賞。

「Netscapeのオープンソース化」という事件の舞台裏

白石 こんにちは。瀧田さんにはずっとお会いしたかったので、お会いできて大変光栄です。

瀧田 こちらこそ。

白石 今回は、Mozilla JapanがWebDINOに名称変更したということで、実際のところを伺いに来ました。いろんな憶測も飛んでいる中で、いろいろと率直にお話を伺えればと思います。

瀧田 はい、ぜひ。なんでもお聞きください。

白石 瀧田さんはNetscape社にいらっしゃったんですよね。

瀧田 はい。元々は、日本企業でUNIXのエンジニアをしていたのですが、勤めていた会社がこれからはインターネット事業だ！ということで米国に視察に行ったんです。

そこでブラウザというものに初めて出会ったのですが、その頃のソフトウェアって当然のようにアメリカ中心で、国際化（Internationalization） のことなんかちっとも考えられていない。 インターネットってグローバルなものなのに、日本語対応とかが全然必要だとも思われていなくって。

「そんなんでインターネットを語るなよ」みたいな気持ちもあって(笑)、フィードバックを繰り返していたら、逆にNetscapeから「入社しないか」というオファーがあったんです。

その時は「Web」という言葉も一般に認知されていないような時代でしたが、「Webは爆発的に普及するな」という予感もあったので、そのオファーを受けて入社しました。それが1996年頃ですね。

白石 その当時は第一次ブラウザ戦争と呼ばれる、Internet Explorerとの競争も激しかった時期ですよね。

瀧田 そうですね。あの時はブラウザ間の互換性も低く、多くの批判もありました。ただ、今考えると、あの激しい競争があったからこそ、あれだけのスピードで技術が進歩したんだとも思っています。

白石 その後、1998年にNetscapeのソースコードが公開されるという大事件がありましたね。その時の様子はどんな感じだったんですか？

瀧田 あれは実は、当時現場で働いていた私たちにとっても突然の出来事だったんです。社内でもごく一部の人間にしか知らされていませんでした。ある時カフェテリアに集まるように言われたので行ってみると、ソースコードをコピーした紙が高く積んであって、それを撒き散らし始めたんです。そうして、全社員に対してオープンソース化の件が発表されました。ものすごくびっくりしましたね(笑)。

白石 それは面白い(笑)。

瀧田 この時公開されたソースコードは公開用に準備されていたものでした。というのも、Netscapeには、サードパーティー製のコードもたくさん含まれていたのですが、さすがにそれを一緒に公開するわけにはいかない。なので、そうした部分が取り除かれたものが用意されたのですが、コードが歯抜け状態だとちゃんと動かないわけです。ダウンロードしたユーザーからは多くの不満が寄せられました。

白石 そんなこともあったんですね！Netscapeのコード公開が、「オープンソース」という単語と文化の誕生に大きく寄与した…なんて知識しかないものですから、裏にそんな苦労があったとは知りませんでした。

瀧田 大変でしたよー！そもそも公開する前提なんかで書いてないコードでしたから、Netscape Communicator 4 当時はコードもかなり汚かったんじゃないかな。使ってない関数がそのまま残っていて、誤って呼び出しちゃうなんてバグもざらにあったし。そんなコードを世の中に晒すのは、はっきり言って恥ずかしかったですね(笑)。

白石 なるほど。ただ、今だからお聞きしたいのですが、Netscapeのオープンソース化は、IEに対して負けを認めての半ばヤケクソだったのか、それともシェアを奪還するための「勝とう」という動機からのものだったのか、どちらだったのでしょう？

瀧田 当時のNetscapeは独立した営利企業ですし、やはり勝つための行動だったとは思います。

ただ同時に、コードをオープンにすることが、多くの不確実性を呼び込むということもわかっていたとは思います。 あとは、社内のエンジニアだけでは得られない社外の多くの人の叡智に賭ける（そしてシェアを奪還する）という思いも大きかったのではないでしょうか。

Mozilla Japanの立ち上げ

白石 98年のオープンソース化から、瀧田さんが2004年にMozilla Japanを立ち上げるまでの経緯はどんなものだったのでしょうか？

瀧田 NetscapeのAOLによる買収などを経て2001年には日本法人も撤退し、一時はもうブラウザをやめようかと思った時期もあります。ただ、Web標準の重要性を日本の企業に説明に行ったり、個人的にNetscapeの広報活動をしたり、オープンソースコミュニティと一緒に行うイベントなどの活動は続けていたんです。

そして、2003年にAOLが Netscapeなどのクライアント事業を完全に分離し、Mozilla Foundationが誕生したのをきっかけに、日本でコミュニティ活動をスケールさせるためには母体となる組織が必要だと感じ、Mozilla Foundationの公式アフィリエイト（支部）として、2004年にMozilla Japanを設立しました。

白石 コミュニティのためにMozilla Japanを設立した、と言っても過言ではないわけですね。

瀧田 はい、日本はもともと世界的に見ても Mozilla のコミュニティ活動が特に活発でした。当時の状況だと、非営利の法人が存在した方が、そうしたコミュニティ活動やオープンソースプロダクトの信頼性の確保につながると考えたんですね。もちろん、インターネットを健全で開かれた場所にするという Mozilla Foundation のミッションに強く共感したということもあります。

その後Firefoxがリリースされてからは、国際化はもちろんのこと、オープンソースを活用した人材育成だけでなく、Webの可能性の探求をはじめとする日本発のイノベーションを世界に伝えたいと思って活動していました。 やはり、日本人が持つこだわりや繊細さは、世界に通用するものだと思っていますから。

Mozilla Japan設立から13年経ちますが、いまだにそうした想いは変わらないですね。

Mozilla JapanはなぜWebDINOに？

白石 ではその13年後である現在、瀧田さんはMozilla JapanをWebDINOに名称変更されました。WebDINOという名称には、どういう意味が込められているんですか？

瀧田 Webは私たちにとって欠かせないものです。そしてDINOはWebに対して私たちが重視してきた、そしてこれからも重視する価値観を表しています。

DはDiversity (多様性)。
Iは私たちがずっと注力してきたInternationalization (国際化)ですが、人によってInternetだったり、Innovationだったりしてもいいと思っています。
NはNeutrality (中立性)。
OはOpenness (公開性)です。

この4つの要素をつなげたらDINOになったわけです。

白石 なるほど、様々な意味と想いが込められた名前なのですね。WebDINOに名前を変えるまでに、どういう経緯があったのでしょう？

瀧田 昨年末、Mozilla Japanの今後について深く考える機会がありました。

まずMozillaという組織についてお話しますと、最初にできた母体であるMozilla Foundationとその後2005年に設立されたMozilla Corporationから構成されています。 非営利法人であるMozilla Foundationが、営利企業であるMozilla Corporationを子会社として所有しているという形になっています。

Firefoxは、検索エンジンへの窓口として収入を得ていますが、その収入が非常に大きくなってきたことでNPOであるFoundationで扱える範囲を超えるため、財団の下に営利企業を作って運営するという形を取っているんですね。

白石 営利企業が非営利団体の子会社、って面白い構図ですね。知りませんでした。

瀧田 Mozilla Japanは、Mozillaの中ではちょっと特殊な立ち位置だったのです。Mozilla Corporation ができる前にMozilla Foundationの公式支部としてできた組織で、日本の独立した法人ですから。そういう特殊な立ち位置のまま13年経過した。

しかし今は、グローバルに向けた業務はMozilla Corporation に所属するスタッフが行うことになっているので、特定の地域に向けてのみ活動する組織というのは、Mozillaの中では認められていないんです。そこでこの状況をどう整理するかという時期に来て、組織としてどうあるべきかをあらためて考えた時、私たちがしたかったこと、してきたことを見直すきっかけになりました。

企業体としてのMozilla Corporationは、当然ながらプロダクトにフォーカスしています。 組織としてどうあるべきかをあらためて考えた時、私たちがしたかったこと、してきたことって、プロダクトを通じてMozillaの理念を伝えることもそうですが、日本の状況に寄り添ったMozillaの理念を軸にしたチャレンジングな活動だったはず。

だから、私には、Mozillaプロダクトのマーケティングだけを行っていくという選択肢はあり得なかったのです。 というのも、私たちはMozillaのユーザーはもちろん、すべてのWeb、インターネットを使う人たちのために何をすべきかを考えたいと思っていたので。

なので、組織体制的にMozilla Japanをどういう位置づけにするべきかという選択の中で、Mozilla Foundationの公式支部という立場を離れ、外部組織として連携を図っていくことにしたというわけです。

白石 元々ががミッションやコミュニティ、オープンソーススケールのために作ったのだから、プロダクトのマーケティングのみを行う組織には甘んじたくなかったと。

瀧田 というより、もともとAOLから離れて100％NPOとしてコミュニティ主導に変わり、Mozilla Foundationができた時に賛同して作った組織なので、その頃からの志は変えたくないというか。例えばMozilla Europeなんかは、Mozilla Corporationが設立された時点で、その傘下に入りました。Mozilla Japanにも、当時そういう選択肢はあったのですが、そうしなかったという経緯もある。

そういう歴史も踏まえつつ、これから5年10年先を見据えて「Mozilla Japanはどうすべきか」と考えているうち、自然と「Webはどうあるべきか」を考えていたのです。それに気づいた時、Mozilla組織内という立場にとらわれず、逆にもっと大きな視野でWebを考える立場として活動する方がフィットするのだと判断しました。

白石 それは大きな決断ですね。今後、Mozillaとの関わりはどうなっていくのでしょう？

瀧田 もともと特殊な立場だったので、当面はそれほど大きな変化はないですね。Mozillaのプロダクトマーケティングだけをやってきたわけではないのでスタンスも変わりませんし、引き続きMozilla Foundationの活動には協力していくことになっているので。 活動資金という面から言うと、これまではMozilla Corporationからマーケティング活動に対して予算を割り当てられていましたが、今後は外部組織という立場から、Mozilla Foundationにプロジェクトベースで相談していくことになります。

白石 なるほど、運営面では当面大きな変化はないと。ただ、その先もサステナブル（持続可能）な活動が可能なのでしょうか？

瀧田 Mozillaのマーケティング以外に行ってきた様々な事業も引き続き行いますし、今後も色々と構想しています。チャレンジであることは認めます。しかし実は数年前から、ブラウザという枠を出たい、もっと外からWebを眺めたいと思って活動していたんです。

現在、技術という面ではWebは多少停滞しているのでは、という思いがあります。だからこそ、Webをブラウザという枠の外にどんどん広げたいと思っています。IoT/WoTの活動や、CHIRIMEN OPEN HARDWARE のコミュニティ活動支援なども引き続き行っていきたいと思っています。そういうチャレンジに正面から向き合えることは、正直ワクワクしていますね。

オープンソースコミュニティとしてのMozilla、企業としてのMozilla

白石 ところで、Mozilla JapanがWebDINOに変わったように、Mozillaという組織やコミュニティ自体にも、何がしかの変化が起きているのでしょうか。

瀧田 Mozillaに限ったことではありませんが、企業体が大きくなったことで、企業体とコミュニティのバランスが難しいところに来ているとは感じています。

Mozilla Corporation内で給与をもらってエンジニアリングをしている人もいれば、コミュニティには純粋にボランタリーな人もたくさんいるわけです。そうした多様な開発者と、分け隔てなく接していけるかどうか。難しくも繊細な問題です。

白石 例えば、Mozillaが開発方針や優先順位を定めたとしても、善意や関心で関わっているコミュニティの人々は、Mozillaのリードに従う義務はないはずです。そこのバランスをどう取って、開発を進めているのかは、ずっと誰かに聞いてみたいと思っていました。

瀧田 Mozilla Corporationは、MozillaやFirefoxというブランドを保持している以上、そのブランドの価値を高めていく必要があります。そこで、開発全体を管理しようという欲求が生じるのはある意味やむを得ないところです。

それが、コミュニティ的な自由とのせめぎ合いになるところなのは間違いないですね。Mozilla Japanのメンバーは、Mozillaの組織がまだ小さかった頃から関わってきたので、そうしたせめぎ合いの中でも、常に「Mozillaらしさ」を意識して行動するようにしていました。

白石 なるほど、やはりそういうせめぎ合いはあって、バランスを取って進めていたのですね。

ではもう一つ、前から疑問に思っていたことを聞かせてください。Firefoxのシェアが下降しているというデータがありますが、それについてMozillaやMozilla Japanはどう捉えていたのでしょうか。

というのも、非営利組織であり、ミッションを重視するという立場からすると、競合と言えども「Webを盛り上げる仲間」という捉え方もできるわけです。そうなると、シェアを伸ばそうという強いモチベーションは生まれにくいのではないかと想像していました。

瀧田 おっしゃる通り、何が何でもマーケットシェアを拡大していこうという貪欲さは、Mozillaには馴染みがないものだと思います。ただ個人的には、ある程度のシェアを確保しておく必要はあると感じています。

というのも、Firefoxが登場して間もないころはInternet Explorerの独占状態で、私たちが何を言っても「なぜいまさらブラウザなのか」という扱いで、誰にも相手にされないような状態でした。目標とするマーケットシェアを尋ねられた時に「25%を目指します」と答えたら、あまりに非現実的だと受け止められて、鼻で笑われたものです。

しかし、シェアが10%を超えたあたりから明らかに周りの反応が変わってきて、実際に25%に近づいたときには、私たちの言うことにみな耳を傾けてくれるようになりました。そういう経験から言うと、発信力や発言力を保っておくためにも、シェアは少なくとも10%以上はキープしておかないと、という思いがあります。いくら崇高なミッションを掲げていても、耳を傾けてもらえなければ意味がありませんから。

ただし、シェアが高いだけではだめで、そのシェアを持つことで何を伝えるかが重要だと思っています。シェアを持ったベンダーは、マーケットに対して何を貢献するのか、Webの標準の重要性だったり、Webのエコシステムだったりと、ミッションとシェアの両方があることが重要なのだと思います。

あとは、製品を提供する企業が一社では良くないという想いもあります。先程も申し上げましたが、第一次ブラウザ戦争は痛みももたらしましたが、技術の急激な進歩を後押ししました。 技術革新の健全な競争は、Webの発展のためにも必要だと思います。

白石 発言力という点で言うと、シェアの変化に伴い、W3C内でのMozillaの発言力に変化はありますか？また、WebDINOになってW3Cとの関わり方に変化はあるのでしょうか？

瀧田 国内の話で言うと、これまでもW3C/Keioさんとは、日本独自のイベントなどをいろいろとコラボレーションをさせていただいてきました。日本のWeb発展のためにも、できればそうした関係はこれからも続けていきたいと思っています。

W3CでのMozillaの発言力という点については、それほど影響は出ていないのではないでしょうか。HTML5で最も話題になっていた頃に比べると、標準化の活動が落ち着いているな、という感はありますがWeb技術はどちらかというと発展のフェーズから活用のフェーズに入ったのではないかと思います。

これからのwebはどうなるか、どうあるべきか

白石 では瀧田さんは、今後のWebはどうなるとお考えですか？

瀧田 Webは、ブラウザの枠を出なくては…という思いはありますね。

Firefox OSの開発中止が発表されたあたりでしょうか、今後のコミュニティ、Web、そしてインターネットはどうあるべきか、よく考えたんです。その時感じたのは、ブラウザという枠から出ることのできないMozillaのままではいけない、一旦外に出てWebを見直さなければいけないということです。

そうして実際に、ブラウザの枠を超えた活動を通じて、実際に触ることのできるリアルなものとWebがつながることが大事だという想いを深めました。すべてのものにURLが振られ、触れるものすべてがWebとつながっている世界。そこには、今のブラウザが想定しているようなビジュアルなUIはありません。ブラウザは空気のようにならなくてはならない。

白石 そうなった時、もはやそれを「ブラウザ」とは呼ばないでしょうね。ブラウジングじゃありませんから。

瀧田 そうです。ブラウザは、この先もずっとブラウザと呼ばれているようではダメだと思います。

白石 すごく進んだ考え方だと思います。

瀧田 はい、もしかすると私はいつも早すぎるのかもしれません。

この間部屋を片付けていたら過去の講演資料が出てきたんですが、2004年くらいの時点で、Webはコミュニケーションとアプリケーションの基盤になるということや、モバイルWebについても語っているんです。

そしてMozillaがFirefox OS、つまりモバイルを語り始めた頃には、IoTとWebについて語っていた。技術というのは10年くらいで一つの区切りがあると考えているのですが、一区切り先を語ってしまっているのかもしれないな、と思います。

ただ、そういう人もいていいのかな、とは最近思うんです。私は鉄腕アトムが好きなんですが、その世界観が多くの人に影響を与えて、実際の世界にも近づいてきていると感じています。そういう、未来に関するビジョンを示すという役割も世の中には必要なんじゃないかな…と考えています。

ちなみに、白石さんはWebの未来について、今後どうなるとお考えですか？

白石 うーん…ぼくは、瀧田さんほどビジョンめいたものは抱いていません。が、最近ぼくはコミュニティというものに改めて価値を感じているんです。

瀧田 改めて、ですか？

白石 はい。ぼくがコミュニティ（html5j）を運営していた頃って、実はコミュニティというものにそこまで価値を感じていなかったんです。感じないようにしていたというか。それは、「自分の行っている活動に価値がある」なんて思い上がりをしないよう、自分の中でブレーキをかけていたのが大きいんですが。

コミュニティって、明確に形があるわけじゃないから、とらえどころがない。資本主義的な価値観から言っても、価値はそれほど感じられない。お金が儲かるかというと、そうではありませんから。

瀧田 そうですね(笑) 。お金を儲ける道具と考えてしまうと、コミュニティってうまくいきません。

白石 そういう意識を常日頃から持ち続けることで、コミュニティというものに価値を感じるという感覚を封じてたんですね。でも、自分がコミュニティリーダーを離れて、少し離れたところからコミュニティというものを考えられるようになって、ようやく価値を実感し始めたというところなんです。

なくてはならないものというか、価値うんぬんは関係なく、人間がたくさんいる限り自然に発生するものというか。そしてそういうコミュニティを作り、運営するという点については確実にスキルや経験が問われる要素がある。

そういう点では、瀧田さんがMozilla Japanを通じてオープンソースコミュニティを支えてきたという経験は、何物にも代えがたいものなのではないか…なんて思いながら聞いていました。

瀧田 Webの価値って、結局人なんですよね。人と人がWebを通じて繋がっている、そこにこそWebやインターネットの価値があるんです。Mozillaはブラウザというプロダクトを通じて、またオープンソースコミュニティを通じて、人と人を結びつけました。そこにはきっと、テクノロジーの流行り廃りを超えた普遍的な価値があると思います。

白石 そうした価値こそが、WebDINOが体現していくものなのかもしれませんね。お忙しいところ、本日はどうもありがとうございました。大変楽しかったです。

]]> Windows Creators Update,Firefox 53,Chrome 58リリース──2017年4月のブラウザ関連ニュース /myakura/23905/ Thu, 29 Jun 2017 00:30:07 +0000 /?p=23905 連載： WEB標準化動向 (23)

4月にはFirefox 53とChrome 58がリリースされました。そして、Windows Creators Updateが一般公開され、Edgeも新しいEdgeHTML 15が搭載されたバージョンに更新されました。

また、Firefoxのリリースサイクルが変更され、新しい機能が実装されてからリリースされるまでの実装が短縮されることになりました。

Windows Creators Updateリリース、EdgeもEdgeHTML 15に更新

4月11日にWindows Creators Updateが公開され、Microsoft Edgeも更新されました。

開いているタブをよけておく機能の追加や、タブのサムネイルを表示するなど、ブラウザとしての使い勝手にも手が入りました。

レンダリングエンジンであるEdgeHTMLもバージョンが15に更新されており、新機能が追加されています。開発ガイドが公開されています。

Payment Request API、CSS Custom Propertiesなどは、Edgeのブログでも過去に取り上げられていますね。

Intersection Observerの実装はうれしいですね。これは要素とブラウザの表示領域が交差したことを検知するAPIで、画像などの遅延ロードやパララックス的な表現の実装に役立ちます。FRESH!のパフォーマンス改善手法のひとつとしても取り上げられました。

JavaScriptでは、Async Functions（async/await）の実装がうれしいです。今回Edgeがサポートしたので、主要ブラウザの最新バージョンすべてが対応しました。

目立たない機能の実装も…あるかも

Dev Guideの下に、実装されたAPIの一覧があったので、ブログなどでは取り上げられない機能のうち、気になったものをチェックしました。

  • Element.closest()、Element.matches()の実装
  • text-combine-uprightプロパティ（接頭辞なし）の実装
  • outline-offsetプロパティの実装
  • -webkit-text-strokeプロパティとサブプロパティの実装
  • translate、scale、rotateプロパティの実装

最後のtranslate、scale、rotateプロパティですが、これはCSS Transformsの変換関数だったtranslate()、scale()、rotate()をプロパティ化したものです。プロパティになったので記述の短縮になりますし、書き順で結果が変わってしまうことのあるtranslateプロパティでの指定よりも、意図した効果を実現しやすくなります。

すでにChromeで実装されており、Edgeでの実装もとてもうれしい…と書いていたのですが、手元でちょっと試したところ未知のプロパティとなってしまいました…秋の新しいバージョンに期待します。

Firefoxのリリースプロセスに変更、Auroraチャンネルが廃止

4月18日より、Firefoxのリリースサイクルが変更されました。

これまでのFirefoxは、「Nightly → Aurora → Beta → Release」と4つのチャンネルに分かれていました。このうち、Auroraチャンネルが廃止され、「Nightly → Beta → Release」と、1サイクル短くなります。これにより、新しく実装された機能が手元に届くまでの期間が、これまでより1サイクルぶん（6〜8週）短くなります。

Auroraチャンネルはこれまで、Developer Editionという名前のビルドとして提供されていました。Developer Editionというシステムは廃止されないようですが、中身はBetaチャンネルになります。Beta版とのリリースとの違いは、Developer Editionはこれまで通り異なるプロファイルが作られることなどにあります。

Auroraチャンネルの廃止によって、4月19日にAuroraチャンネルに移行予定だったFirefox 55は次のサイクルまでNightlyに留まります。Nightlyが2サイクル分続くので、Firefox 55で導入される機能の数がいつもより増えるかもしれませんね。

Firefox 53リリース

4月19日に、Firefox 53がリリースされました。

今バージョンからWindows XPとVistaのサポートがされなくなった（Firefox 52 ESRのサポートに移行）ほか、Macでは64ビット版のみになったことでアプリケーションのファイルサイズが減少しました。UIまわりでは、パーミッション関連のUIが改善されています。

また、Firefox Developers Editionのテーマだった「Compact」テーマがリリース版にも同梱されました。

スクリーンショット：FirefoxのCompact Lightテーマ

グラデーションがなくなりフラットになった。画像はLightだがDarkテーマも。

レンダリングエンジン周りでは、以下のあたらしい機能がサポートされています。

CSS Textの実装で日本語の扱いが向上

Firefox 52から部分的にサポートされていたのですが、CSS Text Level 3の「Segment Break Transformation Rules」が実装され、日本語や中国語の文字間などに改行がある際の処理が変更されました。

Webページを表示するとき、HTML中の改行は半角スペースに変換されて表示されます。

<p>Hello↵
World</p>

こういう風に、改行前後に空白がなくても、「HelloWorld」ではなく「Hello World」と表示されます。この処理、単語の区切りに空白を使う言語ではよいのですが、日本語などでは不自然な箇所で空白が入ってしまい煩わしいです。

CSS Text Level 3では、改行前後の文字を見て、それが日本語や中国語のものであれば、その改行を除去して扱うという仕様が加わりました。以下のエントリで細かくまとめられています。

この仕様の実装によって日本語内での改行が省かれるので、改行がつくる空白に依存しているコンテンツがあれば、見た目に影響がでるかと思います。

display: flow-root

displayプロパティの値にflow-rootが加わりました。floatの解除には::afterを使う、display: tableを使うなどがありましたが、ちゃんとした方法になります。

CSS Alignmnent Level 3のplace-items, place-self, place-contentがサポートされました。FlexboxやGridで使われるalign-items/align-self/align-contentとjustify-items/justify-self/justify-contentをまとめて指定するプロパティです。

caret-colorプロパティ

先月リリースされたChrome 57でサポートされた、caret-colorプロパティがFirefoxにも導入されました。3月にリリースされたChrome 57でサポートされており、そちらで簡単に取り上げています。

CSS Transitions仕様に追加されたtransitionstart, transitionrun, transitioncancelイベントがサポートされました。MozillaのBrian Birtlesさんのブログエントリで、導入の経緯も含め簡単に紹介されています。

その他

アルファチャンネルを持つWebMがサポートされました。Chromeチームがつくったデモで確認できます（だいぶ気味の悪いデモですが…）

ビデオ関連では、video要素などのplay()メソッドがPromiseを返すようになりました。

auxclickイベントが実装されました。主要なボタン以外のボタンがクリックされたときなどに発火するイベントです。ChromeもChrome 55から実装しています。

Chrome 58リリース

abbrのデフォルトスタイルが変更に

略語をマークアップするabbr要素のデフォルトスタイルが変更され、CSS3のtext-decorationプロパティを使うようになりました。以下のスタイルが、ChromeのUAスタイルシートに追加されています。

abbr[title], acronym[title] {
    text-decoration: dotted underline;
}

FirefoxもFirefox 40で変更されています。

多くはないと思いますが、使われているサイトでは、二重線になってしまうケースがあるかもしれません。

color-gamut媒体特性のサポート

メディアクエリーのcolor-gamut媒体特性がサポートされました。

color-gamutはディスプレイの色域が特定ものにマッチするかを調べる媒体特性で、Safari 10.1でサポートされています。

]]> Firefox, Chrome, SafariがCSS Gridに一斉対応ほか──2017年2月と3月のブラウザ関連ニュース /myakura/22818/ Thu, 13 Apr 2017 04:00:44 +0000 /?p=22818 連載： WEB標準化動向 (22)

2月はブラウザのリリースがなかったのですが、3月にはFirefox 52, Chrome 57, Safari 10.1がリリースされました。いくつかのブラウザに共通して大きな機能追加があったので、まずはそこから紹介します。個々のリリースについては、そのあとで取り上げます。

Firefox, Chrome, SafariがCSS Gridに一斉対応

CSS Grid LayoutがFirefox 52, Chrome 57, Safari 10.1で有効になりました。長らく試験的な実装状態が続いていたのですが、タイミングをはかったかのように一斉に使えるようになりました。

CSS Grid Layoutは、かなり強力なレイアウト用の仕様です。 ちょうど、HTML5 Experts.jpのトップページがCSS Gridの説明に都合良さそうなので、ちょっと書きながら紹介しようと思います。

スクリーンショット：HTML5 Experts.jpのトップページ

HTML5 Experts.jpのトップはグリッドレイアウトを意識した見た目になっている

HTML5 Experts.jpのトップページは、ロゴやサイドバーなどのブロックが、15pxの間隔をおいて配置されています。
ちょっと線を引いてみましょう。

スクリーンショット：HTML5 Experts.jpのトップページにグリッドの線をひいた

グリッドのガイド線を引いた。線で区切られた領域に各パーツが収まっているのがよくわかる

CSS Gridも同様に、配置する基準となる線を定義し、その線と線で区切られた領域に、コンテンツを配置します。Photoshopでガイドをひいて、その中で矩形選択をするようなかんじでしょうか。

現在のトップページをCSS Gridで書くと、このようなかんじになります。

body {
  display: grid;

  /* 縦線をひく */
  grid-template-columns: 1fr 290px 430px 290px 1fr;

  /* 横線をひく */
  grid-template-rows: 210px 60px 1fr /* 以降は割愛 */;

  /* 隙間を定義すると、隙間分の線を引かなくてよいので楽 */
  grid-gap: 15px;
}

#logo {
  /* 横の配置、2番目の線（1番目の線は左端）から3番目の線まで */
  grid-column: 2 / 3;

  /* 縦の配置、1番目の線（上端）から2番目の線まで */
  grid-row: 1 / 2;
}
...

枠だけですが、以下にコードを置いてみました。

CSS Gridは機能が強力なぶん、構文も複雑です。先程書いたのは一例で、ほかにも線に名前をつけたり、アスキーアートのような構文でグリッドのセルを定義できたりします。

ドキュメンテーションやチュートリアルのサイトもすでにあるので、それを参考にしてみましょう。

このうち、Grid Gardenは、CSS Gridの構文の一部をゲームで学べるサイトです。入門にちょうどよいかと思います。

また、Firefoxの開発者ツールには、CSS Gridインスペクタが搭載されました。グリッドの線や隙間を視覚的に確認できてとても便利です。

CSS Gridを使う場合、コンポーネントの見た目とレイアウトを、コード上ではっきり分離しないと扱いづらくなるので、マークアップやCSS設計にもいろいろ影響を与えるだろうと感じています。気が向いたら、取り上げるかもしれません。

Firefox, ChromeではWebAssemblyも有効に

こちらはFirefoxとChromeのみですが、WebAssemblyが有効になりました。

WebAssemblyについては、清水さんの連載を読んでいただくことにして、説明は割愛します。

Mozilla Hacksでも2月にWebAssemblyの特集が組まれています。JITコンパイラやアセンブリの話から始まるなど、読み物としても面白いものになっています。

この特集の他にも、asm.jsと比較しWebAssemblyが速い理由や、WebAssembly Explorerというツールの紹介もされています。

MDNにもWebAssemblyのドキュメントがまとめられており、日本語訳も有志によって進められているようです。

Firefox 52

3月7日に、Firefox 52がリリースされました。Captive portal（Wi-Fiサービスのログインページ）の検出が追加されたり、HTTPなページでパスワードを扱っている場合警告が出たり、Flash以外のNPAPIプラグイン（AcrobatやSilverlight、Javaなど）が無効にされたりと、セキュリティ周りの機能強化が目立ちます。

とはいえ、フロントエンド周りの機能強化も、先述したCSS GridとWebAssemblyサポートに加えて、以下のようなものがあります。

space-evenly

Flexboxのjustify-contentでspace-evenlyという新しい値がサポートされました。

space-aroundとなにが違うかというと、space-aroundでは連続したアイテム間では空白が左右のそれの倍になってしまうのですが、space-evenlyでは「even（均等）」と名のつく通り、空白の大きさが等しくなります。仕様書の画像がわかりやすいです。

justify-contentプロパティなどに指定する各種値のレンダリングの違いを比較した画像

space-evenlyのほうがspace-aroundよりも使われそう

CSS Color Level 4のrgb()とhsl()

CSS Color Level 4のrgb(), hsl()関数表記が実装されました。「もとからあったじゃないか」と思う方しかいないと思いますが、CSSお得意の構文変更です。

これまでのrgb()やhsl()は、それぞれの色の値をカンマで指定していました。

それが空白区切りになりました。

color: rgb(128 90 0);

また、整数値しか取れなかったのが小数も受け入れるようになりました。hsl()については、これまで数値でしか指定できなかった色相を、角度（degなど）を使って指定可能になりました。

color: rgb(111.4 128 0.0);
color: hsl(120deg 100% 30%);

そして、これまで別の関数表記だったrgba(), hsla()の機能を統合し、rgb(), hsl()からアルファを指定できるようになりました。アルファはスラッシュで区切り指定します。また、これまでは数値のみの指定でしたが、パーセンテージでも指定可能となりました。

color: rgb(128 90 0 / 50%);

構文が変わったと書きましたが、互換性という名目で古い構文も引き続き定義されるので、移行しなければならないというわけではありません。

ES2016, ES2017のサポート

JavaScriptでは、ES2016やES2017の以下の機能が実装されました。

  • Exponentiation operator（**）
  • Destructuring rest parameters
  • Async Functions（async/await）
  • Trailing commas in functions

ES2016以降の実装について、ここ数リリースでのまとめも公開されています。

現在はまだ提案であるAsync Iteratorなどの実装も進められているようです。楽しみですね。

新しいResponsive Design Modeになった開発者ツール

開発者ツールでは、Responsive Design Modeが強化され、モバイル環境のエミュレーションがより細かく行えるようになりました。

UIが変わったほか、回線環境のスロットリングと、デバイスピクセル比のカスタマイズ、デバイスのプリセットなどが追加されました。回線のスロットリングができるようになったので、回線速度のレンダリングへの影響を検証しやすくなりました。

スクリーンショット：Firefox 52の開発者ツールで登場した新しいResponsive Design Mode

Nexus 5をエミュレートすると、画面サイズやデバイスピクセル比はもちろん、UA文字列も切り替わる

ほか、Responsive Design Modeではありませんが、アニメーションパネルではイージングの視覚化も行われるようになりました。

同等の機能はChrome DevToolsにもだいぶ前からあるのですが、Escを押して現れるドロワーを開き、そこからAnimationタブを開くなど、機能への動線がよくなかったりします。

Chrome 57

Chrome 57がリリースされました。

フロントエンド周りの機能強化は、先述したCSS GridとWebAssemblyサポート以外に以下のようなものがあります。

text-decorationのサブプロパティが実装

CSS Text Level 3のtext-decorationプロパティが実装され、下線の色やスタイルを変更可能になりました。

これまではborderを使ってなんとかするハックだったので、これはうれしいですね。

/* リンクの下線を青色の点線にする */
:any-link {
  text-decoration-line: underline;
  text-decoration-style: dotted;
  text-decoration-color: slateblue;
}
/* text-decorationがショートハンドになったため、以下のようにも書ける */
:any-link {
  text-decoration: underline dotted slateblue;
}

Firefoxがだいぶ前から（接頭辞つきですが）サポートしており、続いて何年か前にSafariが、そして今回ようやくChromeでもサポートされました。

日本語では特に影響がありませんが、text-decoration-skipプロパティも一部が実装されました。text-decoration-skip: inkと指定すると、ディセンダなどのある文字（gやjなど）に下線が重なるのを防げます。

text-decoration-skip: inkの例。「HTML5 Experts.jp」という文字の「p」と「j」のディセンダを避けて下線が引かれている

フォントサイズが大きいととくにうれしい

caret-colorプロパティ

CSS UIで定義されているcaret-colorプロパティがサポートされました。キャレットの色を変更できます。

input {
  caret-color: orange;
}

ファンシーな機能ではありますが、入力欄の色が薄い色になったときにコントラスト比が保てないという問題への対応でもあります。

スクリーンショット：caret-colorにorangeを指定したinput要素

細くて見えないかも。なおキャレットの太さなどを指定するプロパティはありません

V8 5.7ではpadStart/padEndが実装、高速化も

Chromeのバージョンにあわせ、V8も5.7になりました。

新機能については、文字列の詰めを行うpadStart()とpadEnd()の導入が主でしょうか。

以前、padStart()と同様のことをするleft-padというモジュールが消えてnpmが大混乱になったので、Nodeで使えると依存を減らせて嬉しいかもしれません。

padStart(), padEnd()は、Firefox 48, Safari 10で実装済みで、EdgeでもCreators UpdateのEdge（EdgeHTML 15）でサポートされます。

他に取り上げられているのは、パフォーマンスの向上です。 正規表現周りのパフォーマンス向上については、独立したエントリが1月に公開されています。

また、V8チームはここ数バージョンほどES2015の実行速度改善に取り組んでおり、そのエントリも公開されています。

V8 5.7時点でES5と比べた実行速度差は、平均で1.86倍、中央値で1.3倍にまで減少したとのことです。

まだ差があるため「やっぱりBabelか…」という話になるかもしれません。

が、コンパイル後のES5のコードの容量が増大すれば、JavaScriptのパースなどにコストがかかり、Webアプリの最初のレンダリングまでの時間に影響します。コードの容量と実行速度、どちらも与える影響を鑑みた上で選択できるといいですね。

Safari 10.1リリース

macOS 10.12.4とiOS 10.3がリリースされ、Safari 10.1もリリースとなりました。Safari 10.1で新しく入った機能が、AppleのドキュメンテーションやWebKitのブログで紹介されています。

いくつか紹介します。

Custom Elements v1

Safari 10のShadow DOM v1サポートに引き続き、Custom Elements v1もサポートされました。

HTMLのForm Validation

ついにHTMLのForm ValidationがSafariでもフルサポートされました。

HTML5からtype=emailといった新しいinputの型や、required属性、pattern属性など、フォームの入力内容を調査する属性が導入されました。

検証項目に違反する入力内容があると、フォーム送信前にブロックされるという仕様なのですが、Safariは長らく対応していませんでした。DOMから入力内容がvalidかをチェックはできるのですが、UI上のサポートがなかったのがうれしくありません。

Safari 10.1では、他のブラウザと並んでフォーム送信時のチェック（ブロック）を行うようになったほか、好きなタイミングでフォームの検証状態を通知できるreportValidity()メソッドも一緒にサポートしました。こちらはBlinkのみで長らくサポートされていたもので、最近になりFirefoxもサポートしたものです。

広色域の色指定

新しいデバイスにはDisplay P3という色域の広いディスプレイを導入しているAppleですが、その恩恵をWebコンテンツでも受けられるべく、sRGBを基準としているCSSの色域を拡張する提案を行い、その一部を実装しました。

実装されたのは、color()関数とメディアクエリのcolor-gamut媒体特性です。

color()は、RGB各色の度合いを色域を含め指定できる新しい関数です。

color(display-p3 0 1.0 0)

このように指定すると、P3ディスプレイでの緑100%となり、sRGBでは表現できない、より濃い緑を発色できます。

]]> Firefox 51・Chrome 56リリース、Safari 10.1発表、Windows 10 Creator’s UpdateのEdge、WebKitほか──2017年1月のブラウザ関連ニュース /myakura/22272/ Tue, 07 Feb 2017 03:04:00 +0000 /?p=22272 連載： WEB標準化動向 (21)

2017年1月は新年早々いろいろ動きがありました。Firefox 51とChrome 56のリリース、Safari 10.1発表、Windows 10 Creator’s UpdateのEdge、WebKitにWebRTCとCredential Management API、Facebookとブラウザベンダー協力の話など、注目ニュースが満載です！

Firefox 51リリース

1月24日に、Firefox 51がリリースされました。

WebGL 2のサポートや、非HTTPSなページ上のパスワードフォーム入力についてのUI改善が目玉ですが、すでに知っているところだと思うので、地味なところをとりあげます。

::placeholder 疑似要素と :placeholder-shown 擬似クラスが実装されました。input 要素やtextarea 要素の placeholder 属性で指定するプレースホルダ周りのスタイルを調整するためのものです。前者はプレースホルダのテキストを、後者はプレースホルダが表示されているときの要素（input など）を表します。

SVGでは、xlink 接頭辞なしの href 属性がサポートされました。これまでSVG内で外部リソースを読み込んだりSVG内の要素を参照する際は、XLinkを使っていました。SVGがXMLのフォーマットというところに由来するのですが、名前空間の扱いの難やHTMLとの親和性などをふまえ、SVG 2.0で名前空間なしの属性が導入されました。

この名前空間なしの href 属性ですが、Internet ExplorerがSVGを初実装したIE9から使えます。SVGを実装するにあたって、検討段階だったSVG 2.0で取り入れたい機能の先行実装をさせたという話を以前SVG WGの人に聞いたことがあります。

SVGまわりでは、tabindex 属性や data- 属性に対応しました。使えなかったのに驚く方もいるかもしれませんが、これらはHTMLのグローバル属性だったので、SVGの要素では使えず、dataset プロパティなどのアクセサリーもなかったのでした。これらもSVG 2.0で導入されたものです。

Chrome 56リリース

1月25日に、Chrome 56がリリースされました。

パフォーマンスの観点から、タッチイベントハンドラの passive オプションがデフォルトで true になりました。Android版Chromeでは多くの場合、スクロールがスムーズになるとのことです。

CSSでは、position: sticky が復活しました。むかーしむかし実装されていたのですが、パフォーマンスの観点から削除されていたのでした。scroll イベントを監視しなくてもよくなるので、パフォーマンス向上が期待できる機能です。

Web PaymentsのPayment Request APIに追加された　canMakePayment()　メソッドがサポートされました。このメソッド、昨年AppleがWebでのApple Payを発表した祭、Web Paymentsにないものとして上げていたメソッドのひとつです。Web PaymentsのアクティビティにもAppleが関わり、APIの差異を埋めているようなので、今後に期待ですね。

他にも、border-image-repeat: spaceがサポートされています。これでようやく実装がそろった感じですね。

Safari 10.1発表

macOS Sierra 10.12.4のベータ版が開発者向けに公開され、Safariが10.1にアップデートすることがわかりました。昨年春にリリースされたSafari 9.1のように、WebKitがアップグレードされ、新しい機能が導入されます。

APIの目玉はCustom Elementsでしょうか。Safari 10でもShadow DOMがサポートされたので、Web Componentsがまたさらに進みます。
ほかにも、Fetch APIやIndexed DB API　2.0, Gamepad APIがサポートされます。Gamepad APIはすこし意外ですね…ブラウザでゲームパッドを使うようなゲームを提供する顧客がいるのでしょうか？

JavaScriptでは、ES2017仕様のAsync Functionsや SharedArrayBuffer に対応します。

HTMLでは、HTML 5のフォームバリデーション機能がついに実装されました。これまでもDOM上では検証していたのですが、invalidな際にフォームの送信をブロックするという挙動を実装していなかったのでした。

CSSではGrid Layoutが有効になります。リリース時期を春とすると、FirefoxやChromeと同時期になります。いっきに使いどころが増えそうです。

Windows 10 Creator’s UpdateのEdge

Microsoftのブログが活発に更新され、Windows 10 Creator’s Updateで提供される各種機能の紹介がされています。先月から引き続きいくつか取り上げます。

このエントリでは、タブのサムネイルや一時退避といったブラウザのUIの機能（Operaみたいですね）や、EPUB、Payment Requset APIのサポートなど、EdgeHTML 15で目玉になる機能をまとめています。

WebRTC 1.0は互換性のため実装を始めたもので、あくまでORTCを推奨していくという立場のようです。コーデックもVP8をサポートしましたが、ソフトウェアでコードのため電力消費やCPUの使用はH.264よりも高いとのこと。

他にも、Content Security Policy Level 2のサポート、フルカラー絵文字のサポートもあるようです。

WebKitにWebRTCとCredential Management API

Safari 10.1もうれしいですが、次期メジャーバージョンでも嬉しい機能が入りそうです。

ひとつは、WebRTCです。1月19日に、Appleのエンジニアによって、WebKitにWebRTCのライブラリがチェックインされました。

WebRTCについては、getUserMedia() の実装が進んでいましたが、通信周りのAPIは特に進んでいませんでした。EdgeもEdgeHTMLでWebRTC (1.0)を実装しますが、ようやくといったところでしょうか。

コミットログを読むと、Chromeのソースコードをインポートして利用しており、Chromeとの互換性がなかなか期待できそうです。

もうひとつは、Credential Management APIです。1月24日に、AppleのエンジニアがWebKitにCredential Management APIを実装予定という旨のメールをメーリングリストに投稿しています。

Credential Management APIはパスワードやソーシャルログインなど、ユーザーの認証情報を抽象化して扱うAPIで、ログイン周りの煩雑さを解消できます。現在はChromeでのみ使えますが、Safariでも使えるようになるとモバイルでのログイン周りがとても便利になりそうです。

次期iPhoneで顔認証が導入されるといった噂を目にしていまし、信憑性が高まった気もします。

Facebookとブラウザベンダーの協力

Facebookの開発者ブログに、ブラウザベンダーと協力してFacebookへのリクエストを省力化したという話が掲載されています。あわせて、Chrome、Mozillaの開発者ブログでも紹介されています。

Facebookは各種アセットを、ハッシュ付きURL＋長大なキャッシュ有効時間というキャッシュ戦略で運用しています。キャッシュの有効時間が長ければ、ブラウザは再読込の際に同じリソースをダウンロードする確率が低くなるので、ネットワークにやさしいです。

しかし、これまでのHTTPキャッシュでは、ダウンロードは防げても、リクエスト自体は起こってしまっていました。パフォーマンスの観点からもうれしくありません。Facebookが自身のアクセスを解析したところ、全体の60％がそういったリクエストだったそうです。更に調べると、他のブラウザが13％〜22％だったのに対し、Chromeだけは63％ととても高い数値を示していたとのこと。

これを解消しようとFacebookのエンジニアがChromeチームに働きかけ、挙動を変更。結果63％だったものが24％まで減少したとのこと。

Firefoxでは、Chromeと同様の挙動変更を行わない代わりに、Cache-Control: immutable という新しいヘッダの値を実装しました。このヘッダについては、Jxckさんが自身のブログにまとめているのでそちらをご覧ください。

]]> Chrome Dev Summit開催、Firefox 50リリースの最新情報を解説──2016年11月のブラウザ関連ニュース /myakura/21730/ Wed, 28 Dec 2016 00:32:53 +0000 /?p=21730 連載： WEB標準化動向 (19)

2016年11月のブラウザ関連ニュースは、サンフランシスコで開催されたChrome Dev Summitと11月15日にリリースされたFirefox 50についてお届けします。

Chrome Dev Summit開催

11月はChromeのリリースがありませんでしたが、サンフランシスコにてChrome Dev Summitが開催されました。

名前にChromeと冠していますが、トピックはProgressive Web Appsです。Progressive Web Appsが認識され広がりつつある今年は、LyftやCNETのPWA開発の裏側といったケーススタディや、フレームワークを使った際にどうパフォーマンスを見たり改善したりするかといった実践的な話が多かったです。

ビデオも30分くらいのセッションがほとんど多いので、さくさくと観られます。

Firefox 50リリース

11月15日に、Firefox 50がリリースされました。

Firefoxもついに50になりました。

訪問済・未訪問を問わないリンクにマッチする :any-link 擬似クラスがサポートされました。a と何が違うのか疑問に思う方がいるかもしれませんが、:link, :visited, :any-link は area や link といった要素型にもマッチしますし、href 属性の有無もふまえます。ちゃんと「リンクされているか」を見るってことですね。

DOMでは、NodeList インターフェースがiterableになり、querySelectorAll() の結果に直接 forEach() などをくっつけられるようになりました。他のブラウザもChrome 51、Safari 10も対応済みですし、だんだんと使える環境が広がっていますね。

最近のDOM仕様では、addEventListener() の第三引数に AddEventListenerOptions というディクショナリを取れるようになっているのですが、そのうちの一つ once がサポートされました。jQueryの one() のように、一度だけ呼び出されるイベントリスナを設定できます。

セキュリティ関連では、X-Content-Type-Options: nosniff がサポートされました。ブラウザはサーバから来る Content-Type ヘッダを見てコンテンツの種類を判断しますが、状況や特定のファイルによってはコンテンツの中身を少し見てからその種類を推定したりします。これを「Content sniffing」や「MIME sniffing」といいます。
便利なときもあるのでしょうが、セキュリティ上の懸念があるため、それを無効にするための手立てとして X-Content-Type-Options: nosniff というヘッダがIE8に導入され、Opera, Chromeも追従し、最終的にFetch 仕様に取り込まれました。

このほか、border-image-repeat: space や、Chromeが独自に実装していたFileSystem APIの一部のサポート、dotted もしくは dashed を設定したボックスに border-radius をかけたときの見た目の改善などが行われています。

]]> details要素がサポート追加となったFirefox 49リリース、Safari 10リリースやベンチマークのMotionMarkなど──2016年9月のブラウザ関連ニュース /myakura/21141/ Thu, 13 Oct 2016 23:58:18 +0000 /?p=21141 連載： WEB標準化動向 (17)

2016年9月のブラウザ関連ニュースは、details要素がサポート追加となったFirefox 49や、Safari 10リリースとベンチマークのMotionMarkなどについて紹介します。

Firefox 49リリース

9月20日に、Firefox 49がリリースされました。

今回はいつも以上にいろいろ追加されてる気がします。

HTML関連では、<details> 要素がサポートされました。トグルで表示・非表示を切り替えるウィジェットをJavaScriptなしに導入できます。

これ関連で面白いなと思ったのが、HTML5 <details> in GitHub です。参考情報としてエラーログなどを張りつける際にログを <details> で囲むことで、ページが長くなるのを防ぎます。

Qiitaでも対応したとのことなので、コード一式をとりあえず書いておくとかそんなときに使えそうですね。

DOMまわりでは、before(), after(), replaceWith(), append(), prepend() メソッドがサポートされました。jQueryで見たことがあるメソッド名が多いですが、それらとほぼ同様で、要素の追加・置き換えを行います。なお要素を削除する remove() については、Firefox 23からサポートされています。

CSSでは、Level 4の機能がいくつかサポートされました。

#rrggbbaa 式の色表記がサポートされました。こちらは先日Blinkでも有効にされかけたのですが、WebViewの誤った実装との互換性をとるため無効にされてしまいました。

background-clip: text がサポートされました。背景画像でテキストをくり抜く表現が実現できます。もともとWebKitの独自拡張でしたが、広く使われてしまったこともあり、Backgrounds & BordersモジュールLevel 4で定義されました。

background-position-x/-yもサポートされました。background-position は水平方向・垂直方向の位置両方を指定しなければいけませんが、これらを使うと個別の方向ごとに位置を指定できます。もともと古いIEやWebKitでサポートされていたもので、こちらもBackgrounds & BordersモジュールLevel 4で定義されました。

背景画像系ではほかにも、Level 3の background-repeat　の round と spaceがサポートされました。他のブラウザでは結構前からサポートされていたので、追いついたかたちです。

-webkit- サポートも追加

もともと独自拡張だった機能のサポートがこのバージョンで行われたのには理由があります。Firefox 49では、-webkit- 接頭辞つきのCSSプロパティやAPIの一部をエイリアスとしてサポートしたからです。これによって、主にモバイル向けWebサイト・アプリの互換性が向上します。

-webkit- の部分的サポートは突然始まったことではなく、日本や中国などの特定サイトに限定し行われていました。それが方針転換し、すべてのサイトに適用されるようになりました。

標準化された機能と接頭辞つき実装には、標準化の過程でプロパティ名や値の取り扱いなどに違いが生まれます。こうした違いをどう埋めるかを明文化すべく、Compatibility Standardという仕様も作られています。ただ、すべての接頭辞つき機能がここで記されるわけではなく、webkitMatchesSelector() などは標準仕様に取り込まれるかたちで定義されています。

Safari 10リリースとベンチマークのMotionMark

9月13日のiOS 10と9月20日のmacOS 10.12 Sierraリリースにともない、Safari 10がリリースされました。Sierraだけでなく、El Capitanにも提供されています。

Safari 10の新機能については、過去の記事で取り上げているので、気になる方はそちらをご覧ください。

さて、9月21日に、WebKitからMotionMarkという、グラフィックス処理のパフォーマンスを計測するベンチマークが発表されました。

MotionMarkは、既存のグラフィクス関連ベンチマークが抱えていたいくつかの問題を解決するために用意したとのこと。計測対象がフレームレートではなく、フレームレートが閾値以下になったときのアニメーションの複雑さであることや、いろんなテストをいちシーンに詰め込まず、問題を切り分けやすくするといった工夫がされているようです。

Safari 10でMotionMarkを実行した結果。スコアは145.15（±5.12％）


この記事を書いているマシン（2011年のMacBook Air、11インチモデル）上のSafari 10で実行してみた

]]> Firefox 48の新機能、EdgeHTML 14を搭載したMicrosoft Edgeリリース──2016年8月のブラウザ関連ニュース /myakura/21074/ Fri, 23 Sep 2016 01:21:32 +0000 /?p=21074 連載： WEB標準化動向 (16)

2016年8月のブラウザ関連ニュースは、8月2日にリリースされたFirefox 48、8月31日にリリースされたChrome 53について紹介します。

Firefox 48リリース

8月2日に、Firefox 48がリリースされました。マルチプロセスが状況に応じて有効化されたり、Chrome拡張API互換のWebExtensionsが安定版となったりしました。

Web関連の新機能ですが、Web Animations APIのひとつ Element.animate() がサポートされました。

とても雑に紹介するならば、jQueryの animate() メソッドの標準版です。とはいってもCSSアニメーションとおなじバックエンドを使うため、基本的にjQueryのアニメーションよりもスムーズ・低負荷なものになるはずです。

CSSでは text-combine-upright: all がサポートされ、縦中横ができるようになりました。縦中横は日本語の縦書きで、短い桁の数値を一文字分に収めたりするのによく使われています。

スクリーンショット：「平成28年」という縦書き文字列中の「28」を縦中横にした例

通常は横に寝てしまう「28」を縦中横にしたので、ちょっと読みやすくなった

開発者ツールには、Firebug由来の機能が追加されました。ほかにも、CSSのルールを編集する際によく使われるプロパティ名が優先的にサジェストされるなど、細かなところの使い勝手が向上しています。

EdgeHTML 14リリース

8月3日にWindows 10 Anniversary Updateがリリースされ、Microsoft EdgeもEdgeHTML 14を搭載した新しいものにアップグレードされました。

このAnniversary Updateで、Edge公開時点のロードマップで言及されていた拡張機能がついに導入されました。こちらもChrome拡張APIと互換となっています。これで拡張を作るモチベーションが多少上がりますね。

EdgeHTML 14で導入されたWeb関連機能は多岐にわたります。Web Notifications APIやWOFF 2.0などはすでに実装・利用されていますが、Fetch APIやES 2015, ES 2016など他のブラウザと同じ時期に実装しているものもあります。また、FIDO 2.0などはEdgeが先行しています。今後の動向も注目です。

Chrome 53リリース

8月31日に、Chrome 53がリリースされました。

52でのMac版に続き、Windows版でも見た目がすっきりしました。これについて、リデザインに関わったGoogleのSebastien Gabrielが、その経緯や技術的なところをMediumに投稿しています。

Material Designへの移行にあたり、SVGでおこしたデザインをコードに変換する方法に切り替えたことで、使っていた画像のアセットが大幅に減ったといった話などは面白いですね。

Web関連機能では、新しいShadow DOMのAPI、通称「Shadow DOM v1」が実装されました。

Shadow DOMはChrome 35から実装されていますが、これは「v0」と呼ばれる、Blinkのみでしか使えないものです。標準化が進むにつれ、APIに結構大きな変更が生まれたため、新しいAPIは「v1」として区別されています。v1 APIは他ベンダーの合意もとりつけ、Safari 10でも実装されます。

Android版では、Payment Request APIが有効になりました。

モバイルで決済をする際にとても煩わしいのが、決済フォームへのクレジットカード番号や住所の入力でしょう。Payment Request APIは、端末やブラウザに保存されている情報を利用し、それらをブラウザ側で用意されたUIで提供することで、決済周りの体験をスムーズにする目的で策定されているAPIです。

こちらもAndroid版ですが、muted 属性が指定された video 要素に限り、autoplay 属性や play() メソッドによる自動再生が可能になりました。

これまではビデオの自動再生ができなかったため、アニメーションGIFやCanvasで擬似的に行うといったハックが使われていました。しかしアニメーションGIFには容量の増大や色数の制限、描画パフォーマンスなどに問題がありますし、CanvasもビデオファイルをJavaScriptでデコードするといった無茶をしており、うれしくありません。こうした本末転倒な状況を解消するため、無音状態に限り自動再生できるように要件が緩和されました。

同様の変更は、iOS 10のSafariでも行われます。

多くのサイトが、負荷の高いアニメーションGIFからビデオに移行してくれればなあと強く思います。

]]> Firefox 47・Safari 10、EdgeとProgressive Web Appsの新機能など─2016年6月のブラウザ関連ニュース /myakura/19921/ Tue, 05 Jul 2016 02:25:46 +0000 /?p=19921 連載： WEB標準化動向 (14)

6月7日にリリースされたFirefox 47や、WWDCで発表されたSafari 10、WindowsにおけるProgressive Web Apps対応など、6月も注目のブラウザニュースをお届けします。

Firefox 47リリース

6月7日にFirefox 47がリリースされました。

今回は開発者ツールを取り上げましょう。まずはResponsive Design ModeでUA文字列をカスタマイズできるようになりました。いまのところプリセットがないので面倒ではありますが、そこそこ便利です。

スクリーンショット：開発者ツールのResponsive Design Modeのツールバー。Custom User AgentでUA文字列を設定できるようになった。

さて、これはいいなと思ったのが、コンソールの複数行入力です。以前からShift+Enterで可能でしたが、Shiftを押し忘れてしまって赤い SyntaxError を見るなんてひとは多かったのではないでしょうか。

スクリーンショット：Chrome DevToolsのコンソールで、複数行入力をしようとして失敗した例。「{」でEnterを間違えて押してしまいエラーがでた。

Firefox 47の開発者ツールは入力中のコードの構文を解釈するようになり、{ など「開いている」状態でEnterを押すと自動的に複数行入力になります。foo(...) など「閉じている」場合はふつうに評価されます。

スクリーンショット：Firefoxの開発者ツールのコンソールでは、構文を解釈するので「{」は開いた状態と認識され、ただのEnterでも次の行にカーソルが移動する。

構文エラーを意図的に入力したい方には不便かもしれませんが、基本的にはとても便利です。
ちなみにSafariではたしかSafari 7くらいからできます。

ほか、Service Worker関連のデバッグに便利な機能が多数追加されています。

Safari 10発表

6月13日から17日までAppleのWWDCが開催され、MacのOSがOS XからmacOSになるなどいろんなことが発表されました。
SafariもSafari 10になることが発表されました。すでに実装される機能が公開されています。

ES6のサポートはうれしいですね。Indexed DBやCSS Filtersの接頭辞削除など、互換性も向上しています。
フォント関連機能にも大きな進展があります。Font Loading APi、WOFF 2.0、unicode-range のサポートが追加されました。とくに日本語のWebフォントは容量が大きいので、これらの機能はうれしいですね。

このエントリでは、先日Webフォントの読み込み中の挙動が変更されたことも書いてあります。これまではWebフォントが読み込まれるまでテキストが表示される問題でしたが、今回の変更でFirefoxやChromeと同じく、Webフォントの読み込みに時間がかかる場合は3秒後にフォールバックのフォントで一旦表示するようになりました。Safari 10の紹介には書いてありませんが、この変更が取り込まれてることを祈りましょう。

Keynoteで発表されたApple Pay on the WebについてはSafariでのみしか利用できない、Web Paymentsワーキンググループで策定している標準APIではないといった批判の声もあります。これについてはAppleのEdward O’ConnorがWeb Paymentsワーキンググループに対して説明をしています。

マーチャントの検証機能や canMakePayments() といった標準にはないメソッドがApple Payにはあるそうです。AppleもWeb Paymentsワーキンググループに参加していますし、標準APIもよいものにしていってほしいですね。

また、Flashコンテンツについても、ユーザーのアクションなしには実行できないようになると発表されました。

MacにはFlash Playerがプリインストールされていないので、インストールしていない人もいるかと思います（Chrome内蔵のFlash Player経由で見るなどは大いにありそうですが）。他のブラウザーもFlashをなるべく実行しないように動いていますし、HTML5なコンテンツへの移行が急務になりそうですね。

EdgeとProgressive Web Apps

Microsoft EdgeチームのJacob Rossiが、MediumにWindowsにおけるWebアプリのこれまでと今後のProgressive Web Apps対応について投稿していました。

WindowsにおけるProgressive Web Apps対応は、ChromeやOperaのそれよりも、よりOSの機能との統合を考えているようです。具体的な例としてアプリケーションのリストへの追加や、アプリの設定やアンインストールといったものを紹介しています。また、WindowsストアやBingの検索結果への表示といった、アプリの発見についてもいろいろ考えている模様。PWAをふつうのアプリとして扱うよという強いメッセージを発しています。

この記事と時を同じくして、Push API, Web App Manifest, Cache APIの実装開始も発表されました。Windowsというデスクトップ環境が主流のプラットフォームでWebアプリをどう統合していくか、とても楽しみです。

]]> Edge Web Summit、Chrome 50、Firefox 46、WebKitなど─2016年4月のブラウザ関連ニュース振り返り /myakura/18864/ Tue, 10 May 2016 00:00:57 +0000 /?p=18864 連載： WEB標準化動向 (12)

2016年4月のブラウザニュースは、Edge Web Summit、Chrome 50リリース、Firefox 46リリース、WebKitの接頭辞ポリシー変更などについて紹介します。

Edge Web Summit開催

4月4日に、Edge Web Summitが開催されました。Microsoftは前々日にBuildカンファレンスを行っていましたが、Edgeはこちらに集中した印象です。

新たに発表されたのは、レンダリングエンジンEdgeHTMLのイシュートラッカーです。

Internet Explorer時代にもMicrosoft Connectで公開フィードバックはできましたが、こちらはエンジンのEdgeHTMLに特化しており、開発者とのコミュニケーションを強く意識しているように感じられます。

他にも、Webで使われているCSSプロパティなどを集めたデータも公開されました。ChromeチームもChrome Platform Statusで公開していますが、それと同等のものですね。

「使われている」の定義にもこだわっているようで、ただCSSファイルを解析しているわけではなく、WebページにアクセスしDOMとCSSOMを構築したうえで調べているとのこと。

現在バグのため padding 利用率が0％になっていますが （CSSの calc() 解釈まわりにバグがあるそう）、そのうち直るでしょう。

また、WebRTC関連のロードマップが更新されたことも発表されました。

これまでEdgeではORTCをサポートしていましたが、互換性への取り組みからWebRTC 1.0の一部も実装するようです。また、映像コーデックについてはH.264/AVCを実装中、さらに決定ではありませんがVP8も検討しているとのこと。

Chrome 50リリース

4月13日に、Chrome 50がリリースされました。ついに50なのですね。

新しい機能についてはBetaリリース時のポスト、およびDev Operaの記事が詳しいです。

新しい機能として、HTMLの link 要素に preload というものが加わりました。使われるであろうリソースをその種類とともに指定することで、先読みを実施できます。

たとえばWebフォントのURLなどに使いやすそうです。外部CSSでWebフォントが定義されている場合、まずそのCSSファイルを取得し解釈したのち、Webフォントをリクエストするため、パフォーマンスの向上が見込めそうです。

他に目立つのは、Canvasの toBlob() メソッドと、 ImageBitmap インターフェースでしょうか。

toBlob() は toDataURL() の Blob 版です。一度文字列を経由せずに、バイナリデータを直接さわれるのが魅力でしょうか。

ImageBitmap は、Canvasで画像を扱いやすくするAPIです。これまでは効率的に画像のデコードなどを行えませんでしたが、createImageBitmap() を使えば非同期に画像を容易できます。drawImage() のように描画を必要としないのも魅力的です。Workerにも提供されるので、画像の処理を別スレッドにもっていくのも容易です。

すでに他のブラウザでも一部実装されており、toBlob() はFirefox 19とIE10から、ImageBitmap はFirefox 42でサポートされています。

新しい機能が追加される一方で、削除・廃止予定の発表もあります。Chrome 50では、非HTTPS環境でGeolocation APIが利用不可に、同じく非HTTPS環境でAppCacheが廃止予定となりました。

位置情報の取得をGeolocation APIのみに頼っているサイトはHTTPSへの移行が強く推奨されていますが、Google Maps Geolocation APIなど別のサービスも紹介されています。

機能の削除や廃止については、blink-devメーリングリストで都度アナウンスされるほか、Chrome Platform Statusで「deprecated」「removed」と検索すると、すでに変更されたものも含め一覧を見られます。

また、廃止予定の機能を仕様している場合はコンソールにその旨が出ますので、たまにはちゃんと読みましょう。

Firefox 46リリース

4月26日にFirefox 46がリリースされました。

ES2015 に導入された RegExp の u フラグがサポートされました。絵文字や「𠮷」といったBMP外の文字はES5時代のJavaScriptでは扱いづらかったのでうれしいですね。

これに伴い、input 要素の pattern 属性の解釈を u フラグと同等にする変更がHTML仕様に入り、そちらもあわせて実装されました。たしかにフォームのバリデーションは u フラグつきの方がやさしそうですね。

はてなの開発者向けブログでも取り上げられています。わかりやすいです。

また、JavaScriptでのUnicodeの扱いはOperaのMathias Bynesの記事によくまとまっています。彼の講演も面白いですよ。

CSSでは、圏点を表示させる text-emphasis プロパティ群がサポートされました。小説などでは見る強調表現ですが、Webでも太字以外の強調が今後増えてくるのでしょうか。

他には、過去に紹介した -webkit- 接頭辞のプロパティサポートが有効になりました。日本のモバイル向けページなど、-webkit- 接頭辞に強く依存してるページの表示が向上すると思われます。

WebKitが接頭辞のポリシーを変更し、他エンジンに追従

4月26日に、WebKitがベンダー接頭辞に関するポリシーを変更すると発表しました。試験的な機能にベンダー接頭辞をつけることはせず、他エンジンのようにランタイムフラグを設けて試すようになります。

最近はツールの助けもあり、手で -webkit- などを書くことは少なくなっていると思いますが、すでに公開されたページではWebKitの接頭辞に依存したコードが残っていたりします。これをうけEdgeやFirefoxは互換性確保のためいくつかの機能をサポートしています。

接頭辞の廃止については、WebKitもしていきたいとのことですが、機能によりそうです。廃止が現実的でない機能については、Compat Standardでの定義など標準化によるサポートも必要でしょうか。

]]> WebAssembly実装プレビュー、Chrome 49新機能など─2016年3月のブラウザ関連ニュース振り返り /myakura/18768/ Mon, 18 Apr 2016 00:00:26 +0000 /?p=18768 連載： WEB標準化動向 (11)

2016年3月のブラウザニュースは、Chrome 49の新機能、Firefox 45とinnerText、WebAssembly実装のプレビュー、Edgeの拡張機能、Safari 9.1リリースなどについて紹介します。

Chrome 49でCSS Variablesサポート

3月2日に、Chrome 49がリリースされました。新機能はベータ版がリリースされた際にまとめられています。また、同じエンジンを搭載するOpera 36のリリース記事でも紹介されています。

注目はCSS Custom Properties（通称Variables）でしょうか。プリプロセッサやポストプロセッサが持つ変数とちがい、ちゃんと継承されるというのが特徴です。これを利用し、Jake Archibaldが、display の値をカスタムプロパティで定義し、外部CSSが読み込まれた際に block に書きかえさせ段階的にCSSを読み込ませるというアイデアを披露しています。

V8も更新され、ES2015のdestructuringとdefault parametersが使えるようになりました。また、Promiseのrejectionを検知する unhandledrejection イベントおよび rejectionhandled イベントもサポートされました。

Firefox 45と innerText

3月8日に、Firefox 45がリリースされました。

ES 2015のClass構文が有効にされています。うれしいですね。

他には、他ブラウザとの互換性のため innerText プロパティがサポートされました。要素内の「レンダリングされたテキスト」を取得するプロパティです。

この「レンダリング」というのが曲者です。要素内の文字列を取得するには textContent プロパティがありますが、こちらは「DOM要素内のテキスト」なので display: none などが指定された要素内のテキストももちろん返ります。いっぽう、 innerText はレンダリング結果を考慮するため display: none な要素内のテキストは結果に入りません。

innerText はブラウザ拡張などで外部サイトをいじったりするときには便利だったりしますが、レイアウトを行うためパフォーマンスに影響があります。単純に要素のテキストを取得したい場合は textContent を使いましょう。

WebAssembly実装のプレビュー

3月15日に、Mozilla、Google、Microsoftが、WebAssemblyの実験的なサポート状況について公開しました。WebAssemblyの試験実装は昨年から進められていますが、3ブラウザで相互運用可能な状態になったとのことです。

FirefoxとChromeについては、NightlyやCanaryでフラグを有効にすると試せます。

WebAssemblyについては、中心人物のひとり、MozillaのLuke Wagner氏へのインタビューが面白いです（インタビューの場に混ぜていただきました）。インタビューが行われたMozillaのView Source Conferenceでのセッション資料も参考になります。

また、先日ポッドキャストでのインタビューも行われています。こちらもあわせてどうぞ。

Edgeの拡張がプレビュー版に

Microsoft Edgeの拡張機能が、ついにプレビュー版に入りました。

拡張は正式リリース時にはWindows Storeから追加できるようになるそうです。

拡張の構造はChrome拡張互換のAPIですが、現時点では本家やMozillaのWebExtensionsと少し違い、chrome オブジェクトが browser オブジェクトに変わっているそうです。ちょっと面倒ですね。

サポート予定のAPIはロードマップが公開されています。Firefox, Edge, Chromium系で（だいたい）同じコードで拡張が動くようになるのでやる気がでますね。

Safari 9.1リリース、さらにTechnology Preview登場

3月21日に、OS X 10.11.4とiOS 9.3がアップデートされ、Safari 9.1がリリースとなりました。WebKitのブログで新しい機能が紹介されています。

新しい機能は内部的に利用されてもいるようで、追加されたCSS Custom Propertiesを使い、Web Inspectorのコードをシンプルにした話もエントリとして公開されています。

さらに、3月30日、Safari Technology Previewという開発者向けのビルドが公開されました。

Safari Technology Previewはリリース版のSafariよりも新しいWebKitを搭載したビルドで、2週間にいちど更新されます。最初のビルドではES2015のArrow Functionsやイテレータ、Web標準ではShadow DOM (v1)などが使えるようになっています。

なお、レンダリングエンジンのWebKitはこれまでもナイトリービルドを提供していましたが、Safari Technology Previewは独立したUIを持ち、App Storeから更新されるといった違いがあります。

現段階でiOS版のプレビューは提供されていませんが、多くの人がそれを望んでるだろうとは認識しているとのこと。こちらのほうが出ると嬉しいので、要望をあげましょう。

]]>