00:05
はい、6月19日、日曜日ですね。
僕は浅草城を回りました。
本日の東京は結構いい天気ですね。
いい感じで晴れてます。
はい、おはようございます。
かぶし返しのゆめみのキースこと、桑原です。
では本日も朝活を始めていきたいと思います。
はい、ということで今日はですね、前回、
なんだっけ、WWDC22の
WebKit Features in Safari 16 Betaか、
っていう記事を読んでたんですけど、
その先のWeb Technologies for なんちゃらかんちゃらっていう、
そのWWDC22のSafariの記事、
Appleの記事ですね。
を続き読んでもいいと思ったんですけど、
ちょっと別の記事で気になっているものが見つかったので、
今日はそう読んでいこうかなと思います。
はい、主に2つですね。
タイトルにありとるんですけど、
1つはストーリーブックの公式ブログですね。
の中にあるコンポーネントエンクロサイクロペディアってやつですね。
僕、そもそもこれ何ぞやっていう名前すら知らなかったので、
ちょっと改めて勉強したいなと思いました。
で、もう1個はファーストクッキーレシピーズっていうのがあって、
僕クッキー周りもちょっと知識が曖昧だったとするので、
せっかくこうブログが出てたので、
それも読んでいきたかったっていう感じですね。
はい、じゃあ早速1つ目から入っていきたいかなと思います。
はい、コンポーネントサイクロペディアですね。
ストーリーブックを最近は全然触らなくなったので、
要はプロジェクトでやってないからってことなんですけど、
ちょっとね、完全に浦島太郎感が出てき始めたので、
ちょっと反省はしますけど。
はい、というわけでコンポーネントエンクロサイクロペディア、
要は百科事典ってことですね。
はい、世界のUIコンポーネントを探検し、
実際に機能するテクニックを学んでいきましょうっていうのがサブタイトルありますね。
はい、しんさんですかね。
はい、おつかれさまでした。ありがとうございます。
では行きましょう。
最初ですね、今回のタイトルですね。
記事を担当してくださった方はドミニクグウェンさんっていう方ですね。
はい、じゃあ行きます。
アクセシビリティとレスポンシュ、パフォーマンス、多面性を全て同時に実現するUIを構築するにはどうするのが良いでしょうかと。
学習リソースってのたくさんありますけども、
そのほとんどっていうのは初心者向けになってしまいますよと。
まあそうですし、僕も多分初心者向けの記事ばっかり書いてしまいがちですよね。
実際のチームの要件とそこでのトレード法を考慮したものってほとんどありませんってことですね。
はい、でUI開発でレベルアップするための最短の方法っていうのは同業者の仕事を観察することですと。
まあでもこれは確かに完全に同意って感じですね。
はい、やはり盗むっていうところですね。
そうすれば自分のプロジェクトで彼らのテクニックを試すこともできますと。
今回コンポーネントエンサイクロペディアを立ち上げることができ、とても嬉しく思っていますと。
03:00
私たちは世界中のトップUIコンポーネントを一箇所に集めてカタログ化し、
あなたが自分のプロジェクトを構築する際に閲覧し参照し採料できるようにしましたと。
ああ、そういうものなんですね。
だから本当に百科事典なんですね。
いや、これありがたいですね。
おお、素晴らしいです。
これはもう僕も後でクラップをしておきます。
Airbnb、マイクロソフト、Zendeskなどをはじめとする数多くの企業が提供する5132のコンポーネントを掲載していますだと。
おお、すごいですね。
確かに下に画像とかが載っているんですけど、
Wordpress、Airbnb、Abbc、GitHubとか本当に何らかる企業のコンポーネントがずらっと並べているものなんですね。
いや、これはありがたいですね。
このEncyclopediaの特徴としては、コンポーネントを視覚的にブラウズすると。
5132個のコンポーネントをもちろん検索可能にしますと。
ブラウザでライブサンプルをデモもできますと。
もちろんソースコードですね。
View Sourceというソースコードを見ることもできますし、Reuse Component、コンポーネント採料もできますと。
いや、こんな。
これ、お金払っていいレベルだと思うんですけどね。無償なんですかね、これ。
はい。
なんで百科自定なのかというのが次のセクションですけども。
何千ものチームが毎日UIコンポーネントを開発するためにストーリーブックに依存しています。
しかしストーリーブックはそれを使っている人ほど賢いわけではありません。
最先端のツールを使っても、洗練されたチームと私たちのような普通の開発者の間にはやっぱり知識のギャップがありますと。
UIには無数の要件が絡み合っており、その多くはあなたの手には追えませんと。
ブラウザーであったり、ネットワーク接続であったり、デバイスAPIなどがありますよね。
マークアップを間違えたり、抽象化を間違えたりすると、全てを考え直さなければならなくなることもあります。
私たちはコンポーネントエンサイクロペディアというのを構築することで、開発者が最も賢明なチームによってテストされたUIコンポーネントを参照できるようにします。
これはコンポーネント時代のビューソースと考えてください。
これはUIエンジニアリングの課題が実生活でどのように解決されるかを研究するために役立ちますと言っています。
いやーもうなんかすでにワクワクがめちゃくちゃ止まらないんですけどね。
ちゃんとリンクもありますね。
で、ちょっと軽くリンクを見て感想を述べるんですけど、
リンクURL的にはstorybook.js.orgのスラッシュショーケースってやつですね。
いわゆるショーケース的に並べたんですね。
カテゴリー的なものも用意されていて、それをクリックすると、
例えばエモーションとかウェブコンポーネントとかそれだけに沿ったストーリーブックのリストというのが表示されていくわけですね。
あとはビューアンギュラーがあってなぜリアクトがないんだろうね。
06:01
CSSモジュールとかもしくは先ほど見たものとかですね。
ウェブコンポーネントとかエモーションとかはリアクトながら。
クリックしてその先に行くとやっぱりそれぞれのリストというのがバーっと表示されていて、
そのリストというのは例えばアコーディオンであったりとかアラートであったりとか、
オートコンプリートとかアバターであったりとかバッチリみたいな感じで、
それぞれのコンポーネントの例というのがショーケース的にバーっと並んでいる感じですね。
デザインもいろんなものもあったりしますし、形とか形状もいろいろなものもあったりしますし。
それをさらにクリックしていくと、本当にストーリーブックの実行環境ですね。
プレイグラウンド的に実際にストーリーブックが実行されたページというのがネットに公開されていて、
それを触ることもできますよということですね。
これは本当にありがたいなと思いました。
それを自由にソースコードをコピーしたりとかそのまま使ってみたりとかいう感じですね。
ストーリーブックなのでいろんなアドオンも入っていて、
デフォルトカラーとかカラーの変更であったりフォントサイズの変更であったりとかもできますし、
値とかコントロールもちゃんとできるようになっていますし。
これは便利ですね。
Docsもちゃんと用意されていますね。
いろんなカラバリとかも用意されていますので、
使い方ってもそうですね。
いつも通り僕らが使うようなストーリーブックのものがそのまま公開されているので、
そのままソースコードもコピーして使うこともできる感じですね。
ショーコードってやるとコンポーネントの使い方みたいなところも出てくるので。
ではもう一回本記事に戻りますけども、
改めてコンポーネントエンサイクロペディアですね。
百科事伝というセクションがあります。
コンポーネントエンサイクロペディアっていうのは、
公開されているストーリーブックのUIコンポーネントを視覚的に紹介するものです。
何千ものチームが毎日ストーリーブックにゾーンしています。
GitHubや欧州連合っていうのはアプリの無数のエッジケースを追跡するために使用しています。
ブレックスやソースグラフのようなスタートアップ企業っていうのは、
より少ない作業で新機能を組み立てるために使用していますよと。
今年の初め、私たちはβ版のコンポーネントエンサイクロペディアを立ち上げました。
数え切れないほどのコミュニティの貢献者が、彼らのプロジェクトをインデックスに投稿してくれました。
しかし、より多くのデータが慣れ込んできたため、
そのすべてを構造化する方法が必要になりました。
本日のリリースでは、ファセット検索やブラウズ可能なタグ、
新しいプロジェクト概要ページ、そしてさらに多くのデータを導入しています。
次に、当社のデータは常に更新されています。
ストーリーブックが広く採用されたことで、
我々は世界で最も包括的なUIコンポーネントのデータベースを構築する絶好のポジションにいます。
現在、5132のコンポーネント、14949のストーリー、そして85のプロジェクトがインデックスに登録されています。
09:07
毎週、新しいプロジェクトが追加されたり、最新バージョンに更新されています。
厳密に言うと、この更新は中のチームではなく、
投稿してきたプロジェクトのチームや会社が更新をするのではないかと僕は見えましたね。
もしかしたら中の人は本当にやっているかもしれないですけども。
続いて読んでいきますね。
コンポーネントプロジェクトの検索の仕方というところですね。
コンポーネント名またはプロジェクト名で検索をします。
テキストフィールドがあるので、そこで打ってもらって検索すればできますよという感じですね。
私たちの自信というのは、あなたのプロジェクトで再利用したいと思う最も関連性の高いコンポーネントを強調することです。
各コンポーネントのメタデータというのはタグ付けされていて、
メンテナンス、ストーリー数、ダウンロード数などのヒューリスティックに基づいてランク付けもされています。
またビュー層ですね。リアクト、ビュー、アングラム。
またはCSSライブラリ、Emotion、CSSモジュール、SASみたいなのですね。
結果をフィルタリングして、あなたの技術スタック特感性のあるコンポーネントを見つけられることができますよと。
検索機能のところもしっかり重視して、ページとか機能拡張というのを指摘したというところですね。
さっき軽く見た感じですけど、ここに書いてある通りですね。
検索して、モジュール打ってEnter押したらバード出てきて、カテゴライズもされていますし、
その後、タグ付け的なのもあるので、そのタグをまたチェックボックスがあるのでチェックしていけば
それのものがパッと出てくるとフィルタリングされますよというので。
視覚的にも分かりやすい検索の仕方だと思いますね。
続いてコンポーネントを視覚的にブラウザするということですね。
コンポーネントはコードの視覚的及び機能的な側面というのをカプセル化しています。
コンポーネントエンサイクロペディアというのは、ライブラリ、デザインシステム、
またはアプリケーション内の全てのコンポーネントで参照画像を取得します。
これによってさらに詳しく調べる前にコンポーネント本質というのを視覚化することができます。
調べたいものが見つかったらクリックしてブラウザ上でデモを行います。
マシンでコードをコンパイルしたり、GitHubのReadMeを読んだりする必要ももちろんありません。
これがまたありがたいですよね。
クローンしたり手元の方に持ってきたりして、見る必要が別にないですよというところですね。
これがある意味でありがたいところがありますね。
もちろんちゃんと拡張したかったり、自分で手を入れたかったらクローンしたり、フォークしたりしたらいいと思いますけどね。
続いてまたまたぼちぼち読んでいきますけども、
コンポーネントを比較するというところのセクションに入ります。
コンポーネントエンサイクロペディアというのはコンポーネントをタイプ別に分類しています。
12:01
各タイプには定義とそのコンポーネントの標準的なサンプルのセットが含まれています。
最もよく使われるUIパターンの先行技術を包括的に把握することができます。
キーワードで全てのコンポーネントをブラウザするか、
当社チームが監修した注目のコンポーネントに目を通すことができます。
ストーリーブックチームがちゃんと監修しておって、
その中でこれに注目だよみたいなのをちゃんと表示したりできるんですね。
手厚いなあと思いましたね。
ぜひ使ってくださいというところをどんどん強化するための施策なんだと思いますけど。
次のステップです。
ストーリーブックでは、世界はコンポーネント駆動型UIに移行していると考えていると。
まあまあまあ、おおむね同意ですね。
我々の目標はコンポーネントへの移行を加速させることであり、
コンポーネントを最初に構築する方法を学ぶ手助けをすることをテスト。
我々は全てのフロントエンド開発者のための包括的なリファレンスポイントである
コンポーネントエンサイクロペディアから始めてみます。
より多くのプロジェクトを追加し、機能を提案し、問題を報告するために
皆さんの協力が必要ですということで。
お気軽に報告をできるようなところもちゃんと用意してますよということでした。
その方法の2つとして、コンポーネントを100カ所で閲覧するというので、
とりあえずブラウザ、コンポーネントエンサイクロペディアというリンクがありますよと。
あとはチャットがあるそうですね。
ディスコードでメンテナーとチャットをするというのがありますね。
ディスコードのシャープショーケースというのがあって、
そこで自由にメンテナーとチャットを持つことができますよというふうに書いてますね。
最後に、この機能というか、
日本語出てこない。
このエンサイクロペディアを作っている人たちのことが書いてあって、
コールマンさんという方とこの記事を書かれているドミニック・グアンさんですね。
ストーリーブックコミュニティ全体からフィードバックを得て今も絶賛作っていますよということでした。
この記事は終了してますね。
本当に良さそうです。
軽くざっと見た感じ、このショーケースかなり幅広く、やっぱり5000を超えているので、
パターンの数が多いだけあって、僕らが欲しいと思っているものが大体出てくるんじゃないかという気はしてました。
困ったらこのストーリーブックのコンポーネントをエンサイクロペディアにアクセスして、
自分の欲しいなと思っているUIコンポーネント、
例えばボタンであったりとか、バッジであったりとか、
そういうものを見て欲しいものをどんどんアクセスしていくので、
15:01
そのままソースコードをコピペしてもいいですし、
それをちょっと拡張してもいいしという感じですね。
これは本当に僕らウェブフォントの開発者としてはすごくありがたいなというのをつくづく僕も思いました。
というところで、一旦この記事は以上にしたいと思います。
続きまして、ファストパティクッキーレシピですね。
次の記事に移っていきたいと思います。
ここはかなりテクノロジーというか、技術的な話の内容になると思いますね。
さっきはコンポーネントエンサイクロペディアのただただの紹介と言ってしまえばそれまでだったので、
一応でもそういうものがあるというのが僕は知っていたのですごくありがたかったなと思います。
続いて、ファーストクッキーレシピというタイトルですね。
さて入らせていただきたいと思いますが、
セキュリティとクロスブラウザーの互換性というのを確保し、
サードパーティー製クッキーというのが配置されても破損の可能性を最小限に抑える
ファーストパーティー製クッキーの設定方法について説明していこうかなと思います。
クッキー周りはGoogleの何年前か忘れましたけど発表があって、
そこについての対応を考慮しなければいけないなというのがあります。
続いて、オンディスページというふうにやっていきましょう。
クッキーというのはユーザーのコンテキストに応じて、
ファーストパーティーまたはサードパーティーのいずれかになります。
クッキーの登録可能ドメインとスキームが現在のトップレベルページ、
つまりブラウザーのアドレスバーに表示されているものと一致する場合、
そのクッキーというのはそのページと同じサイトからのものと見なされ、
一般にファーストパーティークッキーと呼ばれます。
次の記事に行かないといけないので文語に行きますね。
クッキー、現在のサイト以外のドメインからのクッキーというのは
一般にサードパーティークッキーと呼ばれます。
ここまでは基本的なところですね。
ウェブ上のファーストパーティーとサードパーティーの区別は必ずしも明らかではなく、
それが異なるリソースに与える影響も様々にあります。
ブラウザがファーストパーティーとサードパーティーのクッキーをどう扱うかという課題のいくつかに対処するため、
ファーストパーティーセッツというのは同じエンティティが所有し、
運営する関連ドメイン名が同じファーストパーティーに属すると宣言することを許可すると提案しています。
ブラウザがファーストパーティーとサードパーティーのクッキーをどう扱うかという課題のいくつかに対処するため、
ファーストパーティーセットというのがあるんですね。
リンクが貼ってあって、これはGoogleのディベロッパーの記事ですね。
18:03
ファーストパーティーセットというのがあります。
これは同じエンティティが所有し、運営する関連ドメイン名が同じファーストパーティーに属すると宣言することを許可すると提案しています。
続いてのセクションが、
The Good First Party Cookie Recipeというところで、
ファーストパーティークッキーの設定の仕方の良いレシピだというところですね。見ていきましょう。
あなたが設定しているクッキーがサイト間で使われない場合、
例えばあなたのサイトでセッション管理に使われ、クロスサイトのiフレームで使われることがない場合ですね。
そのクッキーは常にファーストパーティーのコンテキストで使用されます。
デフォルトではクッキーはサイト間で共有され、JavaScriptでアクセスされ、HTTP接続で送信されますが、
これにはいくつかのプライバシーとセキュリティのリスクがあります。
プライバシーサンドボックスやオリジンバウンドクッキーなどの他の提案を通じて、
デフォルトの動作を改善するための作業が進行中ですが、
クッキーに追加の属性を設定することで、今日できることがたくさんあります。
以下の設定というのがベストプラクティスであり、
ほとんどのファーストパーティークッキーのセキュリティとクロスブラウザーの互換性を保証します。
これは完全な基盤を提供し、必要なときだけ権限を開放するように調整できます。
この記事は、いくつかの特定のユースケースのためにレシピのバリエーションもカバーしていますよと言っていました。
一応、ザ・レシピというところを見てみますと、
最初にセットクッキーをして、
&&hostcookiename="cookievalue",というのを設定します。
あとはセキュアというのを設定して、
&&pass="slash",
&&httponly="maxage="7776000",
&&samesite="lux",というのを設定しておきます。
これが一応、ベストプラクティスらしいですね。
一応、Detailsというタブがあって、それを開いてみますと、
これの詳しい説明的なのが載っている感じですね。
Detailsどこまでいくんだこれ。
Detailsは、結構短い感じですね。
短い感じなので、Detailsも見ていきますが、
お、何か見落とした。見落としましたね。すみません。
Details入っていきたいと思いますが、
Details長いな。めちゃめちゃ長かった。
ちょっと翻訳時間かかりますね。ごめんなさい。
じゃあ、一個一個見ていきたいんですけども、
まず最初は、セットクッキーのところにある&&hostというのは、
ある属性を必須として、他の属性を禁止するオプションの
21:01
セット文字になります。
それというのは、3つあって、
1つはセキュアであること、2つ目は、
ドメインは省略可能です、と言ってますね。
最後、パスというのはスラッシュでなければなりません、
というふうに言ってますね。
ホストというのを追加すると、これ&&hostですね。
を追加すると、条件の属性が&&hostの規則に沿って
設定されるかどうかをブラウザーが確認して、
そうでない場合はクッキーを拒否するように頼れます。
そういうことができるんですね。なるほど。
僕、これ見たことなかったですね。&&host-cookiename
というのがクッキーバリューで、そこからわちゃわちゃ設定すると
そういうことができるようになるんですね。
その辺をブラウザーが見て、規則に沿って設定されるか
というのを確認してくれるらしいです。
セキュアというのは、https属性による、
接続によるクッキーの送信のみを許可するため、
安全でないネットワーク上でクッキーが盗まれないように
保護してくれますと。
サイトをhttpsに完全に移行してない場合は、
そちらを優先してくださいと。はいはい、なるほどですね。
まずやっぱセキュアのことをしたい場合は、
SSLの方、厳密に言うとTSLか、
いうのを設定してくださいよということですね。
その上で、https接続による、
送信のみを許可するような設定をするのに、
セキュアというのをつけてくださいということですね。
ただ、さっきもある通りですけど、
セキュアであることがやっぱり大前提と書いてるんで、
先にhttpsの方を準備してくださいということですね。
まさひろさんですね。
お参加いただきありがとうございます。
タイトルにある通り、コンポーネントエンサイクルメディアと
ファーストパーティークッキーレシピって2つの記事を読んでて、
後者の方はすでに読んでしまったので、
今は後者の方の記事をずっとだらだら読んでる感じですね。
今はベストプラクティスのところに入って、
それを一個一個ディテール図で細かいところを見ていっている感じです。
続いて、さっき出てきたドメインってやつですね。
省略可能だって書いてましたけど、
ドメイン属性っていうのは、
どのホストがクッキーを受け取ることができるのか、
っていうのを指定することができると。
これを省略すると、
クッキーは現在のドキュメントホストに制限されて、
サブドメインっていうのは除外されますと。
で、example.comのクッキーっていうのは、
example.comへのすべてのリクエストで送信されますけど、
例えばimages.google、
example.comへのリクエストで送信されることはありませんよと。
で、example.comのクッキーっていうのは、
同じドメインへのすべてのリクエストで送信されますけど、
同じものを繰り返してるな。
images.example.comへのリクエストでは送信されませんと。
送信されることもありませんし、
送信することもないですよってことですね。
これはハショルトってことですね。
ハショルト内でちゃんとドメイン設定するときは、
設定してくださいよってことですね。
で、続いてパスってやつですね。
パスっていうのは、
24:00
必ずスラッシュでなければなりませんっていうふうに書いてあって、
これ何かっていうと、
そもそもパスっていうのは、
ブラウザがクッキーヘッダーを送信するために、
要求されたURL内に存在する必要があるパスを示します。
あー、なるほどですね。
で、パスイコールスラッシュを設定すると、
そのドメイン上のすべてのURLパスにクッキーが送信されることになります。
ドメインなしとパスイコールスラッシュの組み合わせっていうのは、
クッキーを可能な限り、
原点に近いところに結びつけますと。
したがって、ローカルストレージのような、
他のクライアント側ストレージと同様に振る舞い、
example.com.aっていうURLですね。
また、example.com.bと異なる値を受け取るかもしれないっていう混乱はまず起こりませんと言ってますね。
あー、なるほどですね。
だから、ドメインっていうのをオミティックにして、
パスっていうのをスラッシュにしてくださいって言ってるわけですね。
なるほど。
基本的には、脳死じゃないけど、
知っておいたほうがいいけど、
知らなくてもとりあえずパスをスラッシュに設定しておいて、
多分損はないなって思いましたね。
続いて、httponly属性ですね。
こちらっていうのは、JavaScriptのアクセスを制限することで、
サイト上の悪意のあるサードパーティースクリプトに対する保護を追加します。
これはクッキーをリクエストヘッダーでのみ送信し、
ドキュメント.クッキーを介してJavaScriptから利用できないようにするものです。
この辺は結構基本的な感じかな。
多分、httponly属性っていうのを見たら、
大体こういうことが知られるのかなと思います。
httponlyを使用しても、
フェッチや、例えばxmlhttpリクエストのような、
JavaScriptからのリクエストをトリガーすることができます。
あなたのサイトのこれらのスクリプトのいずれかが侵害されているか、
もしくは悪意のある場合は、
潜在的に機密性の高いクッキーデータへのアクセスが制限されます。
最後ですね。
maxageですね。
maxageっていうのは、もちろんクッキーの寿命を制限しています。
ブラウザのセッションっていうのは、かなり長い時間続くことがあって、
古くなったクッキーが永遠にぶら下がるのはやっぱり好ましくないですよ。
これはユーザーセッションのような短期間のクッキーであったり、
フォーム送信のためのトークンのような、
さらに短いクッキーにも適しています。
maxageってのは基本的には秒単位で定義されて、
上の例では777万6千秒、つまり90日に設定されています。
一応ベストプラクティスは90日がベストらしいですね。
けど、これは別に運営するサイトであったりとか、
お客さんの仕様であったりとか、いろんなことを加味して設定するのがいいです。
これは多分何もない状態の時に、
デフォルトだったらこの辺の値がいいんじゃないのっていう値だと思いますね。
一応これは妥当なデフォルト値であって、
ユースケースに応じて変更することができますし、
してくださいって書いてますね。
ちなみにmaxageの最大値っていうのは400日なんですね。
そんな続くの?
3456万秒、一応。
あ、であってはなりませんと言ってますね。
最大値は400日以上であってはなりませんと。
そもそも1年超えてる時点でえってなるんで、
27:02
1年以上で設定することは僕は聞いたことないんですけどね。
クッキーの寿命を制限するもう一つの方法っていうのは、
有効期間の代わりに将来の有効期限を設定する、
いわゆるエクスパイアーズ属性を指定することです。
エクスパイアーズ属性で指定される日付と時間っていうのは、
サーバーではなくクッキーが設定されるクライアントかの
相対的なものにあることに注意してください。
ここ重要ですね。
あくまで相対値ですよってところです。
エクスパイアーズでもいいんですけど、
僕はmaxageそのまま設定しちゃっていいんじゃないかな
って気はしますね。
続いて、これが本当のラストですね。
samesite="lux">っていう設定の話ですね。
samesite="lux">っていうのは、
クッキーが同じサイトのリクエストにのみ送信されるように制限します。
つまりリクエストが現在の閲覧状況、
ロケーションバーに表示されている
ユーザーが現在閲覧しているトップレベルのサイトと
一致する場合です。
samesite="lux">っていうのは、
最近のブラウザのデフォルトではありますけども、
異なるデフォルトを持つ可能性のあるブラウザ間で
互換性を保つためにこれを指定するのは
良い習慣になりますよと。
クッキーを明示的に
samesite="only">とすることで
ファーストパーティーのコンテキストに
制限することになり、
サードパーティーのクッキーがなくなっても
そのクッキーを変更する必要はないはずです
って言ってますね。
samesite="only">も結構
いろんなサイト多分使われてるし、
そういう設定されてる印象はすごく強いですけどね。
でなくて、samesite="lux">っていう設定でも
別にいいんじゃないのっていう感じですね。
一応異なるクッキー属性の詳細について、
MDNのセットクッキーのドキュメントがあるので
こちらを参照してくださいっていうことでした。
なんですけど、MDNの記事とか
サイトの情報っていうのも
本当に最新情報かどうかっていうのは
結構怪しかったりするので、
一応参考として見るのは構わないですけど
本当にそれが正しいかどうかっていうのは
随時吟味していただければいいんじゃないかな
と思ったりはしていますね。
はい、というところで
続きすげー読んでいきたいんですけど
9時29分になってきたので
続きは明日にしちゃおうか。
いや、あと短いかな。
短いので、このまま読み切ってしまってもいいですかね。
うん。
いや、長いですね。
長いので続きは明日にしようと思います。
はい、というわけで
今日の朝勝はこちらで一旦以上にしたいかなと思います。
明日はこの続きですね。
ファーストパーティークッキーレシピっていうものの続きですね。
いくつかまたレシピがバンバンと出てくるので
それについての説明をまた読んでいこうかなと思います。
じゃあ今日もご参加いただきありがとうございました。
日曜日の朝早い時間から
眠いなっていう方もいらっしゃると思いますけども
ゆるりと聞いてくださって
すごくグッとしたら嬉しかったなと思います。
じゃあ本日日曜日ですね。
良い休日をお過ごしいただければなと思います。
じゃあこれで終了します。お疲れ様です。
