Skip to content

（意訳）Intrinsic design theming and rethinking how to design with WordPress

Jump to bottom
Olein-jp edited this page Feb 24, 2023 · 4 revisions

Intrinsic design, theming, and rethinking how to design with WordPress

原文

https://developer.wordpress.org/news/2023/02/intrinsic-design-theming-and-rethinking-how-to-design-with-wordpress/

意訳

  • Gutenberg プロジェクトに寄り添ってきた開発者たちの中でしばしば繰り返される質問がある

  • いつになったらレスポンシブ操作ができるようになるのか

  • デスクトップ、タブレット、モバイルのビューに基づいて、ブロックデザイン要素を変更する機能に関して、この質問がよく取り出される

  • これは重要な問題

  • テーブルレイアウト、フロート、フレックスボックスやグリッドレイアウトというように、Web は常に変化し続ける分野

  • 様々なスクリーンサイズに応じたメディアクエリを活用しているが、標準的なサイズがない

  • 仮に標準を決めたとしても、明日には全て変わってしまうかもしれない

  • メディアクエリはその場しのぎの解決策としては有効だが、使い過ぎると CSS が肥大化する可能性がある

  • そのため、デザインは変化し続けるウェブに対応するように進化し続ける必要がある

  • そこで登場したのが、「intrinsic design（イントリンシック・デザイン）」です

イントリンシック・デザインとは

  • intrinsic とは Merrian-Webster 辞書には「belonging to the essential nature or constitution of a thing（本来のところ）」と定義されている

  • ウェブの「本質」とは何か

  • ひとつは「常に変化し続ける」ということ

  • 全てのページの幅と高さを正確に把握し、要素のずれを心配することなくすべてを完璧にそろえることができる印刷物デザインとは異なり、ウェブは流動的なメディアである

  • イントリンシック・デザインは、この単純な真実に基づいて問題を解決しようとする

h1 {
  font-size: 64px;
}
  • メディアクエリに基づくレスポンシブ Web デザインでは、64px がすべてのデバイスで美しく見えないことに気づいた
h1 {
  font-size: 48px;
}

@media screen and (min-width: 767px) {
  h1 {
    font-size: 64px;
  }
}

  • これでは、対象とするビューポートサイズの数に応じて、複数のメディアクエリがすぐに膨れ上がってしまう可能性がある

  • そして、ウェブの本質に基づいたデザインの問題を解決するものではない

  • イントリンシック・デザインの手法とは、ビューポートの大きさを問わない方法で問題に取り組むこと

  • 見出しの大きさは関係なく、縮んだり広がったりすることができる

  • viewport units や clamp() などの機能により、以下のスニペットのように最近の CSS ではこれが良いとされています

h1 {
  font-size: clamp(2.25rem, 6vw, 3rem);
}

  • これは広いトピックを単純化しすぎた例ではある

  • その目的は、テーマの作者が自由に使えるツールで、問題を解決するための最良の解決策を常に考え直し、再評価すること

  • メディアクエリやコンテナクエリがデザイナーのツールの重要な要素ではないといっているわけではない

  • それらを使い続けるというシナリオもある

  • しかし、それらを常に唯一の道具とする必要はない

WordPress にとって イントリンシック・デザインとは何か

  • WordPress 5.0 でブロックエディタが導入され、特に 5.8 でブロックテーマが登場したことで、WordPress の上でデザインする風景が変わりました。

  • UI の中からサイトを構築するという究極の目標が、より現実味を帯びてきたのです。

  • WordPress プロジェクトの健全性を保つためには、可能な限りの CSS プロパティをインターフェイスにオプションとして追加することに、真っ先に飛びつかないという厳しい決断を迫られることになった

  • UI が UX の悪夢にならないようにするには、よりゆっくりとした、より整然としたアプローチが必要であることはすぐに明らかになった

  • 新しいデザインツールを導入するたびに、何年もの技術的負債を抱えることになりかねないからです

  • さらにユーザーは、ブロックやブロックパターンを文字通りどこにでも挿入することができます

  • テーマ側では、ブロックがどのような文脈で使われるか把握し、すべてのユースケースを考慮する方法はありません

  • ブロックはサイドバーのあるコンテンツエリアにあるのでしょうか？

  • レイアウトはフルワイドなのか、ワイドなのか、制約があるのか

  • レイアウトはフローなのか、フレックスなのか

  • ブロックレベルでメディアクエリを使用してこれに取り組むには、あまりにも多くのシナリオがあります

  • しかし、現実には、スクリーンサイズの流動性を考慮したデザインが必要

  • WordPress は、UI の肥大化を抑えつつ、最新の技術を駆使してこの問題に立ち向かう必要があった

  • レスポンシブブロックと本質的な web デザインと題した Gutenberg チケットで、Joen Asmussen はこのアプローチの背後にある考え方を紹介した

最終的には、メディアクエリを完全に排除することが目的ではなく、「単一のブロックパターンが、どの程度レスポンシブに対応できるのか」ということを追求することが動機となっている。 副次的な効果として、編集のための UI が大幅に簡素化される可能性があります。メディアクエリやコンテナクエリは、組み込みの固有動作の漸進的な拡張とみなすことができます。

  • 一夜にして解決するような問題ではない
  • むしろ、開発者は過去数回のメジャーリリースで新しいツールやテクニックがリリースされるのをみてきており、今後も期待できる反復プロセスである
  • これは考え方でもある
  • コアとなる貢献者だけでなく、テーマとなるコミュニティも同じように考える必要がある。
  • 今日の方法が明日のために正しいかどうか、自問自答し続けなければならない

テーマ作成者のためのツールやテクニック

  • ブロックレベルでは、テーマの作者はあまりコントロールできません。
  • 技術的には、カスタム CSS を大量に記述して WordPress コア部分の動作を覆すことは可能ですが、多くの場合、そのシナリオは避けた方が良い
  • 次のメジャーアップデートで、せっかく書いたものが一掃されてしまう可能性があるからです
  • 特に Group、Row、Stack、Columns などのコンテナ/レイアウトブロックに当てはまります。
  • ほぼ全てのシナリオで、一般的な経験則は、WordPress が提供するもので作業することです
  • これらのブロックとそのサポート機能は、新しいリリースごとに強力になっています
  • テーマ作者が最もコントロールできるのは、タイポグラフィーとスペーシングのプリセットを利用した theme.json の中

流体タイポグラフィ

  • WordPress 6.1 では、theme.json による組み込みの流体タイポグラフィサイズサポートが導入された
  • これにより、テーマ開発者は指定した範囲内のカスタムサイズを登録して、スクリーンサイズに応じて拡大・縮小することができ、WordPress は裏で複雑な計算をすべて処理する
  • テーマ作者は、すべてのサイズを fluid に設定したり、個々のサイズに対してこの機能を有効／無効にしたりすることができる
  • 以下の theme.json コードは、 TT3 の例を再構築したもの
  • settings.typography.fontSize プロパティを介して設定できる３つの例を示しています
{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "settings": {
    "typography": {
      "fluid": true,
      "fontSizes": [
        {
          "fluid": {
            "min": "1rem",
            "max": "1.125rem"
          },
          "size": "1.125rem",
          "slug": "medium"
        },
        {
          "fluid": {
            "min": "1.75rem",
            "max": "1.875rem"
          },
          "size": "1.75rem",
          "slug": "large"
        },
        {
          "fluid": false,
          "size": "2.25rem",
          "slug": "x-large"
        }
      ]
    }
  }
}
  • ユーザーから見ると、UI 上では通常のサイズ選択と同じようにみえるでしょう

https://developer.wordpress.org/news/files/2023/02/fluid-font-sizes-1536x800.jpg

  • しかし、フォントサイズの大きさや小ささの見え方は、全ての画面サイズに依存します
  • これは、読者が閲覧するデバイスに合わせて自然に流れるようなタイポグラフィを実現する上で、大きなメリットになります

流体スペーシング

  • WordPress には、フォントサイズのような流動的なスペーシングシステムは、最初から含まれていません
  • これは、流体マージン、パディング、ギャップオプションを作成するために clamp() を使用するなど、彼らが選択した任意の有効な CSS 値を追加できることを意味する
  • TT3 は、theme.json の settings.spacing.spacingSizes 設定を使用して、流体スペーシングプリセットを実装する方法を確固たる例として役立ちます
{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "settings": {
    "spacing": {
      "spacingScale": {
        "steps": 0
      },
      "spacingSizes": [
        {
          "size": "clamp(1.5rem, 5vw, 2rem)",
          "slug": "30",
          "name": "1"
        },
        {
          "size": "clamp(1.8rem, 1.8rem + ((1vw - 0.48rem) * 2.885), 3rem)",
          "slug": "40",
          "name": "2"
        },
        {
          "size": "clamp(2.5rem, 8vw, 4.5rem)",
          "slug": "50",
          "name": "3"
        }
      ]
    }
  }
}
  • clamp() の値を K さんするオンラインツールがいくつかありますし、Smashing Magazine の clamp チュートリアルのように、自分で計算するための公式もあります。
  • カスタムプリセットを追加すると、エンドユーザーがマージン、パディング、ギャップのいずれかのオプションをサポートするブロックの UI で調整するためのシンプルなスライダーを提供することでうまく機能する

https://developer.wordpress.org/news/files/2023/02/fluid-spacing-1536x800.jpg

  • ユーザーは、この奇妙な値が何であるかを気にする必要がありません。
  • 訪問者がどのような画面サイズから見ているかに関係なく、単に機能する
  • テーマ制作者にとっては、既存の CSS の機能を WordPress のグローバルスタイルシステムに統合する強力な方法になります。
Clone this wiki locally