未来のテーマ：デザインフレームワークとマスターテーマ

WordPressのテーマには豊富な歴史があります。 何年にもわたって、テーマの作成者はプラットフォームに多数の機能をもたらしてきました。 一部には、エンドユーザーが必要とする機能を作成するために、WordPressの基本的な問題を解決しなければならないことがよくあるためです。

すべてのテーマ作成者が今日使用している投稿クラスと本文クラスは？ それらはもともとサンドボックスと呼ばれるテーマにありました。

注目の画像？ それらは10年前に雑誌のテーマで普及しました。

投稿フォーマットはTumblrから始まったと思いますか？ WordPressの共同作成者であるMattMullenwegは、2004年にテーマに投稿を作成する方法を教えてくれましたが、それ以前は存在していました。

WordPressの機能は、多くの場合、テーマの世界で始まります。 テーマの作者が作品に取り入れているアイデアについて、何年にもわたる実験と反復を当然のことと思うことがあります。 ブロックエディタでさえ、伝統的にテーマデザインの領域内にあったアイテムを処理しています。 カバーブロックは良い例です。 何年もの間、テーマの作成者は、テキストとボタンがオーバーレイされた基本的なヒーロー画像のテーマオプションを構築していました。 結果はしばしば不格好で、ユーザーにとって理想的ではありませんでした。 この機能をコアに組み込むことで、ユーザーはこのカバーブロックを許可されたブロック領域に配置できるようになりました。

多くのテーマ機能がコアになる理由は、標準化されたときにそれらが単により良く機能するためです。 ユーザーは何を期待できるかを知っており、テーマの作成者はユーザーエクスペリエンスの問題を解決するのではなく、デザインの側面に集中できます。

過去の問題の一部は、コアに採用された各新機能が標準のデザインパターンや命名スキームに従わなかったことです。 WordPressテーマを設計する際の大きなスキルは、何百ものクラスのミッシュマッシュをメモリにコミットすることです。

ブロックエディタは、ユニバーサルデザインフレームワークを作成することでそれを変えるユニークな立場にあります。

WordPressにはフロントエンドのデザインフレームワークが必要ですか？

将来的にはブロックパターンが登場し、その後のある時点でフルサイトのカスタマイズが行われるため、テーマの作成者はこの船がどこを航行しているのか正確に疑問に思っています。 エンドユーザーにとって可能性は無限大なので、エキサイティングです。 ある方法で帝国を築いてきたテーマ作者にとっては恐ろしいことですが、開発は何よりも適応に関するものです。

風景が変化しているという予見を武器に、これはテーマの作者がブロックベースの世界で彼らの未来を形作るために団結する必要がある瞬間です。

私が関わっている開発者グループの1つには、コア開発者がテーマの作成者ではないという冗談が少しあります。 テーマの作成者の観点からは、CSSデザインシステムを考えずにアイデアが無計画に一緒に投げられているように見えることがあります。

ああ、BEMが見えます。 このサブ要素が同じ命名スキームに従わないのはなぜですか？ 待って。 それは38文字のユーティリティクラスですか？

WordPressに常に欠けていたのは、ユニバーサルフロントエンドデザインシステムです。 時々、それは良いことでした。 これにより、テーマの作成者は好みのフレームワークを使用できるようになりました。 十分長い間ゲームに参加しているテーマの作者なら誰でも、そのような柔軟性は素晴らしいと言うでしょう…そうでないまでは。 ウィジェットにコンテキストクラスを追加しようとしたことがありますか？ コメントフォームラッパーにユーティリティクラスを追加するのはどうですか？ アスピリンが必要になります。 または2つ。

WordPressを使用すると、いくつかのものが石に設定され、他のものはプラグイン可能です。 一部の機能は標準のクラス命名スキームに従い、その他の機能は意味がありません。 テーマの結果は、さまざまなコンポーネントを混乱させようとして、CSSが肥大化することがよくあります。

コア機能を再作成せずに、テーマでTailwindCSSのようなユーティリティクラスのフレームワークを完全に使用することはほぼ不可能です。

これの多くは、何年にもわたるレガシーコードの積み重ねと、下位互換性に対するWordPressの取り組みに起因しています。 しかし、未来は過去に似ている必要はありません。 私たちは新しい時代の入り口にあり、今こそフロントエンドの設計者が会話に飛び込む時です。

WordPressには、堅固なフロントエンドデザインフレームワークが必要です。

これはロードされたステートメントです。 20人のデザイナーを部屋に入れて、デザインフレームワークについて話し合うように依頼すると、それは殴り合いのレシピになる可能性があります。 私は楽観主義者になる傾向があり、議論が結果をもたらすことを願っています。

グーテンベルクは私たちを部分的にこの方向に押し進めましたが、それは十分に進んでいません。 将来のフルサイト編集では、この問題に取り組むためのより包括的なアプローチが必要です。

何よりも、会話にはより多くのフロントエンドデザイナーが必要です。 .has-subtle-pale-green-background-colorが、 .bg-pale-green 、 .bg-green-100 、さらには.background-pale-greenなどのユーティリティクラスとして存在する必要がある場合は、この方法はありません。もっと冗長になりたい。 その決定に入る最適化の概念はありませんでした。 開発者がギガビットインターネット接続を実行しているとき、世界の多くが遅いペースで進んでいることを忘れがちです。

ユーティリティクラスを適切に使用するコンポーネントベースの命名スキームは、いくつかのスイートスポットに当てはまる可能性のある1つのオプションです。 これは、あるCSSフレームワークが別のCSSフレームワークを超えるという議論ではありません。 多くの優れた既存のオプションがあります。 WordPressは、他のプロジェクトによって築かれた基礎から借用し、WordPress独自の何かを作成することによって、この問題に正面から取り組む必要があります。 それはこの分野のリーダーでなければなりません。

デザインフレームワークもプラグインに関するものです。 テーマシステムの黎明期から2人が進行中の戦争を繰り広げてきたテーマの領域へのいくつかのクロスオーバーがあります。 テーマとプラグインの間の戦場には、優れたアイデアの死が散らばっています。 あまりにも多くの人が、コアに着陸するために必要なサポートを獲得することはありませんでした。 ある種のユニバーサルデザイン基準は、問題の洪水を食い止め、停戦を要求する可能性があります。

カスタムフロントエンドコンポーネントを出力するプラグインには、たとえば、現在のテーマが垂直リズムをどのように処理するかを知る方法がありません。 上マージンを使用しますか、それとも下マージンを使用しますか？ 使用される値と単位は何ですか？ これは基本的なことであり、プラグインがそれを処理するためにカスタムCSSを追加しようとすると、ほとんどの場合壊れます。

WordPressには、すべての可動部分をフロントエンドで調和させるための設計フレームワークまたは言語が必要です。 いつかそこに着くと確信しています。 過去のランダムなコンポーネントや命名スキームよりもまとまりがあることを願っています。 また、開発者や設計者が準備できるように、技術的な詳細の一部を記入する明確なロードマップを用意する必要があります。

1つのテーマの未来は可能ですか？

Rich Taborは、彼の記事A Look at the WordPress Themes of the Futureで、コアWordPressが単一の親テーマを提供できると主張しています。 テーマの作成者は、この「マスター」テーマの子テーマの作成に追いやられるという考え方です。

多くの人にとっての直感的な反応は、それが機能せず、テーマが個性を失い、私たちがクッキーカッターのデザインの世界に住むことになるということです。

現実には、私たちは、ひとり親またはマスターテーマのアイデアが真剣に検討されている未来に向かって進んでいます。

ほとんどのテーマは、ほぼすべてのテーマに存在する標準要素のカスタムグループです。 文体上の懸念は別として、ヘッダーのレイアウトなど、テーマを互いに異なるものにするいくつかの決定があります。 1つのテーマでは、1つのブロックにサイトタイトルとナビゲーションメニューが含まれる場合があります。 もう1つは、ナビゲーションメニュー、タイトル、および下に2番目のナビゲーションメニューがある場合があります。 ただし、別のテーマで検索ボックスが表示される場合があります。 フルサイトのカスタマイズがユーザーに属する世界では、これらの決定は、開発者エクスペリエンスではなく、ユーザーエクスペリエンスの一部になります。

テーマは、カラーパレット、タイポグラフィ、および独自の風変わりなブランドで際立つ必要があります。これは、CSS Zen Gardenの時代の復活ですが、はるかに大規模です。

私はそれについて悲しくはありません。 この分野のトップデザイナー間の競争を見るのは興味深いでしょう。 それはまた、WordPressのテーマを、CSSの知識と決意を少し持っていれば誰でもできる時代に戻すかもしれません。

1つのテーマがすべてのテーマを支配する未来への準備はまだ整っていませんが、会話を始める場所です。 この潜在的な将来のためにWordPressを設計した場合、マスターテーマを実装していなくても、ロードマップはどのようになりますか？ どのような障害が邪魔になっていますか？ それは実行可能ですか？