00:05
はい、7月10日、時刻は朝9時を回りました。
昨日はすみません。ちょっと体調がどうしても悪くてですね、
頭痛も吐き気もちょっとひどくて、朝活をさぼってしまいました。
はい、おはようございます。めめめのkeethことくがはらです。
では本日から、また朝活を再開していきたいかなと思います。
はい、本日の朝活ですけども、タイトルにあるとおりですね、
Archive Content Roundup from TokyoのVolume368をダラダラ読んでいこうかなと思います。
はい、今回はですね、10個の記事がピックアップされているので、
一個一個まずはその10個の記事のタイトルと概要を読んでいこうかなと思います。
はい、1つ目ですね。
Mobile-First CSS- Is It Time for a Rethink?
というところで、Mobile-First CSSを考え直すときじゃないでしょうかという記事ですね。
Mobile-First CSSというのは優れた設計アイディアではあるんですけど、デメリットもあります。
この記事ではアプローチの問題点を指摘しながら、
ベタな設計のアイディアというのを講座していきますということでした。
はい、これが1つ目です。
2つ目の記事はThe Collapse of Complex Softwareです。
複雑なソフトウェアの崩壊というふうに言ってますね。
なかなか強いタイトルだなと思いました。
はい、概要はローマ人、マヤ人、チャコ人の優れた文明が滅びたのなぜかというと、
一説ではその社会の複雑さに起因しているというふうに言われています。
ソフトウェアについても同様な状況が起きていると考えることができます。
レガシーなシステムを修正するために、
安易に新たな要素を追加しまうことはよくあることであり、
その結果複雑さがさらに増加していくと。
そしてそれを捨てて、新たなゼロから設計するときが訪れます。
こういったソフトウェア設計のライフサイクルについてちょっと考察を深め、
それに対してどのように向き合っていくべきかというのを考察しようかなというところでした。
はい、計算ですね。
おはようございます。
ご参加いただきありがとうございます。
タイトルにある記事の、まず今10個の記事を打った後、
概要とタイトルを読んでいます。
はい、続いて、
For trade-offs when designing navigation menus
ナビゲーションを実装する際の4つのトレードオフについて紹介をしようという記事ですね。
1つ目が全てのトピックを表示するか、重要なものだけを表示するか。
2つ目は新規ユーザーを中心にデザインするか、
頻繁に使用するユーザーを中心にデザインするか。
3つ目が単一の目的かもしくは複数の目的か。
最後4つ目ですね。
ユーザーが実行できるものを表示するか、それとも絶対表示するかというトレードオフを考えましょうということでした。
はい。
4つ目の記事ですね。
Re-evaluating technologyです。
テクノロジーを再評価する時の。
こちらの概要は、
FlashというのはWebより優れていました。
しかし時間が経つにつれてWebは追いついてきました。
現代ではこのFlashの役割はネイティブアプリ化になっていると考えることができます。
Webの技術というのは日々飛躍的に進歩しており、
あの時にネイティブアプリが優れていると判断されていたものを再評価する時が訪れているかもしれませんというところでした。
うん、ちょっと気になります。
03:01
はい、では5つ目の記事です。
SQLiteとWeb、読めないですね。
リネセサンスというものですかね、これは。はい。
エッジコンピューティングとSQLiteの相性について紹介します。
現在のエッジコンピューティングにはSQLiteが非常に組み合わせが良いということを紹介していますということでした。
はい、残り記事インプリーフですね。
6個目です。
コンポーネントエンサイクルメディアですね。
ストーリーブック製のコンポーネント108点の紹介です。
こちらについては何回か忘れましたけど、数回前に自分も読んだことがあるので割愛しますね。
ストーリーブックが公開しているコンポーネント108点そのままですね。
だいたい5132個でしたっけ、数字を合わせました。
5000個以上のコンポーネントの108点が載っていて、
それはストーリーブックが作っただけではなくて、
いろんな企業、世界的な企業がこういうコンポーネントを作ったというのをストーリーブックに共有しているという感じですね。
その後、多分ストーリーブック社の中の人がそれをピックアップ、
選定して選んだやつが5000個載っているという感じなので、
困ったらここを見てもらって、自分の作りたいアプリケーションとか
ウェブのアプリケーションに組み込んでもらえればいいんじゃないかなというところでした。
次で7個目ですね。
Simplify Your Color Palette with CSS Color Mix Smashingか。
CSSで色を混ぜることができるカラーミックスメソッドの仕様について紹介してみますよということでした。
で、8つ目の記事です。
The Case for Prisma in the JAMstackということですね。
JAMstackにおいてプリズマがいかに有効にワークするかというのを解説します。
で、9つ目。
The Smallest CSSですね。
HTMLをきれいに見せるために必要最低限のCSSについてちょっと考察してみましょうと。
これもちょっとギリなのかな。
で、ラスト10個目ですね。
Private Access Tokens Stepping into the Privacy Area Respecting Capture-less Features We Were Promisedということで、
キャプチャーなしで認証を行うための技術使用についての解説をしていますというところでした。
以上10個ですけども。
今回読む記事はちょっと気になったのはやっぱり冒頭2つですね。
The Collapse of Complex Softwareで複雑なソフトウェアの崩壊技術と、
Re-evaluating Technologyですね。
テクノロジーを再評価するときとか気になります。
もう1個冒頭のMobile First CSSですね。
Mobile First CSSを考え直すときっていうところも個人的には気になるんですけど、
どれ読もうかな。3つあって。
たださっき言った複雑なソフトウェアの崩壊、テクノロジーを再評価するときっていうのは、
ちょっと似た話な気もしなくはないが、ネイティブアプリの話は違う気がするんで。
ソフトウェアの崩壊の方から行こうかなと思いますので、
今日読むのはMobile First CSSを考え直すときっていうものと、
複雑なソフトウェアの崩壊ってこの2つを読んでいこうかなと思います。
ちょっと長いかもしれないので2つとも読めないかもしれないですけども、
06:02
1個1個言っていきたいかなと思います。
では1つ目の記事から。
いつも通り翻訳するのでちょっとお待ちください。
はい、来ました。
じゃあ行きましょう。
Mobile First CSS is it time for a rethink?
Mobile Firstのデザイン手法っていうのはユーザーにとって本当に重要なものに焦点を当て、
よく実装され、何年も前から一般的なデザインパターンとして使われています。
ですからCSSをMobile Firstで開発することも非常に素晴らしいことだと思っています。
それについてちょっとちょっと記事に入っていくところですね。
しかし必ずしもそうではないということが言えますと、
Mobile FirstのCSS開発っていうのはスタイル宣言の上書きの原則に基づいています。
CSSをデフォルトのスタイル宣言で開始をして、
より大きなビューポート用の最小幅のメディアクエリでブレークポイントが追加されるとき、
新しいスタイルを上書きまたは追加します。
これについての概要の記事、
What is the Mobile First CSS and why does it look?
ということで記事も一応書いてて、そこを見てくださいって言ってますね。
Mobile First CSSとはなぜそれが重要なのかっていう記事を別で書いてるんで、
詳しく見たい方はそこを見てくださいってことでした。
しかしこのような例外というような複雑さと非効率性を生み、
その結果テストの増加とコードベースの維持っていうのが困難になる可能性がありますと、
それを望んでいる人はどれだけいるでしょうかというところですが、
残念ながらCSSっていうのは後勝ちで動いていくっていうのが、
もう絶対的なルールでありますので仕方ないと思います。
メディアクエリってのは基本的に上書きをしていくものだっていうのは、
そういうCSSの手法に乗っかるしかないのでっていうところがありますね。
しかしその前にビジュアルデザインやユーザーとのインタラクションに照らして、
Mobile FirstのCSSがどの程度適切かっていうのを評価する必要はあります。
ここではMobile Firstがあなたのプロジェクトに合わない場合の
大体案について説明していきましょうというところでした。
では一個ずつセクションに入っていきますね。
一つ目のセクションはAdvantage of Mobile Firstです。
まずはMobile Firstのメリットってところですね。
Mobile FirstのCSS開発にはいくつかの利点があって、
なぜそれが長い間事実上の開発方法であったのかっていうのを、
非常に理理にかなっているよっていうところを話していこうと思います。
一つ目ですね。一つ目はDevelopment Hierarchyです。
開発階層という言葉を使われていますね。
Mobile Firstの利点の一つは開発階層がより明確であるよと言っていますね。
続いてTried and Testedというところですね。
いわゆる試行錯誤というところですね。
長年にわたって試行錯誤を繰り返してきた方法論にはやっぱり理由があるよというところも言っていますね。
三つ目がPrioritize the Mobile Viewsですね。
モバイルビューティーを優先するというところです。
モバイルビューティーは最もシンプルで間違いなく最も重要ですと。
なぜなら全ての主要なユーザージャニーを網羅し、
09:00
多くの場合ユーザーフォームの高い割合を占めるからですと。
それはプロジェクトのことになりますけどと言っていますね。
今はみんなモバイルでウェブにアクセスしたりアプリケーションを使うのはデフォルトですから。
最後ですね。四つ目はPrevent Desktop Center Developmentですね。
デスクトップ中心の開発を防ぎましょうというところですね。
開発というのはデスクトップコンピューターを使って行われるため、
当初はデスクトップの表示に集中したくなることがあります。
しかし最初からモバイルについて考えておけば
後で行き詰まるということは少なくともないですよね。
デスクトップ中心のサイトをモバイルデバイスで動作するように回収することに
時間を費やしたいと思ったままはそもそもいないでしょうというところで
今のがモバイルファーストで考える四つのメリットでした。
じゃあアドバンテージを語ったので次はディスアドバンテージをモバイルファーストですね。
じゃあデメリットです。
スタイル宣言を設定し、より高いブレークポイントで上書きすることで
望ましくない影響が出る可能性もありますと言っています。
一つ目です。
モアコンプレキシティということで、複雑さが増しますよねと言っていますね。
ブレークポイントの階層が上がるほど、
階のブレークポイントから不要なコードを継承することになります。
これは基地の事実ですね。
二つ目。
Higher CSS Specifyということで
Specificityですね。
ちょっと英語を言うわけですみませんね。
CSSの得意性というのは高くなりますよと言っています。
クラスメイド宣言でブラウザーのデフォルト値に戻されたスタイルというのが
より高い得意性を持つようになります。
これは大規模なプロジェクトでCSSセレクターをできるだけシンプルに保ちたい場合に
普通の他になることがあります。
これもそうですねということです。
三つ目はRequires More Regression Testingですね。
より多くのリグレッションテストが必要とします。
KyViewでのCSSの変更、
より新しいスタイルの追加などには
全ての上位ブレークポイントのリグレッションテストが必要になりますよねと言っていますね。
それもそうね。
ラスト四つ目ですね。
The Browser Can't Prioritize CSS Downloadですね。
ブラウザーはCSSのダウンロードに優先順位をつければできないようできます。
より広いブレークポイントでは、
従来のモバイルファーストの最小幅のメディアクエリというのは
CSSファイルを優先的にダウンロードするブラウザの機能を活用できませんと。
なるほどですね。
それはブラウザは確かに判断はできないですね。
こちらから細かく命令できればいいかもしれないですけどね。
今のところそんな機構はないですからね。
はい、はい、はい。
なるほどでした。
今、利点欠点というのを一回見てみました。
続いて、The Problem of Property Value Overwriteですね。
プロパティ値の上書きの問題点というのを語っていきましょう。
CSSはそんなように設計されていますので、
値を上書きすることは本質的に悪いことではないと言っています。
しかし不正な値を継承することは全然有益ではないですし、
負担が大きく非効率的な場合がありますと。
12:02
またスタイルを上書きしてデフォルトに戻す必要がある場合、
スタイルの特殊性が増しまして、
特に特注のCSSとUTTクラスを組み合わせて使用している場合は、
後で問題が発生する可能性があります。
CSSには確かに秘伝のタレじゃないですけど、
特別なスタイリングするのは仕方ないところはありません。
より高い得意度でリセットされたスタイルに対しては
UTTクラスを使用することはできなくなります。
それもおっしゃる通りです。
この点を考慮して、
最近はデフォルト値を重視したCSSを開発することが多くなっています。
特に順番もなく、具体的な値の連鎖もないので、
ブレークポイントを同時に開発することができるようになりました。
私は当時と同じメディアクエリの範囲、
つまりマックスウィズや設定されている範囲などにおいて、
共通のスタイルを見つけ、特定の例外を広げることに集中しています。
いいですね。
むしろそういうことをしてくれる人がいるっていうのは
めちゃめちゃチーム内としてはありがたいと思います。
このアプローチでは、
各ブレークポイントを白紙の状態として見ることができるため、
いくつかの可能性が開きます。
コンポーネントのレイアウトが全てのブレークポイントで
Flexboxに基づいているように見える場合は、
それは問題なくデフォルトのスタイルシートでコーディングすることができます。
しかし、大画面にはグリッドだったり、
モバイルにはFlexboxが遥かに適しているようであれば、
CSSを閉じたメディアクエリの範囲に入れると、
これらは両方とも完全に独立して行うことができます。
大画面にはグリッドだったり、
モバイルにはFlexboxが遥かに適しているようであれば、
CSSを閉じたメディアクエリの範囲に入れると、
これらは両方とも完全に独立して行うことができます。
メディアクエリで、大画面系だとグリッド、
細かい範囲はFlexboxにしてしまえば、
同じメディアクエリを使ったとしても、全然使うCSSが違うので、
しっかり分離できているということを言っている。
考えたことなかったな。
確かに大画面だったら、むしろグリッドの方がやりやすかったりしますからね。
フレックスボックスは確かに小さいモバイル画面だと、
基本的にフレックスボックスというのは方向性だけを重視して
スタイリングしていくんですけれども、画面が小さいですし、
基本的には縦にスクロールするか横にスクロールするかというのが
モバイルの使い方の主目的としてある使い方なので、
確かにフレックスボックスの相性はいいですね。
うわ、ちょっと考えたことなかったな。これはありがたいですね。
はい、すいません。戻ります。
また、同時開発では、
同時開発というのは多分モバイルとPC両方ということかな。
2Dのコンポーネントは全てのブレークポイントで
前もってよく理解しておく必要があります。
これにより開発プロセスの早い段階で、
デザインの問題点を表明化させることができます。
モバイル用の複雑なコンポーネントを作って、
うさぎの穴にはまり、
うさぎの穴ってなんだ?
ちょっとこれは新しい例だな。
デスクトップ用のデザインを手に入れたとしたら、
同じように複雑でモバイル表示用に作成した
HTMLと互換性がないことについた、
15:00
みたいなことを避けたいものですね。
それもそうだよね。
理解しないままガッとやっていったら
後で困るな。よくある話ですね。
モバイルとPCの表示どうしたらいい?
っていうのはありますからね。
基本的にモバイルのHTMLとPCのHTMLというのは
互換性そんなないと思います。
全然見た目違いますし、
そもそも画面の幅が近いすぎるので。
この方法っていうのは
全ての人に合うわけではありませんが、
ぜひ試してみてください。
レスポンシブリアップやブリスクなどの
同時並行開発を支援するというツールが
たくさんありますよと。
初めて来ました。
レスポンシブリアップとブリスクっていう
ツールが世の中にあるんですね。
ちょっと後でパラッと見てみて
ふーんってツイートしてみようと思います。
とはいえ、
順番自体は特に関係ない気がします。
モバイルビューに集中することに
抵抗がなく、
他のブレークポイントの要件も
よく理解していて、
一度に一つのデバイスで
作業することを好むのであれば、
ぜひ古典的な開発手段に
開発順序にこだわってみてくださいと。
重要なのは、
共通のスタイルと例外を特定し、
関連するスタイルシートに
反映させることですと。
手作業でツリーを揺さぶるようなものですよね。
こういうのはって言ってます。
個人的にはブレークポイントをまたいで
コンポーネントを開発する場合、
この方が少し楽だとは思いますが、
これは決して必要条件ではないよとも
言ってますねと言ってました。
ブレークポイントをまたぐのであれば、
それは確かに古典的に一遍に
やったほうがいいというのは分かります。
ブレークポイントごとにしっかり
作業とかも分離していて、
そこでやるのであれば、
さっき言ったように
分けたほうがいいかもしれないですね。
なかなか面白い議論だな。
続きまして、
次のセクションですね。
次はクローズドメディアクエリレンジ
インプラクティスということですね。
当時のメディアクエリレンジの
実際のプラクティス的なところを
見ていきましょうと言ってます。
古典的なモバイルファーストCSSでは
スタイルを上書きしてしまいますけれども、
メディアクエリ範囲を使用することで
これを回避することもできます。
違いを説明するために、
簡潔にするために
SCSSというコードを使っています。
ソースコードが、
ここからちょっとコード出てくるんですけど、
基本的にはSCSSを使ってますよ
簡潔にするために
3つのビジュアルデザインがあると仮定しますと。
その3つっていうのは、
メディアクエリをよく使う
ウィッドですね。
幅の話です。
1つはsmaller than 768ということで、
768ピクセルは小さいよと。
続いてfrom 768 to below 1024ですね。
768以上、1024以下ですかね、これは。
最後、1024 and anything largerですね。
1024とそれ以上ということを言ってます。
ブレークポイントは768と1024で、
それより小さいか、
768以上、1024以下と最後、
1024以上とそれ以上か。
18:02
なので1024以下っていう真ん中は
より小さいな気がしますね。
とそれ以上と言ってます。
ブロックレベルの要素のデフォルトのパディングが
例えば20ピクセルで、
タブレットでは40ピクセルに上書きされ、
デスクトップでは20ピクセルに戻される
という簡単な例を見てみましょうと。
デフォルト20ピクセル、
タブレットで40ピクセルで、
最後デスクトップでは20ピクセルに戻される
っていうようなパディング。
なかなか聞いたことないけど。
スマホで20ピクセル。
スマホというか特に指定なければ
基本は20ピクセル。
タブレットで40ピクセル。
つまりスマホは考えてないってことか。
そうですね。
768から1024だからタブレットですね。
で、いきますと。
クラシックMinWidthモバイルファースト
って言っていきますと、
モバイルファーストのMinWidthの
クラシックなCSSのスタイリングでいくと、
例えばMyBlockというところに
デフォルトでパディング20ピクセル
というのを書いておきます。
その下にメディアクエリを付けておいて、
AddMediaのかっこMinWidthのコロン
708ピクセルと書いておきます。
で、その中にパディング40ピクセル。
もう一回AddMediaのMinWidthの
1024ピクセルと書いておいて、
この場合はパディング20ピクセル
という風にまた戻すって感じですね。
で、これをクローズドメディアクエリレンジで書くと、
また同じようにMyBlockっていうクラスの中に
とりあえずデフォルトでまた
パディング20ピクセルと書いておいて、
で、続いて書くときはAddMediaですね。
その中にかっこMinWidth768ピクセル
&かっこMaxWidth1023.98ピクセル。
1023.98ピクセル。
あ、そんな書き方する。
で、パディング40ピクセルという風に書くようですね。
クローズドメディアクエリレンジなので、
確かにメディアクエリの範囲ですね。
どこ以上、どこ以下みたいなとこ書くときに
MinWidthの方の&MaxWidthで挟むってやつですね。
これ確かによくやる書き方だと思いますけど。
古典的な書き方でいくと
MinWidth768と書いておいて、
あとでまたMinWidth1024ってわざわざ別々に書く
っていうような書き方をするらしいですね。
僕逆に古典的な書き方を
書いたことなかったので今初めて知りました。
こう書けるんやっていう感じですね。
はい、すいません戻ります。
で、微妙な違いっていうのは
Moyerhurstの例では
デフォルトのパディングを20ピクセルに設定してから
各ブレイクポイントで上書きし、
合計で3回設定していることですね。
2番目の例では
デフォルトのパディングを20ピクセルに設定しておいて
デフォルト値でない関連するブレイクポイント
この場合ではタブレットだけ例外なので
そこについてのみ上書きをしています。
目標っていうのは次の通りです。
必要なときだけスタイルを設定します。
あとで何度も上書きすることを想定して
スタイルを設定しないことです。
そのためにはメディアクエリの範囲を
1回閉じておくことがまず便利ですね。
任意のビューに変更を加える必要がある場合
特定のブレイクポイントに適用される
CSSのメディアクエリ範囲に変更を加えます。
これによって不要な変更を加える必要性がなくなり
リクエストのテストでは
実際に編集したブレイクポイントのみに
焦点を当てればよくなります。
おっしゃる通りですね。
21:01
続いて、上記の例でデスクトップの
MyBlockというクラスです。
そこの間隔がそのブレイクポイントの
マージンで既に説明されていることが
分かった場合は
パディングを完全に削除したいので
閉じたメディアクエリ範囲に
モバイルパディングを設定することによって
これを行うこともできますよと言っていますね。
間隔が既に説明されているのが
分かっている場合は
パディングを削除したい。
確かによくある話ですね。
その場合は.MyBlockと書いておいて
その下にあるメディアクエリの
MaxWidthで
767.98ピクセルですね。
なんで0.02ピクセルで指定するんだろう。
767。
なんでだろう。
穴の開いた0.02ピクセルの範囲
どうするんだろうと
ちょっと気になりますけど。
一旦AtMediaのMaxWidth
767.98ピクセルで書いておいて
その中にパディング20ピクセルを書きますと。
とにかく767.98ピクセルより小さい場合は
パディングは20ピクセルになって
AtMediaのMinWidth768ピクセル
&MaxWidth1023.98ピクセルの場合は
パディング40ピクセルと書いておくと。
うまくクローズメディアクエリレンジ
というのを書いておけば
別にいいですよと言ってますね。
このブロックのブラウザの
デフォルトのパディングは0なので
デスクトップのメディアクエリを追加して
パディングの後に
アンセットまたはゼロを使用する代わりに
モバイルファーストではそれが必要ですよと言ってますね。
アンセットとかゼロとする必要がありますけど
モバイルのパディングを
閉じたメディアクエリでラップして
現在は例外であるため
広いブレークポイントで
拾われないようにすることができますよと。
デスクトップのブレークポイントでは
ブラウザのデフォルト値を使用するため
パディングのスタイルは特に
設定する必要もありませんよと言ってますね。
これはその代わりあれですね
デフォルト値をちゃんと
最初から指定しているとか
理解できているという認知できている
という意味ではこの仕様が使えますけど
そうじゃない場合はちょっと微妙ですよ
というところはありますね。
あとデフォルトって
基本的にリセットシステムの
何かを使うと思うので
その値がちゃんと分かっているか
というところが結構重要ですね。
じゃない限りはやっぱりデフォルト値の
一旦パディング20ピクセルつけてから
例外でタブレットだけ
端折るというほうが
僕はいい気はしますけどね。
みんながちゃんと理解できているのであれば
何も問題ない。
開発者みんなが認識できていて
それを前提に開発できているという
環境はそんな多くはない気がしているので
はい。
これが基本以上がありますよということでした。
気になるのはその0.02ピクセルの
微妙な差で埋めているのは
ちょっと分からないですね。
このブラウザのデフォルト値で実は
768ピクセルって書いているけど
実は微妙に
0.2ピクセルずれているとか
という話だったら
全然違う話が出てくるので
ここはちょっと調べてみたいですね。
はい、続いていきます。
続いてですね
バンドリングバーシュ
バーシュって読むのかな。
バースス
スパレティングザCSS
24:01
CSSのバンドルと分離の比較
はい。
いきましょう。
その昔ブラウザの同時リクエストの
数の制限というのが
通常6件程度のため
リクエスト数を対象件に押さえることが
非常に重要でしたと。
昔はバンドルしなくて
一個一個確かにインポートしましたから。
そのため画像のスプライトとか
CSSのバンドルが一般的で
全てのCSSを一つのスタイリッシュとして
最優先で一括して
ダウンロードするようになっていましたと。
HTTP2やHTTP3というのが
登場した現在では
リクエスト数は以前ほど
大きな問題ではなくなりましたと。
そのためメディアクエリによって
CSSを複数のファイルに分離することが
できるようになりましたよと。
これにより明確なメリットというのは
ブラウザが現在必要としているCSSを
そうでないCSSよりも高い優先度で
リクエストできるようになったことですと。
これは大きいですね確かに。
これによってパフォーマンスが向上し
ページのレンダリングがブロックされる
全体の時間というのを結構
短縮することができるようになりましたよと。
ブロック時間が結構減りましたよということですね。
細かいセクションですね。
Which HTTP version are you using?
使用しているHTTPのバージョンはいくつですか?
というのが入っています。
どのバージョンのHTTPを
使用しているかを確認するには
ウェブサイトにアクセスし
ブラウザの開発ツールを開いてください。
次にネットワークタブを選択して
プロトコル列が表示されていますので
その中のプロトコルの下に
H2というのが表示されていれば
HTTP2で表示されていることを意味します。
これは画像をちょっと見てもらう
しかなくなりますねこれは。
今記事的には画像が張ってあるんですけど
そういうふうに開発ツールの
ネットワークタブを見てくれればいいと思います。
注意としてブラウザの開発者ツールで
プロトコルを表示するには
ネットワークタブに通して
ページを再読み込みして
任意の列ヘッダーというのを
例えば名前というのを右クリックして
プロトコル列を確認する
必要があります。
HTTP2を使っているか
ツールを使っているかというのは
一応確認したほうがいいですけど
基本ツール以上であればいいなと思いますね。
またですね。
alsoですけど
あなたのサイトがまだ
HTTP1を使用している場合は
いやマジなんで?
というふうに言ってますね。
HTTP2には優れたサポートがあるので
理由もなくとにかく
HTTP2以上に上げろ
というふうに言ってます。
急に外国人とこの辺で
強い言葉を使うのが面白い。
次ですね。
Splitting the CSSです。
CSSを分割しましょう。
CSSを個別のファイルに分割することは
価値のある作業であるよと言ってます。
個別のCSSファイルというのを
関連するメディア属性でリンクすると
ブラウザはどのファイルがすぐに必要で
レンダーブロックを引き起こすためですね。
どのファイルを後回しにできるかというのは
識別できるようになります。
これに基づいて
各ファイルに適切な優先順位が
割り当てられますと言ってますね。
次のモバイル用のブレークポイントに
アクセスしたウェブサイトの例では
モバイル用とデフォルトのCSSが
最も高い、ハイエストの優先度で
読み込まれていることが
確認できますと言ってますね。
残りのCSSファイルですね。
例えば印刷物だったり
タブレット、デスクトップというのは
後で必要になる場合に備えて
27:01
まだダウンロードされていますけども
優先度は最低、ローエストになってますよね。
これを画像を見てますけども
こちらもさっきと同じように
ネットワークタブを開いて
多分アセット周りのところのファイルを
今見てるんですけど
その中に確かにプライオリティという属性があって
そこを見てますね。
ハイエストかローエストかというのを
判断してますというところでした。
CSSを個別のファイルに分化しておけば
そういうところの設定もできるようになるし
細かくやれるので
優先順位というのを各ファイルごとに
適切な優先順位を割り当てることができるよ
と言ってますね。
問題はバンドルをする現在の
バンドルCSSの話を
ここからしてくると思うんですけど
CSSがバンドルされてる場合ですね
ブラウザーはCSSファイルをダウンロードし
レンダリングを開始する前に
それを解析する必要がありますよね。
パスしますよね。
一方前述のように
CSSを別のファイルに分割してリンクし
関連するメディア属性でマークアップすることで
ブラウザーは現在必要なファイルを
優先的に表示することができます。
メディアクエリの範囲を閉じて使用すると
ブラウザーはすべての幅で
これを行うことができます。
従来のモバイルファーストの最小幅クエリでは
デスクトップのブラウザーが
最優先で全てのCSSを
ダウンロードしなければならないのとは
結構対照的になりますよね。
デスクトップユーザーが常に
高速な接続環境を持っているとは
もちろん限りません。
例えば多くの地方で
ローカルのところでは
インターネット接続の速度が
まだまだ遅いという現状もあるので
どうなんだろうという話がありますね。
メディアクエリというものや
個別のCSSファイルの数というのは
プロジェクトの要件に応じて
もちろん異なるんですけど
以下の例に近くなる可能性はありますと
言っていますね。
これどこまで訳したんだ。
ここでバンドルされたCSSと
セパレートされた分割されたCSSの
具体例が記述ありますと。
バンドルされたCSSというのはもちろん
リンクのhref、例えば
separate.cssみたいなものになっていますね。
1個しか読み込まれませんよねと言っています。
この1つのファイルには
全てのメディアクエリも含む
全てのCSSが含まれていて
もちろんこれが最優先でダウンロードされます。
次にセパレートCSSというのはもちろん
セパレートされているので
例えばリンクhrefの
デフォルトCSSの読み込んでおいて
ついにモバイルCSSを読み込んだり
モバイルCSSを読み込むときに
リンクのタグの
メディア属性の方で
スクリーン&マックスウィーツ
ホゲホゲみたいなことを書いたりして
読み込むことができる。
こんな書き方があったんですね。
僕初めて知りました。
リンクタグの属性の中に
メディア属性を付けて
その中でスクリーン&マックスウィーツ
ホゲホゲみたいな
メディアクエリを指定できるんですね。
いやーちょっとCSS知らなすぎた。
ちょっと恥ずかしいな。
こういうのをやっといて
画面幅と必要なCSSというのを
ここで優先順位を割り当てる
ということができるんですね。
こういう古典的な書き方があったんです。
これは初めて知りました。
いわゆるメディアクエリごとに
30:00
1個1個CSSを分割したものを
リンクタグで書いておいて
それを1個1個読み込んでいく
ということをするんですね。
こうCSSを分けておくことで
分離することで
各リンクタグにメディア属性の値を指定して
ブラウザが現在必要としているものを
優先的に表示させることができます。
今回のRAIDは5つのファイルを読み込んでます。
デフォルトとモバイル
タブレット
いわゆるPC
最後にプリントという印刷系のため
5つのCSSファイルのうち
デフォルトファイルと
現在のメディアクエリにマッチするファイルの
2つが最も高い優先度でダウンロードされて
他のファイルは
最も低い優先度でダウンロードされます。
なので後ほど
リファー的に
読み込みが行われるかなという感じです。
プロジェクトの展開戦略によっては
1つのファイル
モバイルCSSなどを変更するだけで
QAチームというのは
その特定のメディアクエリの範囲内の
ファイルだけで
リグレッションテストを行う必要があります。
これを単一のバンドルされた
サイトCSSみたいな
僕らだと結構バンドルCSSかもしれないですけど
というファイルを展開するアプローチで比較すると
通常は
完全なリグレッションテストが
発生することになりますよねと言ってます。
これはこれまたどうなんだろう
って感じはしますけど
ちょっと僕はこれやったことないんで
これやった場合って
ネットワークとか
読み込みのタイミングとか
いつどのファイルをやるかっていうのが
結構気になったりします。
画面をブロックしないんであれば
別にこういう書いてもいいなと思いますけど
結局読み込みが終わってから
レンダリングをするっていうんであれば
この書き方は結構悪手だ気がしますけどね。
いわゆる最優先のものだけ
読み込みをして
パースも終わって
レンダリングするんであれば
この書き方は全然いいんじゃないかと思いますね。
ちゃんく分け結構大変だったりしますので
ちゃんくうまいことガチャガチャやってるんであれば
全然
それでもバンドルしたやつでいい気はしますけど
さっき言ったように
例えばデスクトップのほうではグリッドで
モバイルのほうでは
タブレットのほうでは
それ専用の別のCSS
フレックスボックスを使ってますとか
切り分けられてるんであれば
この手法では全然刺さるんじゃないかな
って気はしました。
改めて考えるっていう点で
これを見直すのはいいかもしれないなと思いました。
最後のセクション
ムービングオンです。
移動するってところですね。
モバイルファーストCSSの導入っていうのは
ウェブ開発において実に重要なマイルストーンとなりました。
しかしある特定のデバイスを優先させると
物事が複雑になりやすく
効率も悪くなるっていう問題を
見失うようにすることがとても重要になります。
そのためにはCSSのものに着目し
何がデフォルトで何が例外なのかを
常に意識することが
次のステップへの自然な流れだと思います。
私自身はもちろん前の開発者の
他の開発者のCSSも
少しずつ簡素化されていくことに気づき
デスクトップやメンテナンスの作業も
少し簡略化され
精査性が向上しています。
一般にCSSのルール作成を
できるだけ単純化することは
オーバーライダーとの堂々巡りをするよりも
33:01
最終的にすっきりしたアプローチになるかもしれない
と言ってますね。
しかしどの方を選択するにしても
プロジェクトに合った方法を
選択する必要がもちろんあります。
モバイルファーストが最適かどうかは別として
まずはトレードフォーをしっかりと理解することは
とても重要ですよねってことを言って
締めておりますという感じでした。
はい、いやめちゃめちゃ良かったですね
この記事、とても勉強になりました。
最初にやっぱりアドバンテージと
ディスアドバンテージの話をしていて
その中で実際にどうしていこうかっていう
話をずっと展開していったんですけど
基本的にその後ですね
上書き問題についてもやっぱり
ちゃんと研究されていましたし
これはすごくいい記事だと思うので
ぜひ皆さんの方でも改めて読み直して
どういうことを思われるかっていうのを考えていただくのが
いいかもしれないなと思いました。
というところで、すみませんが
時間が来てしまいましたので
本当は読みたかった次の記事ですね
なんだっけ
The Corrupts of Complex Software
ソフトウェアの崩壊
っていう記事なんですけど
これそんな長くないんで
これも読みたかったんですけど
すみませんさっきの記事が長かったので
今回は割愛して
Twitterで読みたかった記事みたいなので
ツイートしようと思いますので
もし興味ある方は見てみてください
じゃあ長くなりましたけど
ご参加いただいた皆さんありがとうございました
日曜日のまた早いところから
またまたご参加いただけるとちょっと思ってなかったので
正直嬉しいです。
毎週日曜日のこの時間は本当に人が少ないので
ひたすら本当に一人でだらだら喋っているだけ
っていう時もあるので
本当にありがとうございます。
では本日も日曜日ですので
皆さん良い休日をお過ごしいただければなと思います。
ではこれで締めます。お疲れ様でした。
