感想
- フロントエンドのカンファレンスは一昔前だとJSフレームワークが中心だった印象なので、時代の流れが変わったなと思った
- CSS周りの話が面白くてもっと深堀りしたくなった
- 初開催の中でもハイブリットでオフラインは200名程度のイベントを用意してもらえて感謝です
- もともと1トラック予定のところ、たくさんのプロポーザルが来てなんとか2トラック調整をつけたとか苦労話も聞きました
- 次回開催も期待してます
ダークテーマとアクセシビリティの融合したカラートークンの設計
- 出口 裕貴さん
- https://speakerdeck.com/degudegu2510/dakutematoakusesibiriteinorong-he-sitakaratokunnoshe-ji
カラートークンの設計
- global tokenとalias tokenを定義して使ってた
- カラーパレット
- カラートークン
AI時代のこれから、もっと重要になるフロントエンドのお話
- 米井 優顕さん
生成AIとフロントエンド
- チャットで生成した成果物をどう埋め込むか
- コピペする？
- Copilotだとそのままエディタに反映できる
- メシウスの製品だとエクセルライクなサービスにチャット機能があって生成結果を埋め込める
- Next.jsで作ってAzure叩いてる
CSSレイアウト再入門:完全に理解してCSSを記述するために
整形コンテキスト
- CSSボックスモデル
- ブロックレベルのボックス
- ブロック整形コンテキスト
- インラインレベルのボックス
- インライン整形コンテキスト
- ブロックレベルのボックス
- ブロック整形コンテキスト
- 参加されるボックスはすべてブロックレベルボックス
- 段落が増えていく
- ボックス間はmarginの相殺が起きる
- 何もしなければ横幅いっぱい
- インライン整形コンテキスト
- 参加するボックスはインラインレベルボックス
- 行方向に増えていく
- ボックス種別は外側と内側がある
- ブロックやインラインは外側
- flexとかは内側
- フレックスボックスレイアウト
- フレックスボックスレイアウト
- グリッドレイアウト
- グリッド整形コンテキスト
- 独自の整形コンテキスト
- float
- position
Webサイトをキュッと引き締めるモーションデザイン
- 道家陽介さん
Webサイトにおけるモーション
- モーションのマイナス面
- 動くと読みづらい
- 気を取られてしまう
- 動くのが苦手な人も
- 大事なこと
- 読み手にとって大事な演出であること
- ユーザのメンタルモデルに合うこと
- モーションの要素
- 長さ
- イージング
- ディレイ
- モーションの目的にあわせたサイズの使い分け
- クイックに動かすもの
- ホバーとか
- 中くらい
- ドロワーアニメーション
- 大きいモーション
- 画面遷移
- クイックに動かすもの
- 体感の重心
- イージングをかけて変化の速度を変える
- 1から100に変化させる必要もない
- 75から100とか
デザインシステムとコンポーネント指向によるフロントエンド開発プロセスの革新
コンポーネント指向による開発
- jQueryしか経験ないような人が多いチーム
- コンポーネント指向知らない人に
- AtomicDesignをガイドラインとして進めていった
- どれがどの分類か定義は難しいが方向性をイメージするのにはいい
- デザインシステム
- デザイナーとエンジニアの共通言語になるように
- それぞれ勘所が違うので
10年ものの jQuery フロントエンドを良くしていくための道筋
uQuery
- 昔のブラウザ互換性問題
- prototype.jsはネイティブのオブジェクトにいろいろ生やしてた
- jQueryはグローバルな$にいろいろ詰め込んでるのが新しかった
- jQueryで抱えていた問題
- 改善
ESLint Plugin により事業, 技術ドメインに沿った制約と誓約を敷衍させるアプローチのすゝめ
- Shinobu Hayashiさん
- https://speakerdeck.com/shinyaigeek/eslint-rule-niyorishi-ye-ji-shu-domeinniyan-tutazhi-yue-toshi-yue-wofu-yan-saseruapurotinosu-me-796c5458-d929-455c-90cf-f4914b91621f
制約と誓約
- 開発におけるルールを守ることでアプリケーションの質を高める
- アプリケーション開発/運用と普遍的/固有の2x2の4パターン
- 今回は開発の固有部分がスコープ
- 日経電子版では
- HTTP Request Header Fieldから取得の制約
- CSS in JSの制約
- 制約を守るために
- 人の手だけだと完全に実現するのは難しい
- 機械でできることは機械的に
- Custom Linter Ruleで
- Custom Linter Ruleの開発
Component-Driven Design & Development
Component-Driven Design
- コンポーネント
- FIRST
- 焦点を絞る/独立/再利用/小さい/テスト可能
- Component-Driven Development
- コンポーネントを作って組み合わせて開発する
- Storybookが提唱してる
- Component-Driven Design
- デザインもコンポーネントドリブンがいいしそうなりつつある
- AtomicDesighnもデザイナーも巻き込んで浸透してればうまくいくのでは
- デザインツールも進化してきてる
Design Token
- プラットフォームに依存しない形で共有できるもの
- 色とかタイポグラフィとか余白とか
- GlobalToken/SemanticToken
- Globalは直接的な定義
- Semanticは意味をもたせた定義
- デザイン/開発で使うのはSemanticToken
- デザインと開発の橋渡し
- JSONのフォーマットがW3Cで定義されている
- Design Token Format Module
- これをいい感じにCSSなどに変換して使う
- style dictionary
- Headless Componentと相性がいい
- デザイントークンをはめるとstyleがつく
Figma
- デザインをコンポーネント化できる
- Code Connect
Storybook
- Storybookでテストも
- Chromaticと組み合わせてVRT
- Story単位でのテスト
- PlaywrightでStoryを動かすことも
The Future of Frontend i18n : Intl.MessageFormat
- Sajikixさん
Intl.MessageFormat
- Intl
- Intl.MessageFormat
- 新しく追加されようとしている
- 日時など各要素の書式化は充実してきてる
- アプリ全体の国際化を進めようという話
- ECMAScriptとUnicodeと連携して進めている
- 文言管理とか
- ICU MessageFormat
- プレースホルダーを設置してそこに言語ごとの値を入れる
- よくある機能と同じ感じ
- 細かい書式指定や条件分岐も書ける
- 20年くらい前からある
- プレースホルダーを設置してそこに言語ごとの値を入れる
- ECMAScriptとMessageFormat v2
- MessageFormat v2のち買い方
- 2種類のメッセージ
- simple message
- プレースホルダーが
{}で入ってるもの
- プレースホルダーが
- complex message
- 全体を管理して
{{}}で値を組み立てる
- 全体を管理して
- simple message
- 2種類のメッセージ
- simple message
{}の中に$usernameみたいな形で埋め込む- 関数を埋めることもできる
- デフォルトでも用意されてる
- 数値のフォーマットとか単数複数のためのものとか
{#button}Submit{/button}みたいにマークアップすることも- complex message
- message内だけで使える変数の宣言ができる
matchでswitchみたいなこともできる
- 実際はIntl.MessageFormatを通してv2を使うことになる
- newする時にいろいろ指定する
- formatする時に変数を渡す
ブラウザはどのようにしてテキストを描画しているのか？――Chromiumにみるテキスト描画の深淵
- canalunさん
テキスト描画
- text shaping
- フォントデータのglyphをどこに配置するか
- フォントが持つcmapでglyphを決定
- ligature
- 隣に来る文字に応じて字体を変える
- fが2個あるとつながるとか
- 隣の文字によって距離を変える
- テキストの描画
- chromiumはSkiaを使ってる
- 下線/上線/テキスト/打ち消し線
- 縦書きなど回転させる場合の影問題
- ベースを描画してから後から影をつければいける
- 直してるが大変
