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

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

ブラウザからドライブにファイルの書き込みができるNative File System APIとは？


UI開発者 加藤

Google Chrome 78からNative File System APIのオリジントライアルが始まりました。このAPIはユーザーのデバイス上にあるファイルを読み込んだり、任意のディレクトリにファイルを書き込むことができるAPIです。途中段階のAPIですが、このAPIが提供されることでスマホアプリやデスクトップアプリのような機能をWebアプリでも提供できるようになります。

「ブラウザからドライブにファイルの書き込みができるNative File System APIとは？」の全文を読む

パーマリンク

Riot.js v4に対応したルーター、Riot Routerのbeta版がリリースされました！


UI開発者 板垣

本日、すべてのRioterが待ち望んでいた、新しいRiot Routerのbeta版がリリースされました！

「Riot.js v4に対応したルーター、Riot Routerのbeta版がリリースされました！」の全文を読む

パーマリンク

TPAC 2019参加報告


アクセシビリティ・エンジニア 中村（直）

W3Cが年に1回行っているミーティングイベントTPAC 2019について、9月16日と17日の2日間参加してきました。TPACは私自身は初めての参加で、議論や情報交換が活発に行われている様子をうかがうことができました。私からは、2日間まとめてのレポートを簡単にお届けしたいと思います。

既にアクセシビリティBlogに掲載されている当社黒澤によるレポートもあわせてご覧ください。

1日目

1日目は主に、Internationalization Working GroupとAG Silver Task Forceを傍聴してきました。

Towards Accessible Ruby

『Towards Accessible Ruby』というスライドで村田真氏がスライドで発表を行い、ルビについて議論を行っていました。議論のたたき台となったのは「昆虫」という単語でした。

音訓の小・中・高等学校段階別割り振り表（平成29年3月）：文部科学省によれば、「昆」の字は中学校で習う漢字とされています。したがって、小学校の早い段階では「こん虫」と交ぜ書きにすることが考えられます。

そのような前提条件を踏まえると、書き方のパターンは、次のように6つ考えることができます。

  1. まぜがき「こん虫」
  2. すべて漢字「昆虫」
  3. すべてひらがな「こんちゅう」
  4. まぜがきにルビ「こん虫ちゅう」
  5. すべて漢字でパラルビ「昆こん虫ちゅう」
  6. 漢字で総ルビ「昆虫こんちゅう」

特定の人に対して、次のような状況が考えられます。

これらを皮切りに、実装と仕様、両者の観点から様々な議論が行われていました。議論されたのはルビですが、アクセシブルな日本語とは一体どういうものなのか？というのを考えさせられる一幕でした。

AG Silver Task Force

WCAGの次世代版と目されているSilverですが、私が傍聴したときには、WCAG to Silver Mapについてを議論しながら内容を詰めていく作業の真っただ中でした。

Silverができ上がってくるまでは、今しばらく時間がかかるように感じました。また、達成基準の番号で議論しているのがとても印象的でした。

2日目

2日目となる9月17日はCascading Style Sheets (CSS) Working Groupのミーティングを傍聴しました。スケジュールとしては、他のグループとの合同ミーティングが主立ったものでありましたが、その中からいくつかのトピックを簡単に記したいと思います。

聴覚のみレンダリングするテキスト

アクセシビリティとの合同ミーティングでは、テキストを視覚的には表示したくない一方で、スクリーンリーダーには聴覚的に読み上げさせたい、という需要はありますが、これは例えば次のようなコードで実現できることが知られています。

.hidden-visually {
    position: absolute;
    left: -5000px;
}

他にも同様の効果を得る方法があるものの、いずれにせよ専用のCSSプロパティが実装されていないというのが大きな要因です（CSS Speech Level 1として提案されていたspeakプロパティは存在しましたが、CSS Speech Level 1は既に廃止されている仕様です。）

ミーティングではARIA属性やinert属性といったアプローチ、キーボードフォーカスについても取り上げられました。ミーティングの中ではこれと言った結論は得られることはありませんでしたが、この問題について、Amelia Bellamy-Royds氏とLéonie Watson氏が中心となって提案の原稿を作っていくことが確認されました。

適切なアクセシビリティオブジェクトを作るような提案に仕上がるのかどうかが1つのカギを握っていると個人的には思っています。

関連issue: [css-display] create a display property value for visually hiding an element while making it available for AT

lang()の正規化

関連issue: Consider Canonicalization of language tags in :lang() selector maching

HTMLでは、コンテンツの自然言語を特定するために、IETF BCP47という標準で規定される言語タグと呼ばれるものを用います。
HTMLを書いたことがある人になじみのある例を挙げるならば、

<html lang="ja">

というHTMLコードに対応する話で、このlang属性値のjaが言語タグに当たります。

さて、CSS 2で導入され、現在はSelector Level 4仕様において定義されているlang()という疑似クラスがありますが、この疑似クラスについて正規化した上でマッチングさせるとどのような挙動が適切か？というのがトピックとして挙げられました。

例えば、広東語であることを表す言語タグは前述のissueにも挙げられているように、次の3つが考えられます。

上2つはレガシーな書き方で、一番下のものが好ましい書き方となっています。ここで、:lang(yue)とした場合は当然、上2つの言語タグとマッチしないわけですが、言語タグの正規化を考えると、zh-HKやzh-yueともマッチングするのが好ましいのかどうか、といったことが議論されました。

このトピックについて、これと言った結論は得られませんでしたが、当該issueを作成したFlorian Rivoal氏が引き続き検討を行っていくようです。

CSS Writing Modes Level 3がついに策定完了へ

W3Cの文書プロセスとしては、草案（Wonking Draft）→勧告候補（Candidate Recommendation）→勧告案（Proposed Recommendation）→勧告（Recommendation）という段階を踏んで、仕様が確定する仕組みになっているのですが、勧告候補の終了基準（CR Exit Criteria）の原則として、「2つの独立した実装」が必要とされています。

ミーティングではまず、直近のCSS Writing Modes Level 3勧告候補に対する実装レポートについてFlorian Rivoal氏から説明がありました。いくつかのテストについてはFirefoxのパッチが作成中であり、これに関しては解決する見通しがあるためにテストに合格するようになるとのことです。

さらに、ミーティング開始の時点でLevel 3のissueとして挙げられていた3つ（該当のissueに関してはCSS Writing Modes Level 3 Disposition of Comments for 2019-09-03 CRを参照）のものを中心に確認と議論が行われました。

その結果、該当するissueについての議論はLevel 4で引き続き行われることとされ、勧告案に進むことが決まりました。

これにより事実上、CSS Writing Modes Level 3は策定が完了したわけですが、仕様が前進する決定がされたときには拍手と歓声があがりました。勧告案にすることが決まる瞬間というのはなかなかお目にかかることができないため、この瞬間に立ち会うことができたのは幸運であったと思います。

最後になりますが、歴代のWriting ModesのEditorsの皆さん、本当にお疲れ様でした。

パーマリンク

HTMLメール版のCan I use！「Can I email」が誕生しました！！


UI開発者 板垣

先日、普段は静かなHTMLメールコミュニティが久しぶりに盛り上がりを見せていたのでなにごとかと思いましたが、どうやら有志によってHTMLメール版のCan I useともいえる「Can I email」が作成されたようです！
これで、作成中のHTMLメールを都度、対象メールクライアントに送信して表示の確認をする手間が省けそうです。

「HTMLメール版のCan I use！「Can I email」が誕生しました！！」の全文を読む

パーマリンク

Google Chrome 77のDevToolsからLighthouse v5.2.0が使えるようになりました


UI開発者 古川

Google Chrome 77がリリースされましたが、このバージョンのDevToolsでLighthouseがv5.2.0にアップデートされています。

Lighthouse v5.2.0の主要な変更点として、「Third-Party Usage」と「Total Blocking Time」がAuditsに追加されました。

「Third-Party Usage」はDiagnosticsに追加された項目で、ページ内で読み込まれているサードパーティスクリプトのファイル容量とメインスレッドでの実行時間が一覧化されます。これにより、外部から読み込まれるスクリプトがどれくらいWebサイトパフォーマンスに影響を及ぼしているのかがわかりやすくなりました。

ちなみにサードパーティスクリプトとは、外部のドメインから読み込むJavaScriptのことです。たとえば、Google Analytics用のスクリプトやSNSシェアボタン用のスクリプトがサードパーティスクリプトに該当します。

「Total Blocking Time」は試験的なメトリクスで、First Contentful Paint（FCP）からTime To Interactive（TTI）までの間で発生する50msを超えるメインスレッドのタスクのうち、Blocking Time（ユーザーの入力応答を阻害する時間）の合計時間をさします。

現段階ではまだ試験的なメトリクスのため、HTML形式のレポートではなくJSON形式のレポートで確認が可能です。JSON形式のレポートはCLIからレポート形式を選択して入手できるほか、Audits上でも右上のメニューから「Save as JSON」を選択して入手できます。

パーマリンク