00:05
はい、8月24日、時刻は昨日もありました。本日ですね、実は京都に来てます。京都の駅前のホテルに泊まって、今、配信をしてますね。
はい、おはようございます。メインのkkeethの小川原です。では本日も朝活を始めていきたいかなと思います。
ちょっと昨日はですね、会社のメンバーたちと飲み会があったので、それで京都に来てるんですけど、
ちょっと飲みすぎたせいで、声がちょっと枯れていたりとか、若干お酒も抜けてなかったりして頭が痛いんで、ぐだぐだかもしれないですけど、お付き合いいただければなと思います。
では始めていきたいと思いますが、今日はですね、タイトルにある通り、Chromeの105 Betaですね。
今、確か最新バージョンが104.0.0.0だと思うんですけど、次の時期バージョンであれ、Chrome 105 Betaっていうブログ記事が出てたので、
Chromiumブログっていうのが出てたので、それの105バージョンをちょっと読んでいこうかなと思います。
どんな構成になるかという話、把握しておきたいなというところでした。では早速読んでいきたいかなと思います。
はい、山崎さんですね。おはようございます。ご参加いただきありがとうございます。
てててさんですね。ご参加いただきありがとうございます。タイトルにある記事をダラダラと読んでいく感じですね。
では行きましょう。Chrome 105 Betaですね。
特に断りのない限り以外に記載する変更というのは、Android、Chrome OS、Linux、Mac OS、Windows向けの最新のChrome、Betaチャンネルリリースに適用されます。
ここに記載されている機能の詳細については、提供されているリンクから、またはchromestatus.comの一覧からご覧ください。
Chrome 105というのは2020年8月5日現在まだベータ版です。
デスクトップではGoogle.comで、AndroidではGoogleプレイストアで一応最新版をダウンロードもできるので、興味ある人は見てみてくださいということでした。
では一個一個見ていきましょう。一つ目はカスタムハイライトAPIと言われるものです。
もちろんカスタムハイライトAPIというそのものに対しての別の記事のリンクもあって、そこのブログもあったりするのでそれを見てみてもいいと思いますが。
では行きます。カスタムハイライトAPIというのはユーザーエージェントが定義するコロンコロンセレクションとかコロンコロンインアクティブセレクションとかいくつかあるんですけど、
それらに限定されず任意の範囲のテキストにスタイルを設定する方法というのを提供し、記事要素のハイライトの概念というのを拡張しています。
これは独自の選択を実装したい編集フレームワーク、仮想化されたドキュメント上のページ検索、オンラインコラボレーションを表現するための複数選択とか、スペルチェックフレームワークなど様々なシナリオで有用です。
この機能がない場合はWeb開発者やフレームワークの作者というのは希望するレンダリングを実現するためにDOM3の基本構造を変更せざるを得なくなります。
これは目的のハイライトが複数のサブツリーにまたがる場合に複雑であり、またハイライトの変更に応じてDOMを更新して調整する必要があります。
03:07
カスタムハイライトAPIというのはハイライトを追加および削除するプログラム的な方法を提供します。
これは基礎となるDOM構造に影響を与えず、代わりに範囲オブジェクトに基づいてテキストにスタイルを適用します。
105ではカラーとバックグラウンドカラー擬似要素のみがサポートされています。
この項目のサポートは後々追加される予定ですよという風に言っていました。
以上、まず一つ目はカスタムハイライトAPIというものでした。
まずこれだけでも結構いいなと僕は思いましたね。
確かに既存のいろんな擬似要素ですね、CSSの。
あんまりセレクションとかインアクティブセレクションとか実はそんな使ったことなかったので、確かにこういうのもあったなというぐらいなんですけど。
ちゃんと使われている方にはお馴染みのものかもしれないですけどね。
あとはですね、スペリングエラーとかグラムアエラーとかそういうものがあるんですけど、
これに限定されないでテキストにスタイルを設定する方法というのをブラウザから提供してくださるというのは結構いいなと思いましたね。
頑張ってCSSを書かなくてもブラウザ側でもそもそもデフォルトで実装されているので、
この辺を使ってくださいねというのができるので、これはありがたいなと思いました。
反面、またChromeばっかりそういうのがどんどん入っていくんじゃなくて、
他のブラウザにも似たようなのが入ってくるとすごくウェブ開発者としては嬉しいなと思うので、
ここの辺、うまいことブラウザ間、各社間で連携してくださいと連携してくれたら嬉しいなと思ったりはしますね。
一旦、この105でのリリースを待っていきたいなと思います。
以上、まずはガスタムハイライトAPIというものでした。
続きまして、次はコンテナークエリー、クエリーズというものですね。
コンテナークエリーです。お決まりのやつですね。
コンテナークエリーによりコンテナ要素のサイズに応じて要素をスタイル付けすることができます。
この機能はコンポーネントがそのレスポンシブスタイリングロジックというのを所有することを意味します。
これはページ上のどこに表示されてもスタイリングロジックがコンポーネントに付加されるため、
コンポーネントがより弾力的になりますと。
コンテナークエリーはメディアクエリーに似ていますが、
Viewportのサイズではなくコンテナーのサイズに対して評価されます。
基地の問題としてコンテナークエリーをテーブルレイアウト組み合わせた、
マルチカラーのレイアウトで使用した場合、コンテナークエリーが動作しないことがあります。
この問題は106で修正される予定ですと。
詳しくはコンテナーとコロンハズの2つの強力な新しいレスポンシブAPIをご覧ください。
このリリースの他のCSS機能については以下を参照してくださいということでした。
以上、コンテナークエリー図というものでしたね。
106で修正される予定だというのは既に書かれているので、
もうだいぶ先の話までバンバンバン見ている感じですね。
コンテナークエリー僕もあんまり使ったことがなかったので、
これ改めてブログで書かれているのが気になったりしますね。
あとはさっき言ったコンテナークエリーとハズという2つのレスポンシブAPIのところですね。
06:03
これらについても別のブログ記事のリンクが貼られていますので、
そこも見てもらってもいいんじゃないかなというところでした。
こちらについてはdeveloper.chrome.comにブログが書かれていますね。
見てもらうと割とソースコードもバンバン書いてあって、
具体例がいっぱい出てくるので、
コードペンもいっぱい貼られているっぽいので、
これ見てもらうと結構わかりやすいかなと思いました。
じゃあ続いていきましょうか。
コロンハズ、ハズメソッドの議事クラスに入っていきたいと思います。
ハズ議事クラスというのは、
引数として渡された相対セレクターにまつわる要素を少なくとも1つ指定します。
他のセレクターと異なり、
ハズ議事クラスというのは、
指定された要素に対して先行する要素、
具体的には兄弟、祖先、
祖先の先行する兄弟にスタイル規則を適用します。
例えば次のルールは子供としてイメージタグを持つ
アンカータグにのみ適用されますよというふうに言っています。
ソースコード的に音読になりますけど、
aコロンハズ括弧の小なりスペースのイメージって感じですね。
っていうようなハズクラスがあったとします。
そういうCSSの規律があったとしましょう。
この辺のものがさっき言った通りの例になりますね。
子供としてイメージタグを持つアンカータグですね。
aタグに対して適用されるような感じですね。
僕でもハズ議事クラスを使ってみたんですけど、
意外と効かなかったりして、
これ何だろうなと思ってたんですけど、
単純に僕のブラウザーのバージョンが古かっただけなので、
これ僕は結構好きですね。
ハズ議事クラスは。
かなりパワフルで使いやすいなと思ったし、
これからおかげで割と書かなくて良くなったCSSがたくさんあったので、
僕はこれ改めて使うのは全然ありかなと思いました。
ちょっと前に読んだ記事で、
ボディタグにハズクラスを使うことで、
ユーザーのインタラクションに応じてCSSの設定を変更するとか、
またはHTMLのタグにクラスを付けたり削除したり、
JavaScriptでそういう変更をしたりすると思うんです。
それによって見た目、デザインを変えるっていう、
2つのデザインの切り替えをCSSのクラスを付け加えるか削除するかによって、
変更するみたいな実装をよくすると思うんですけど、
ああいうのをJSで処理しなくて良くなるっていう記事が前にあったんですね。
それを読んで僕結構いいなと思ったので、
割とこのハズギジクラスっていうのの再評価と使い勝手っていうのをちょっと考えていくのは、
僕はいいんじゃないかなと思ったりはしました。
その記事のリンクを今ふっと思い出せないので、
もし何か思い出したらツイッターに連絡します。
では続いて読んでいきましょうか。
このハズギジクラスについての記事っていうのが別にあるので、
09:03
詳しくはこっちを見てもらえると、
この強力なResponsive APIっていうのが理解できるので見てください。
ついでにさっき読んだコンテナクエリですね。
こちらもやはり強力なのでやっぱりこれとセットで書いてるので見てみてくださいってことでした。
以上では続いていきましょう。
続いてはフェッチアップロードストリーミングってものですね。
ちょっと翻訳に時間かかってますね。
翻訳に時間かかってるというかこれは僕のDeepLがまた侵略罪気がしますね。
なのでブラウバーから別の。
あ、来た来た。よかったよ。
じゃあいきましょう。
フェッチアップロードストリーミングですね。
こちらはですね、
ウェブ開発者がReadable Streamのボディを持つフェッチを行えるようにするものです。
以前はボディ全体が準備できてからでないとリクエストを開始できませんでした。
しかし今ではコンテンツを生成している途中でもデータの送信を開始することができ、
パフォーマンスとメモリ使用量っていうのを向上させることができるようになります。
僕はこれ結構いいなと思いましたね。
やっぱりストリームなので途中から投げたり受け取ったりできる方が
やっぱいいよねっていうのは感覚的に思ってたので、
これがちゃんと実装されたのは結構ありがたいなと思いますね。
ただまあ、Chromeだけできて他のブラウザできないんだったら
結局実装を分けなきゃいけなくなるので、
現実的には使えなかったりするっていうのはちょっと悩ましいところがありますけど。
まあいいや。
例えばですね、
オンラインフォームとかでユーザーがテキスト入力フィールドにフォーカスをすると
まっすぐにフェッチを開始することもできたりします。
ユーザーがエンターキーを押した時にはすでにフェッチヘッダーが送信されていますと。
この機能により、
オーディオやビデオなどクライアント側で生成されるコンテンツを送信することもできます。
詳細はフェッチAPIによるリクエストのストリーミングっていう
ブロック記事があるのでこれを見てくださいということでした。
これもリンク記事貼ってますのでまた見てもらえればいいんじゃないかなと思います。
僕もこれちょっと気になるので、
これはこれでまた別途読んでいきたいかなと思いました。
こういう記事って全部Chrome関係の記事ですけど、
Chromeって更新がめちゃくちゃ早いので、
これバンバンバンバン読んでいかないと、
後から読んでももうそれ古いよって言われたりする可能性もあるので、
もし興味あって読む方はお早めに読んでみてくださいということです。
一応Chromeの機能をちゃんと中から中の要素まで知って理解したい方には別に
時間が経っても全然いいと思います。
単純に最新にこんな機能があるよっていうその機能の把握だけで良ければ別に
こういうブログ記事だけでいいと思いますけど、
中身までやっぱりエンジニアとしては気になったりすると思うので、
その辺を知るのは全然いいかなと思ったりします。
今日のこの記事もまたTwitterで流すので、
そこからリンクをたどってもらったら嬉しいなと思いました。
続いていきましょう。
続いてはWindows Controls Overlay for Installed Desktop Web Appsですね。
ちょっと長いタイトルですけど、
インストール済みのデスクトップウェブアプリの
Windows制御のオーバーレイだという話ですね。
ちょっと長いんですけど。
12:00
いきましょう。
Windows Controls Overlayっていうのは
アプリのクライアント領域を拡張してタイトルバーとか
Windows Controls ボタン、
閉じる最大回復限とか最小化みたいなボタンがありますけど、
っていうものを含むWindows全体をカバーします。
ウェブアプリの開発者はWindows Controls Overlayを除く
Windows全体の描画と入力、入出力を担当しますと。
開発者はこの機能を使用してインストールしたデスクトップウェブアプリを
アプリレーティングシステムのアプリのように
見せたりすることもできます。
詳細についてはPWAのタイトルバーの
Windows Controls Overlayをカスタマイズするっていう記事があるので
これを見てみてくださいということでした。
あんまり僕ちょっとデスクトップアプリを作ったことがないので
そうなんやって感じですけど。
デスクトップアプリでもちゃんとコントロールボタンのところですね。
もカバーできるっていうのは
割とやっぱり地味にいいよなと思いましたね。
これブラウザーでもできたら結構嬉しいんですよね。
ブラウザーでコントロールボタンの
クリックしたりなんかしたりの制御ができたらすごく嬉しいんですけど
やっぱ僕らができることって結局
JavaScriptを書くことしかできないので
結果的にはWindows Objectより上の階層はもう
制御できないっていうのが
ウェブエンジニアの限界ではありますので
苦しいところではあるんですけどね。
なのでその代わりいろんなイベントを
各ブラウザーとかがWindows Objectに設定してくれてるので
そこから頑張ってやるしかないなっていうのはありますが
ウェブアプリじゃなくて
デスクトップアプリであればそういうこともできますよってことでした。
やっぱり参照記事のところがやはりPWAっていうところですね。
PWAの記事だったっていうのは
やっぱりちょっと興味深いなと思いましたし
やっぱりこの辺をしっかり意識しているんだなって
Chromeはって感じましたね。
あとPWAの話だけもう一個すると
やっぱあれですね。
Safariですね。
Safari 16のベータがやっぱり僕は期待してますね。
いろんなところでずっと言ってますけど
Safari 16でやっぱりプッシュ通知が出るので
PWAっていうのがもうちょっと加速するかなっていうのが
淡い期待を持っています。
あとはですね。
投資の12月3日かな。
ちょっとまだ日付確定してないはずなんですけど
PWAナイトカンファレンスですね。
PWAナイトっていうエンジニアのコミュニティがあって
そこが定期的に勉強会もやってるんですけど
そこのカンファレンスですね。
今年もカンファレンスをやるっていう風に言ってたので
それをそこに参加してもらうと結構いいかもしれないですね。
PWAばっかりの話ではなくて
結局フロントエンド周りの話ばっかりになるとしますし
PWAを業務とかプロジェクトで実際に実装しているっていう
事例はなかなかやっぱり少ないんで
PWAカンファレンスやっても
なかなかPWAの話をいっぱいため込むのは結構難しかったので
結果フロントエンド周りの話になると思うんですけど
もし興味ある方は参加してみてください。
大体12月ぐらいに確かやる予定のはずです。
一応僕スタッフやってるので内部情報ですけど
多分12月3日のはずです。
以上。じゃあ戻りますね。
15:00
続いて、続いて長いな。
続いてはオリジントライアルズっていうやつですね。
オリジントライアルズの話でいきましょう。
では続いていきます。
このバージョンのChrome、いわゆる105ですね。
ではオリジントライアルを開始されていません。
ただし現在進行中のオリジントライアルというのは多数ありまして
Chromeオリジントライアルズダッシュボードというページがあるので
そこで確認をしてくださいということでした。
オリジントライアルズでは新機能を試したり
ユーザビリティ、実用性、有効性に関するフィードバックを
Webスタンダードコミュニティに提供したりすることができます。
Chromeのオリジントライアルについては
詳しくはOrigin Trials Guide for Web Developersというのがあるので
その記事を見てみてくださいと言いました。
Microsoft EdgeはChromeとは別に独自の
オリジントライアルというのを実用しています。
詳しくはMicrosoft Edge
オリジントライアルデベロッパーコンソール
ちょっと長くてごめんなさい。
という別のサイトもあったりページもあるので
そこを見てもらってもいいんじゃないかなと思いました。
Edgeは独自なんですね。
Chromeとは別のオリジントライアルというのをやっているそうですね。
一応完了したものとか何とかというざっくりとした概要が書かれているので
そこも見ていきましょうと。
完了したオリジントライアルですね。
以下の機能は以前はChromeのオリジントライアルに含まれていましたが
現在はデフォルトで有効になっていますというところですね。
一つがWorkersのMedia Source Extensionというやつですね。
Media Source Extension
訳してMSEという風に訳すらしいです。
MSEのAPIというのが
Replicated Workerのコンテキストから利用可能になり
メインウィンドウコンテキスト上の
HTMLメディアエレメントで再生される
メディアのバッファリングのパフォーマンスが
向上することができましたと。
Dedicated Workerで
メディアソースオブジェクトを作成すると
アプリケーションはそこから
メディアソースハンドルというのを取得し
ポストメッセージというのを呼び出して
それをメインスレッドに転送し
HTMLメディアエレメントにアタッチすることができます。
メディアソースオブジェクトを作成したコンテキストは
メディアをバッファリングするために
それを使用することができますということでした。
読んでおきながら
全然知らないAPIだったので
ふーんって感じで
僕読んでました。ごめんなさい。
全然不勉強で
この辺はちょっと説明できなくて申し訳ないです。
ちゃんとここにもブログ記事とか
別のリンクとか貼ってあったりするので
興味ある方は見てみてください。
もしくはご存知の方はむしろ教えてくれると
すごく嬉しいなと思ったりします。
あともう一個ですね。
ビューポートハイトクライアントヒント
っていうのがあるらしいですね。
ビューポートの高さのクライアントヒントか。
Chromeっていうのは
新しい
これ何ですか。私知らないやつですね。
sexy-h-viewport-heightっていうクライアントヒントをサポートしてます。
これは以前Chromeで導入された
sexy-h-viewport-widthのツインになるものです。
18:03
hは既に出てたけど
今回新しくハイトが追加になってる感じですね。
これらはオリジンに対するビューポートのサイズに関する情報を撤去します。
これらのヒントを使用するには
acceptchheaderにsexy-h-viewport-heightまたは
sexy-h-viewport-widthを渡しますということでした。
なるほど。
acceptchheaderは僕名前しか知らなくて
そうなんやっていう感じなので
これもすいません。僕不勉強で申し訳ないです。
一応こういうものがあるんだよってことでしたね。
以上。
こういうところだよな。
やっぱり本当に技術力というか
フロントエンドのちゃんと把握をしてる人って
強い人ってこの辺知ってそうだなって
僕勝手な思い込みがあるんで。
言語側とかフレームワーク側とかタイプスクリプト側とか
いろんな意見もあって
そこももちろん大事なんですけど
そういうちょっと突っ込んだというか
インフラとは言わないんですけど
やっぱりそれを使うための技術というか
環境周りのところまで裾野を伸ばしてる人が
やっぱり強い印象があるんで。
こういうのを見ると
自分の頭がかち割られる感覚があって
良くも悪くもしっかり勉強しなきゃなって
励みになりますね。
全然余談でした。
では続いていきましょう。
続いてはですね。
Other Features in this Releaseですね。
他のリリースですね。
このリリースに対して他の機能のことを言ってます。
サブタイトルでマルチスクリーンウィンドウの配置のための正確なスクリーンラベル。
これサブタイトルじゃなくて一個一個の説明でした。
ごめんなさい。
じゃあ一個目の機能ですね。
一個目の機能がマルチスクリーンウィンドウの配置のための正確なスクリーンラベル
というところでした。
このリリースではマルチスクリーンウィンドウの配置APIによって提供される
画面ラベル文字列というのが強化されています。
特に以前のプレイスホルダーを
デバイスの拡張ディスプレイの識別データEDIDと言ったりするらしいですね。
または上位のオペレーティングシステムAPIからの情報で置き換えることにより
スクリーンディテールドットラベルというプロパティを改良しています。
そんなのがあったんですね。
例えばラベルプロパティはエクスターナルディスプレイ1を返す代わりに
HPZ27Nみたいなものとかビルトインレティナディスプレイのようなものを返すようになります。
いわゆるそういうディスプレイの周りの情報を返してくれるんですね。
このようなより正確なオペレーティングシステムが
ディスプレイ設定ダイアログで表示されるラベルと一致するようになります。
どうやってるんだろうこれ。
OSのシステムのディスプレイ設定のダイアログボックスのラベルと同じにするって
どうやってるんだろう。
ブラウザーとかでそういう情報を取れてるんであれば別にいいんですけど
なんかすげえな。
このラベルはユーザーからウィンドウ配置権限を付与されたサイトでのみ公開されます。
なるほど。ちょっと権限周りの話も必要になってくるってことですね。
というところでした。
21:01
いわゆるマルチスクリーンウィンドウのラベル表示っていうのが
より正確なものになりましたよってことでした。
2つ目です。次の機能はCSSですね。
固定された要素のオーバースクロールの防止だっていう風に言ってますね。
要素のHTML要素のCSSプロパティであるポジションをフィックスに設定すると
オーバースクロールビヘビアっていうので指定された効果を実行しないようになりました。
要素の方眼ブロックがルーティンでない場合は除きますよって言ってますけど
特に固定位置の要素っていうのはオーバースクロールの効果中に移動することはありませんと。
これは地味に嬉しいやつですね。
めでたかIEも信じてくれたのでフィックスプロパティっていうCSSのやつが
Configsがしっかり使えるようになって
例えばフッターとかの固定配置っていうのも結構簡単にできるようになったっていうので
すごく嬉しいんですけどその代わりそいつがオーバースクロールとかと影響を受けるんですけど
これがしっかり移動することがなくなったよっていうのはめちゃめちゃ嬉しいですね。
ただ他のブラウザーもっていうしつこいですけどその話はあるなとちょっと思いました。
続いていきましょう。続いての機能はDisplayMediaStreamContains.System.Audioです。
メディアディスプレイストリームの制約の話ですね。
長いしシステムオーディオを使ってる人ってどんだけいるのかちょっと悩ましいとかありますけどね。
まあいいや。いきます。
新しい制約がMediaDevices.GetDisplayMediaに追加され
システムオーディオがユーザーに提供されるべきかどうかが示されるようになりました。
ユーザーエージェントはビデオと一緒にキャプチャするためのオーディオを提供することがあります。
しかしすべての音声が同じように作成されるわけではありません。
ビデオ会議アプリケーションをちょっと考えてみましょう。
タブ音声はしばしば有用であり遠隔地の参加者と共有することができます。
しかしシステムオーディオには参加者自身の音声が含まれていて
共有し直すには適切にない場合があります。
この新しい制約を使用するには制約としてシステムオーディオを渡してあげます。
例えば以下のようになります。
ソースコードが出てくるので音読になりますが
const stream="await">navigator.mediadevices.getDisplayMediaというメソッドをコールします。
引数にオブジェクトを渡してあげて
いくつかのキーバリューを渡してあげます。
1つ目がビデオにしてビデオをトゥルーにします。
2つ目にオーディオもトゥルーにします。
最後にシステムオーディオをエクスクルードというような文字列で渡してあげる。
この3つ目のところが追加オプションになっています。
インクルードにするかエクスクルードにするかアプリケーションによって違いますが
これを指定してあげることによって制約できるようになりますよということでした。
またこの機能というのはonly supported on desktopですね。
デスクトップでのみサポートされていますというところがミソというか制約だったところですね。
エレクトロンとかでやっていたらもっと
24:01
この辺のアプリケーションの場合は適用されるのかなと思いました。
僕は試していないんですけどという話でした。
続いていきましょう。
残り5分なんですけど
機能がめちゃめちゃ多いんですよ。
まだここから何個くらい機能が出てくるので
どうしようかな。
最後に一応別のセクションがあって
デプリケーションズ&リムーバルズというのがあるので
むしろこっちですね。
いわゆるデプリケートになったもしくは削除された機能というのを
シフトしたほうがいい気がしてきているので
他の
in this releaseのother featuresですね。
フィーチャーズ。
他の機能ですね。
のところは皆さんのほうでブログから見てもらうほうがいいのかなと思いました。
結構たくさんあるんですよね。
新しいリリースがChrome 105で導入されているので
この辺ちょっと見てもらってもいいかもしれないですね。
割と面白そうなタイトルいっぱいあるんですけど
残り時間はデプリケーションズのほうをちょっと読みたいなと思いました。
デプリケーションズのほうも
いくつかの機能の話が出ているので
同じような感じになりますけど
ちょっとこっちに行かせてください。
いきましょう。
デプリケーションズ&リムーバルズです。
このバージョンのChromeでは
以下に示す非推奨事項や削除事項が導入されています。
予定されている非推奨事項もしくは現在の非推奨事項
過去の削除事項の一覧というのは
chromestatus.comというふうに詳しくあるので
そこを見てみてくださいということでした。
では行きましょう。
一つ目です。
非セキュアコンテキストにおけるWebSQLの削除ということですね。
Remove WebSQL in non-secure context
はい。
非セキュアなコンテキストでのWebSQLが削除されました。
WebSQLデータベース標準というのは
2009年4月に初めて提案され
2010年11月に放棄されました。
で、月項ですね。
月項はこの機能を実装せず
WebKitは2019年にこの機能を非推奨としました。
W3Cというのは代替手段を必要とする人のために
Webストレージとインデックスデビを推奨しています。
あ、なるほどね。
Webストレージとインデックスデータベースっていうのは
それの置き換えとか代わりのものだったんですね。
全然知らんかった。
WebSQLとこれらって全然別物だと思ったけど
実は代替手段として提供したんですね。
Web3Cが勉強になりました。
まあちょっと歴史的な話ですけどね、これは。
まあまあ全然多分もう使っている人いないんじゃないか。
WebSQLっていうワードシェラーすら
ほぼほぼ聞いたことないんですかね。
現代では。
なのでまあまあ今は皆さん脳死で
インデックスデビかWebストレージ使ってくださっていると思うので
それでいいんじゃないかなと思いますね。
はい。
では続いていきましょう。
続いてはCSSのお話ですね。
カスタム識別紙のCSSデフォルトキーワードの
使用負荷についてっていうところです。
CSSのキーワードデフォルトっていうのがあるんですけど
27:00
これはCSSのカスタム識別紙では使用できなくなりました。
カスタム識別紙はCSSの多くの種類のユーザー定義名。
AddKeyFramesKeySoftだったりとか
カウンターだったりとか
Addのコンテナ名だったりとか
カスタムレイアウトやペイント名など
まあいろんなものがあります。
ユーザーがカスタムに設定できる識別紙ですね。
この辺に使用されています。
これらによりカスタム識別紙の使用が
制限される名前のリストに
デフォルトというのが追加され
特にInheritとかInitial、Unset、Revert
およびRevertLayerというのが
追加されるようになりますよということでした。
はい。
なるほどですね。
まあまあデフォルト
僕実はあんまりデフォルトキーワードを
使ったことないんですよね。
なので別に影響はそんな大きくはないと思っているんですけど
どうなんでしょうね。
まあしっかりカスタム
識別紙を使われている方であれば
全然そこは問題ないと思いますし
逆にデフォルトに頼るようなアプリケーションって
あるのかなっていう
一抹の疑問もありますけど
使ってないんだと思うんですよね。
なので削除されたと思って
よいんじゃないかなっていうのが僕の予想です。
はい。
じゃあ続いていきましょう。
続いてナビゲーションAPIの必須情報ですね。
はい。
これはデプリケーションですけど
TransitionWhileというメソッド
リストアスクロールというメソッドがありますけど
これらのメソッドも今回のリリースで
必須情報となり
108年に削除される予定です。
多分1年じゃなくて
単純にバージョン108ですね。
だいぶ先の話をすでにしている。
けど一応108で削除される予定になっているそうですね。
この機能が必要な開発者は
新しいインターセプトメソッド
およびスクロールメソッドというのがあるので
そこを使用する必要があります。
既存のメソッドの問題というのを説明と
新しいメソッドの使用例については
アミゲートイベントというブログがあるので
そこを見てみてくださいということでした。
30分きましたけど
あと2つの機能なんで
これはちょっと走り切っていきたいなと思います。
続いてクッキーのドメイン属性における
非ASCII文字の非推奨だという風に言っています。
最新の使用RFC6265BISに合わせるために
Chromiumはドメイン属性に非ASCII文字
例えばドメインイコール
example.comみたいなものが含まれるクッキーを
間もなく拒否する予定になります。
クッキーにおけるIDNドメイン属性のサポートは
長い期間設定されておらず
Chromium、Safari、Firefoxはすべて
異なる動作をしていました。
この変更により
非ASCIIドメイン属性を持つクッキーを拒否する
Firefoxの動作が標準化となります。
これはいい話ですね。
Chromiumはこれまで非ASCII文字を受け入れて
正規化されたパニーコードに変換して
保存しようとしたため
今後はより厳格なルールを適用し
有効なASCIIを担当する場合は
パニーコード属性を要求するようにします。
105からコンソールに傾向が表示されなくて
106で完全に削除される予定ですよ
というふうに言っています。
そもそもそんな
ASCIIコード文字を使うかという話は別にあるので
30:00
ちゃんと明確的に規定されて
各ブラウザ同士で異なる動作が
統一化されていくと
Firefoxの動作が標準になるというのは
結構いい話だと思いました。
Firefoxだというのはやっぱり
モジュラー社だからだと思いますね。
ウェブの新しいものを
未来をつくっていこうとするのは
Googleだと思うんですけど
ウェブの標準をつくっていくというと
やっぱり僕はモジュラーだろうな
というふうに思ったりはしています。
じゃあラスト
ジェスチャースクロールドームイベントの削除だ
ということでした。
Chromeからジェスチャースクロールドームイベントの
削除がされました。
具体的には
GetStraight Scroll Startと
GetStraight Scroll Update
あとはGetStraight Scroll End
これらというものが削除になりました。
これらはプラグインで使用するために
Blynkに追加された非標準のAPIで
ウェブにも公開されていました。
懐かしいですね。
Blynkというワードも久しぶりに来ましたけど
こいつらのために追加された
APIだったんですね。
というものが今回は削除になりましたよ
ということでした。
そもそもBlynkはもう使われないので
削除は全然いいんじゃないかと思いますね。
ということで
一応リムーバルのお話は以上になります。
今回のブログも以上になりますね。
読めなかった
Other Featuresのところは
皆さんの方でも見ていただければいいと思います。
かなりたくさんの機能が実装されているので
興味深いなと思いますし
逆にちゃんとGoogleは
Chromeのもう使ってないねとか
もう不要だなという機能の削除を
しっかり検討して
導入してくれるのですごくありがたいなと思いますね。
やっぱりChrome自体は
最近重いなって感じたりもするので
そこら辺しっかり削除になっていて
いらないイベント設定だったりとか
機能というのが消えるというのは
僕はありがたいなと思いますね。
そういうのもあるからやっぱり
Chromeというのは信頼性高いなというのを
ちょっと感じました。
また108という数字が出てきたので
Chromeの今後の実装のプランというのが
しっかりかなり先まで
プランニングされていて
何をどこまでやるかというのも
あるのはすごくありがたいなというので
今後もChromeのブログを読んで
追っていきたいなという風に
改めて感じましたね。
という感想で終わります。
9時33分
30分を超えたので
今日の朝活動は以上にしたいなと思います。
本日もご参加いただいた
多くの方、大変にありがとうございました。
また明日も何か有力読んでいきたいと思いますので
興味
ご参加いただければありがたいなと思います。
明日は
いろんな記事を探したんですよね。
CSS周りだったりとか
フィロソフィー的な記事を読みたいなと言ったんですけど
探したんですけどなかなか出てこなくて
悩ましいんですけど
技術的な記事を読むかもしれないですけど
ご容赦いただければ幸いです。
というわけで
今日からもまた
一日頑張っていきたいなと思いますので
皆さんも頑張っていきましょう。
では終了します。お疲れ様でした。
