社内向けに、フロントエンド関連のニュースや業務で発生したQ&A、利用しているライブラリなどの情報を定期的に書いています。
この記事は、社内の開発部メンバーに向けて直近でリリースされたライブラリなどの情報を不定期でまとめたものです。内容は実務や趣味で使えそうなものを中心に扱っており、網羅的ではなく偏りがあります。
普段の業務において、質問を受けた際の回答などで有益そうなものをピックアップしています。
ビューポートの幅が320pxのiPhoneで、フォーム画面のレイアウト崩れが発生していました。 具体的には、見かけ上は何も要素が存在しないのに、右側で空間が生まれている状態です。 フォーム画面には、テキスト入力に加えてセレクトボックスなど複数の要素がありますが、いずれの要素も適切な範囲に表示されており、余分な余白なども定義されていませんでした。
次のような手順で調査を行いました。
* {
border: 1px solid rgba(0, 0, 0, 0.02) !important;
background-color: rgba(0, 0, 0, 0.02) !important;
opacity: 1 !important;
}
この調査を行ったところ、Safariでのみセレクトボックスのコンポーネント内にある隠しInput要素の幅が368pxになっていることが分かりました。
隠しinput要素に明示的な幅を与えたり、親要素にoverflow: hidden
をかけるなどをすれば対処できます。そもそも置換要素に限らず、この辺りのスタイルを適切にかけるようにしていれば発生しない問題なので気をつけましょう。
置換要素であるinput要素は、特にスタイルをしなくても一定の領域を占有します。そのため幅があることはおかしくないですが、イメージとしておよそ100pxから200pxであり、368pxという値はあまりに大きすぎるような気がします。そこでなぜここまで大きくなっているのか調査しました。
隠しInput要素に適用されていたスタイルは、user agent stylesheetの除けば以下のような記述のみ行われていました。フォントによって置換要素の占有する領域が拡張されるのは直感的だと思います。
.hidden-input {
position: absolute;
pointer-events: none;
font: inherit;
}
試しにfont: inherit
を消すと、ChromeとSafari両方で横幅が147pxになりました。検証用のページを雑に作りChromeとSafariで比べてみました。結果は次の通りです。
Chrome 114 | Safari 16.1 | |
---|---|---|
user agent stylesheet | 147px | 147px |
font: 16px; | 175px | 202px |
font: “Noto Sans JP” | 162px | 230px |
font: 16px “Noto Sans JP” | 192px | 331px |
font: 16px “M Plus 1p” | 207px | 316px |
font: 16px “Roboto” | 168px | 178px |
Safariでは、日本語フォントを適用するとInput要素のデフォルトの幅がかなり大きくなることが分かりました。
置換要素の占有領域はそもそもブラウザ依存ですが、結果を見ると、ChromeとSafariではUA Stylesheetによるフォントの指定が異なるにも関わらずデフォルト147pxで共通してはいるものの、ChromeとSafariで逆転しているケースがあるなど、だいぶ異なるアルゴリズムで組まれていそうな気がします。
あまりこのようなケースに当たることはないと思うので、これ以上調べる気はないですが、他のフォントのケースはどうなるのか、どのような実装がされているのか調べると面白いかもしれません。
2023年3月公開のChakra UIのロードマップで紹介されていたPanda CSSが正式リリースされました。
Panda CSSは、今までのCSS in JSライブラリの集大成のようなライブラリです。
また公式ドキュメントを見れば分かりますが、多くのフレームワークでの利用が考えらており、それぞれのフレームワークについて、導入手順が丁寧に記述されています。
実際に小さなサービスで、Panda CSSへの移行を試してみましたが、かなり体験が良かったです。また使ってみて感じたこととして、Panda CSSの個々の機能は独立しており薄いので、将来的に他のライブラリへ移行する場合も楽だと思いますし、逆にPanda CSSへの移行も比較的楽なのでEmotionやstyled-componentsなどからZero RuntimeなCSSフレームワークへの移行を考えている場合、移行先としてかなり良いのではないかと思いました。
懸念点を上げるとすれば、レスポンシブ対応など複雑な記述をしようとすると独自の記述が出てくる点や、それについての公式ドキュメントの記述が若干少なく感じる点、様々な記述が可能なため派閥が生まれそうな点などでしょうか。
2023年6月22日に、Svelte 4がリリースされました。
https://svelte.dev/blog/svelte-4
Svelteはざっくり言うと、VueのSFCのような形式のsvelteファイルを、ライブラリのコードがほぼ含まれていないピュアな状態まで落とし込むコンパイラです。
Svelteを利用したWebアプリフレームワークとしては公式のSvelteKitがあり、Next.jsやNuxt.jsのような開発体験を得ることも出来ます。SvelteKit自体はViteのpluginとして実装されています。
Svelteを選択するメリットとして、他ライブラリやフレームワークを採用する場合と比べて、比較的少ない記述でアプリを構築できることや、お手軽に高いパフォーマンスを期待できることが挙げられると思います。
Svelte4ではメジャーバージョンは上がっていますが、目新しい機能があるわけではありません。コンパイラとランタイムを刷新する予定のSvelete 5に向けて、レガシーなものを切り捨てることが主な目的とのことです。パッケージサイズはおよそ75%削減され、依存パッケージも61から16個へ削減されています。
W3Cのウェブサイトがリニューアルして、だいぶ見やすくモダンな感じになりました。ソースコードはこちらから閲覧できる他、デザインシステムも公開されています。
MFWでは、基本的にBeta版の情報は扱わない方針ですが、興味深い機能があったので取り上げます。
Safari v17では、Webサイトをネイティブアプリのように扱うことができるWeb Apps機能が追加される予定です。ユーザーはアプリケーションを気軽にDocsに追加し、個別のアプリケーションとして利用できるようになるそうです。加えて、リリースノートで頑なにPWAという単語使われていない気がしますが、PWAの関連のWeb API機能追加も行われます。期待して待ちましょう。