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

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

CSS Writing Modes Level 3がW3C勧告になりました


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

やや旧聞ですが、2019年12月10日付けでCSS Writing Modes Level 3がW3C勧告(Recommendation)となりました。10月末に勧告案(Proposed Recommendation)になったことを伝えたCSS Writing Modes Level 3が事実上の策定完了も参照ください。

勧告案の時には主にCSS Writing Modes Level 3が勧告候補(Candidate Recommendation)になった後の仕様に関することについて記しましたが、今回はブラウザーの実装をごく簡単に振り返ってみたいと思います。

Can I Use...でも、もはやたどることができない程度に古い話ですが、初めてWriting Modesが実装されたのは、2000年7月に公開されたInternet Explorer (IE) 5.5のことでした(当時のニュース:窓の杜 - 【NEWS】Internet Explorer 5.5英語版の正式版がリリース)。あまりにもIE6の時代が長かったこともあり、すっかりIEへの負のイメージが定着しているようにも思えますが、当時としては先駆的な試みがなされていたと思っています。

一方でこれもまた古い話ではありますが、Netscape Navigatorの後続となるMozilla Firefoxは、2015年9月にリリースされたバージョン41になってようやく、リリース版(ベータ版ではない)に実装されました(Firefox 41 for developers - Mozilla | MDN)。

なぜここまで両者の実装時期に差が出たのでしょうか。これはIE 5.5はまだ仕様がCSS Writing Modes Level 3という名前ですらなく、仕様の内容が固まっていないうちに実装した一方で、Firefoxはある程度仕様が固まった、勧告候補(Candidate Recommendation)となってから実装したという、両者の仕様に対するスタンスの違いがあったためと言えるでしょう。逆説的に捉えるならば、Firefoxが実装をし始めるということは、ある程度仕様が固まっている状況にある、と捉えることができるでしょうか(もちろん、すべてに当てはまるわけではないですが)。

さて、CSS Writing ModesはLevel 3はW3C勧告となりましたが、これで仕様の策定が終わったというわけではありません。すでにCSS Writing Modes Level 4の策定が進められています。ここでは、Level 3で安定性に欠けるとして削られたいくつかのプロパティ(値)が再導入されています。わかりやすいものではtext-combine-uprightプロパティの値digitsでしょうか。これは、MDNの説明にあるとおり、指定した桁数(整数値)までの連続したASCII数字を水平に並べてボックス内に収めるものです(text-combine-upright - CSS: カスケーディングスタイルシート | MDN)。今後どのように進展していくのか、見守っていきたいところです。

a11y.cssによるマークアップの品質チェック


取締役 木達

この記事はミツエーリンクスアドベントカレンダー2019 - Qiitaの25日目の記事です。

「アリックス」と発音するそうですが、a11y.cssという名前の、一種の品質チェックツールについてご紹介します。

a11y.cssの概要

accessibilityの省略表記として「a11y」という表記が英語圏を中心に根づいている昨今、あたかもアクセシビリティ品質に特化したチェックツールかと思われるかもしれませんが、そういうわけではありません。アクセシビリティに関わるものを含め、マークアップに潜むリスクや間違いを指摘するものです。

Firefox用のアドオンChrome用の拡張のほか、後述するレベルと言語(英語のほかロシア語、中国語、アラビア語、ポルトガル語、ギリシャ語が選択可能)を組み合わせて生成するブックマークレットから使用することができます。

指摘の対象はエラー(Errors)、警告(Warnings)、時代遅れ(Obsoletes)、アドバイス(Advices)という4つのレベルに分類されています。数がやや多いのですが、本稿執筆時点の最新版において、どんなマークアップを指摘するか列挙します(リンク先はそれぞれ、英語で書かれた公式サイト上の解説です):

エラー

「a11y.cssによるマークアップの品質チェック」の全文を読む

ReactHooksを利用したCRUDアプリケーションを作成してみる


UI開発者 森崎

この記事はミツエーリンクスアドベントカレンダー2019 - Qiitaの24日目の記事です。

React v16.8.0で正式にHooksが導入されましたね。

ReactHooksはstate、context、ref、ライフサイクルなどReactで扱うには少々非効率的であったAPIを、シンプルで扱いやすい形に置き換えたような機能です。

各hookの機能は公式サイトに詳細が記載されていますが、本稿では1つのアプリケーションの中で実際にどのように組み込まれ、機能するのかをTODOリストの作成という形で試してみたいと思います。

「ReactHooksを利用したCRUDアプリケーションを作成してみる」の全文を読む

初学者なりに保守しやすいスタイルシートや命名規則について考えてみる


UI開発者 工藤(皐)

この記事はミツエーリンクスアドベントカレンダー2019 - Qiitaの22日目の記事です。

運用案件で気づけた保守性の重要さ

他の人が記述したスタイルシートを編集した際、思い通りのスタイルにならなかったり、思い通りにいかない理由が予測できない...といった問題に直面したことがありませんか?
つい最近、私自身もこのような場面に見舞われ、かなりの時間を費やしてしまったことがありました。
どうすれば「誰が見ても理解のしやすいスタイルシート」を作ることができるのか、UI開発者として半年間、制作現場で過ごしてきて見えてきたことがあります。それは、スタイルシートは「保守性」を最優先に考えて設計を行うべきだということです。そもそも保守性とは、管理や維持のしやすさを表します。スタイルシートの保守性が低ければ、サイトの運用がしづらくなり、保守性が高ければ運用のしやすさが各段に上がります。実際の案件を通じて、初学者なりに保守性の重要さに気づくことができました。
それでは、「保守性」を高めていくためにはどのような方法が考えられるのか、調べてまとめてみましたので、最後まで読んでいただければ幸いです。

「初学者なりに保守しやすいスタイルシートや命名規則について考えてみる」の全文を読む

@pika/webを使って.vueファイルをwebpackなしで使ってみる


UI開発者 板垣

この記事はミツエーリンクスアドベントカレンダー2019 - Qiitaの21日目の記事です。

みなさんは@pika/webをご存じでしょうか。
@pika/webを使うと、コマンド1つでnpmパッケージとそのパッケージのESM依存関係にあるパッケージをローカル上にインストールして、それらをブラウザで直接実行できるようにようになります。
つまり、これまでwebpackやrollupなどのバンドルツールで行ってきたESMの依存関係解決を@pika/webが担ってくれるのです。
詳しいことは公式の説明を見ていただくとして、この@pika/webを使うとVue.jsの単一ファイルコンポーネント(以下、SFC)を簡単に使うことができると目にしたので、今回はその方法をご紹介します。

※@pika/webはバージョン1がリリースされる際に「Snowpack」という名前に変更されることがGitHubでアナウンスされていますので、気になっている方はご注意ください(現時点でのバージョンは0.6.1)。

「@pika/webを使って.vueファイルをwebpackなしで使ってみる」の全文を読む