Smart Communication Design Company
ホーム > ナレッジ > Blog > フロントエンドBlog

フロントエンドBlog

Webのフロントエンドを構成する技術、特にHTMLやCSS、JavaScript、またそれらに関連する話題を扱うBlogです。

PWA+AMP=PWAMPと言う考え方

UI開発者 泉口

2017年5月17日から19日かけてGoogle I/O 2017が開催されました。

Smart ReplyやGoogle LensなどのAI技術、Android Go/Oに加え開発言語であるKotlinの正式化、Google Assistant iOS版の提供、Google Assistantを搭載したGoogle Homeの日本発売など、さまざまな技術躍進が発表される中で、やはり個人的にはPWAとAMPに関する内容が気になる所です。

PWAに関してはProduction Progressive Web Apps With JavaScript Frameworksにおけるフレームワーク上の「PRPL」のことを書くべきだとは思いますが、今回はFrom AMP to PWA: Progressive Web AMPsからAMP+PWA対応を行ったサイトがどのような恩恵を受けるのか、一部抜粋した内容を前提となるモバイルパフォーマンスを含めて記載します。

全文を読む

「Can I use...」にCSSのtext-orientationプロパティが掲載されるようになりました

UI開発者 渡邉

2017年5月13日、各種Webブラウザにおけるサポート状況を提示してくれるWebサイト「Can I use…」に、CSSのtext-orientationプロパティ掲載されるようになりました。

text-orientationプロパティは、縦書き時における行内テキストの向きを定義するもので、横書き時には効果がありません(参考:Mozilla Developer Networkの該当項目)。

Webブラウザ側の対応状況は、IE11、Microsoft EdgeおよびAndroid 4.4系が未対応となっており、有効なPolyfillライブラリもないことから、今すぐに使えるという状況ではないようです。

また、Microsoft EdgeにおけるPlatform statusリストtext-orientationプロパティを定義しているCSS Writing Modesが列挙されていないことから、Microsoft Edgeでのサポート予定は不明のままです。

将来に期待したいですね。

レシピを見ながら楽しく実装、フォームのアクセシビリティ!その1

UI開発者 宇賀

先日(4月20日)、2016年版のWCAG 2.0達成方法集の日本語訳が公開されました。

WCAG 2.0 達成方法集

日本語訳がでたことで、より一層日本語Webページのアクセシビリティ向上に期待が高まりますが、「実際どこから手を付けたらいいのかわからない」ということはありませんか?

個人的なおすすめにはなりますが、わかりやすく手を付けやすい項目は「フォーム」のアクセシビリティだと感じています。日々の業務の中でも、フォームのアクセシビリティについての問い合わせが最も多いです。

そこで今回は、フォームのアクセシビリティ担保の方法を、いくつかの達成方法集(レシピ)とあわせて紹介したいと思います。

※ 簡単なアクセシビリティチェックの方法については、以前執筆した自分でできるWebページのアクセシビリティチェックをご覧ください
※ この記事に設置されている入力欄に入力された情報が当社に送信されることはありません
※ 作成したページや、本記事の実装例をVoiceOver(macOS、iOS標準搭載)などのスクリーンリーダーで実際に聴いてみると、より直感的に理解が深まります

全文を読む

Web Bluetooth APIことはじめ

UI開発者 加藤

Bluetoothはデバイス間でのワイヤレス通信に日常的に使われています。代表的なものとしては、ヘッドフォンとPC間の接続や、外部センサーとスマートフォン間の接続などがあげられます。Bluetoothバージョン4.0で追加された速度よりも省電力に特化した通信方式 Bluetooth Low Energy(以下「BLE」)では、ここ数年で話題となったIoTデバイス間での接続などにも多く用いられています。

今回ご紹介する「Web Bluetooth API」は、そんなBluetoothをWebブラウザから利用して外部デバイスを検索したり、デバイスの持っている情報を読み書きするための機能を提供してくれるAPIです。

各ブラウザの実装についてはまだまだという状況ですが、macOSのGoogle Chromeではバージョン56からデフォルトの状態で使用可能になりました。APIの動作条件としてセキュリティ上の観点からHTTPS上であることが必須となっています。(ただし、開発時のlocalhostは除く)また、当然のことながら端末にBluetoothが搭載されていること、BluetoothがONになっていることも必須です。その他のブラウザの実装状況はW3CのWeb Bluetooth CGのGitHubに記載されていますので、参考までにご覧ください。

さて、APIの中身について説明していきたいところですが、その前に知っておくべきBluetooth周りの情報がたくさんありますので、今回はことはじめとしてその部分について順を追って説明していきます。

Bluetoothとプロファイル

現在多くのBluetoothデバイスが開発されており、その機能やメーカーは多岐にわたります。そのためメーカー間の差異を埋めるべく、デバイスからどの情報をどの順番に転送するかなどのルールを機能ごとに定めたプロファイルというものが存在します。

プロファイルは、基本的にはBluetooth SIGというBluetoothの推進を行っている業界団体が策定しているものです。いくつか条件はありますが、策定されているもの以外に自社固有の機能を持つプロファイルを提供することも可能です。

既に策定されているプロファイルは採択済み仕様ページの従来版プロファイル項目に記載されています。無線マウス、キーボード用のプロファイル(HID)やヘッドセットと通信するためのプロファイル(HSP)などがあります。 外部デバイスや連携するアプリケーションを作る際は、このプロファイルに沿って機能を実装していくことになります。

BLEによる通信の場合は通常のBluetoothと違い、Generic Attribute(GATT)Profileというベースとなるプロファイルが用意されています。

Generic Attribute(GATT)Profile

Bluetooth3.0以前とBLEでは通信方式が違うためBLE用のプロファイルが別に策定されています。そのベースとなるものがGATTです。GATTをベースとして作られたプロファイルもBluetooth SIGによって策定されています。プロファイルの一覧は採択済み仕様ページのGATT基盤仕様項目に記載されています。

今回はこの中から心拍計のプロファイル(Heart Rate Profile)を例にとり説明していきます。実際のプロファイルをご覧になりたい方は先ほどの一覧のバージョン番号がPDFへのリンクになっていますので、そちらをご覧ください。

一般的にGATTのプロファイルは1つ以上のサービスと呼ばれるグループから構成されており、各サービスは1つ以上のキャラクタリスティックと呼ばれる要素から構成されています。

GATTプロファイルの階層

仕様を見てみると、定義されている心拍計のプロファイルには心拍計の機能をまとめた「Heart Rate Service」と、デバイスの情報をまとめた「Device Information Service」の2つのサービスが定義されていることが分かります。

例えばこの心拍計の機能に加え、サイクリング時のスピードやケイデンス計測の機能を連携させたデバイスやアプリケーションを作りたい場合は、このプロファイルに「Cycling Speed and Cadence Service」を組み合わせて実装すればよいことになります。

続いて、プロファイルに含まれているHeart Rate Serviceの仕様を見てみると、このサービスは実際の心拍の値を示す「Heart Rate Measurement」や、心拍計が体のどこに設置されているかを示す「Body Sensor Location」などの要素(キャラクタリスティック)で構成されていることが分かります。また各キャラクタリスティックが必須の値か、読み書き可能な値かなどの情報も記載されています。

Web Bluetooth APIを用いたWebアプリを作る際はこの仕様を見ながらデバイスの持っている値を読み書きしていくことになります。

心拍計の他にどんなサービスがあるか、各サービスはどんなキャラクタリスティックを持っているかは、GATT XMLにまとめられていますので、ご覧ください。

試してみよう

今回はWeb Bluetooth CGが提供している、Heart Rate Sensor Demoを試してみました。手元にBluetooth対応の心拍計がなかったため、「LightBlue Explorer」というiOSアプリを使い、iPhoneを仮想のBluetoothデバイスとして連携しました。

まずはiPhoneからアプリを立ち上げて、macOSからスキャンできる状態にします。

LightBlueアプリ画面 Heart Rateにチェックを入れることで配信が始まります

デモページを開き画面をクリックすると、Bluetoothデバイスのスキャンが始まります。

ブラウザから外部デバイスをスキャンしている様子。先ほど配信を開始したiPhoneが検知できている状態

デバイスが検知できたら選択してペア設定を押すだけで、下記のようにデバイスから取得した値を利用してグラフのように表示することができます。この仮想心拍計では、60,80,100,120の値を一定間隔で送っているようです。

端末から受け取った値をグラフとして表示している

先ほど説明したGATTベースのプロファイルに沿って作られたデバイスであれば、どれでもこのWebページをビューワーとして利用することができます。逆に言えば、GATTの仕様に沿って作られ公開されたWebページは、外部デバイスのビューワーとして誰でも利用できます。そのWebページを集めればビューワーを集めたギャラリーとして、デバイスを利用しているユーザーに利用してもらうことも可能です。

最後に

現状、Bluetooth通信を用いるデバイスにはネイティブアプリがセットである場合が多く、ユーザーはアプリストアからアプリをインストールするなどの行動が必要です。しかし、このAPIを使えばその手間を省くことができます。また、以前の記事でご紹介したPWAや、一時期流行したiBeaconなどを組み合わせれば、お店の前を通りがかったら通知を送るというような「Webアプリ」を作ることも可能です。

冒頭に示したようにブラウザの実装状況が今ひとつであったり、BluetoothがOFFの場合には機能しないなど、サービスとして公開するにはなかなかに高い壁があります。しかし、PWAの普及が進みWebサイトと外部デバイスとの連携が必要になったときに活躍できるのではないかと考えています。

Google Chrome 58安定板リリースと59の搭載予定機能

UI開発者 泉口

4月19日から25日にかけ各デバイスのGoogle Chrome 58がリリースされました。 多くのFIXと改善がありますが、中でも注目すべきは以下の2点です。

Progressive Web Apps フルスクリーン対応

PWAをホームから表示した際のフルスクリーン表示が可能になりました。manifest.jsonのdisplayの値をfullscreenに変更するだけで実装が可能です。New in Chrome 58にも例が記載されていますが、ステータスバーやナビゲーションが画面内にあるデバイスの場合、フルスクリーン時にどう表示されるか気になったので、当社のブログを簡易的にPWA化し、テストしてみました。

結果は以下のようになりました。

ナビゲーションボタンが物理的なデバイスもあるので、この辺りの挙動はデバイスごとに異なると考えられます。

IndexedDB 2.0

Chrome 58からIndexedDB 2.0を完全にサポートした状態になります。新機能詳細はWhat's new in IndexedDB 2.0?に記載されています。

Google Chrome 59の搭載予定機能

ヘッドレスモードの搭載

コマンドラインでブラウザを操作できるヘッドレスモードを搭載する可能性があります。ブラウザ上での描写を行わずにデータを取得できるため、スクレイピング、処理の自動化などの用途が想定されます。詳細はChrome Platform Statusをご確認ください。

APNG

Support for Animated PNGにおけるコメントでは、Google Chrome 59においてアニメーションPNGをサポートすることが明言されています。実際にGoogle Chrome Canaryでは透過を含めたAPNGが動くことが確認できます。

CSS/JavaScriptのカバレッジ

デベロッパーツールのアップデートでは、CSS/JavaScriptのカバレッジ機能が追加されます。この機能は記述されているコードの何パーセントが実際に使用されているかをファイルごとに確認することができるため、不要なファイルの削減や結合の指標を立てることが可能になります。

フルページスクリーンショットのサポート

こちらもデベロッパーツールの内容ですが、従来の「Capture screenshot」に加え、「Capture full size screenshot」が追加されます。スクロール領域の全てをキャプチャーすることができるので、今後キャプチャー関連のChrome拡張機能は不要になるかもしれません。