الطريقة التي نكتب بها سمات CSS لـ WordPress هي في خضم تغييرات كاسحة. لقد شاركت مؤخرًا تقنية لـ إضافة دعم نوع السوائل في ووردبريس عن طريق theme.json، ملف جديد كان WordPress يضغط بشدة لتصبح مصدرًا مركزيًا للحقيقة لتحديد الأنماط في سمات WordPress التي تدعم ميزات تحرير الموقع بالكامل (FSE).

لا تنتظر style.css ملف؟ لا يزال لدينا ذلك. في الواقع، style.css is لا يزال ملفًا مطلوبًا في قوالب الكتلة ، على الرغم من أن دورها قد تم تقليصه إلى حد كبير إلى المعلومات الوصفية المستخدمة لتسجيل السمة. ومع ذلك ، فإن الحقيقة هي ذلك theme.json لا يزال قيد التطوير النشط ، مما يعني أننا في فترة انتقالية حيث قد تجد أنماطًا محددة هناك ، في styles.css أو حتى على مستوى الكتلة.

إذن ، كيف يبدو التصميم في أيام WordPress FSE هذه؟ هذا ما أريد تغطيته في هذا المقال. هناك نقص في الوثائق الخاصة بتصميم سمات القوالب في ملف دليل مطور قوالب ووردبريس، لذلك كل ما نغطيه هنا هو ما جمعته حول مكان وجود الأشياء حاليًا بالإضافة إلى المناقشات حول مستقبل سمات WordPress.

تطور أنماط WordPress

الميزات التطويرية الجديدة المضمنة في وورد 6.1 تجعلنا أقرب إلى نظام من الأساليب المحددة تمامًا في theme.json، ولكن لا يزال هناك الكثير من العمل الذي يتعين القيام به قبل أن نتمكن من الاعتماد عليه تمامًا. إحدى الطرق التي يمكننا من خلالها الحصول على فكرة عما سيأتي في الإصدارات المستقبلية هي استخدام البرنامج المساعد جوتنبرج. هذا هو المكان الذي يتم فيه تشغيل الميزات التجريبية غالبًا.

هناك طريقة أخرى يمكننا من خلالها الشعور بما نحن عليه من خلال النظر في تطور قوالب WordPress الافتراضية. حتى الآن ، هناك ثلاثة سمات افتراضية تدعم التحرير في الموقع الكامل:

لكن لا تبدأ تداول CSS بـ style.css لأزواج قيمة الملكية JSON بتنسيق theme.json للتو. لا تزال هناك قواعد نمط CSS تحتاج إلى الدعم في theme.json قبل أن نفكر في القيام بذلك. تتم حاليًا مناقشة المشكلات المهمة المتبقية بهدف نقل جميع قواعد نمط CSS بالكامل إليها theme.json ودمج مصادر مختلفة من theme.json الى واجهة المستخدم لتعيين الأنماط العالمية مباشرة في محرر موقع WordPress.

هذا يتركنا في موقف صعب نسبيًا. ليس فقط هناك لا يوجد مسار واضح لتجاوز أنماط السمة، ولكن من غير الواضح من أين يأتي مصدر هذه الأنماط - هل هو من طبقات مختلفة من theme.json الملفات، style.cssأو مكوّن جوتنبرج الإضافي أو أي مكان آخر؟

لماذا theme.json بدلا من style.css?

قد تتساءل لماذا يتجه WordPress نحو تعريف الأنماط المستند إلى JSON بدلاً من ملف CSS التقليدي. يوضح بن دواير من فريق تطوير جوتنبرج ببلاغة سبب وجود ملف theme.json النهج هو فائدة لمطوري السمات.

من الجدير قراءة منشور Ben ، لكن اللحم موجود في هذا الاقتباس:

يمثل تجاوز CSS ، سواء أكان أسلوب التخطيط أو الإعداد المسبق أو الحظر ، عقبة أمام التكامل وقابلية التشغيل البيني: يصبح الحفاظ على التكافؤ المرئي بين الواجهة الأمامية والمحرر أكثر صعوبة ، وقد تتعارض الترقيات لمنع العناصر الداخلية مع التجاوزات. علاوة على ذلك ، فإن CSS المخصص أقل قابلية للنقل عبر سمات الكتلة الأخرى.

من خلال تشجيع مؤلفي الموضوع على الاستخدام theme.json واجهة برمجة التطبيقات (API) حيثما أمكن ، التسلسل الهرمي للأنماط المحددة "base> theme> user" يمكن حلها بشكل صحيح.

تتمثل إحدى الفوائد الرئيسية لنقل CSS إلى JSON في أن JSON هو تنسيق يمكن قراءته آليًا ، مما يعني أنه يمكن عرضه في واجهة مستخدم محرر موقع WordPress عن طريق جلب واجهة برمجة تطبيقات ، وبالتالي السماح للمستخدمين بتعديل القيم الافتراضية وتخصيص مظهر الموقع بدون كتابة أي CSS على الإطلاق. يوفر أيضًا طريقة لتصميم الكتل بشكل متسق ، مع توفير بنية تنشئ طبقات من الخصوصية بحيث تأخذ إعدادات المستخدم الأولوية القصوى على تلك المحددة في theme.json. هذا التفاعل بين أنماط مستوى الموضوع في theme.json والأنماط التي يحددها المستخدم في واجهة مستخدم الأنماط العالمية هي ما يجعل منهج JSON جذابًا للغاية.

يحافظ المطورون على التناسق في JSON ، ويكتسب المستخدمون المرونة مع التخصيصات الخالية من التعليمات البرمجية. هذا هو الفوز.

هناك فوائد أخرى ، بالتأكيد ، و يسرد Mike McAlister من WP Engine العديد في سلسلة Twitter هذه. يمكنك أن تجد المزيد من الفوائد في هذا مناقشة متعمقة في مدونة Make WordPress Core. وبمجرد أن تقرأ هذه القراءة ، قارن بين مزايا نهج JSON مع الطرق المتاحة لتعريف الأنماط وتجاوزها في السمات الكلاسيكية.

تحديد الأنماط باستخدام عناصر JSON

لقد رأينا بالفعل الكثير من التقدم فيما يتعلق بأجزاء الموضوع theme.json قادر على التصميم. قبل إصدار WordPress 6.1 ، كان كل ما يمكننا فعله حقًا هو عناوين وروابط النمط. الآن ، مع WordPress 6.1 ، يمكننا إضافة أزرار وتعليقات توضيحية واستشهادات وعناوين إلى هذا المزيج.

ونفعل ذلك بالتعريف عناصر JSON. فكر في العناصر كمكونات فردية تعيش في قالب WordPress. لنفترض أن لدينا كتلة تحتوي على عنوان وفقرة وزر. هذه القطع الفردية هي عناصر ، وهناك elements الكائن في theme.json حيث نحدد أنماطهم:

{
  "version": 2,
  "settings": {},
  // etc.
  "styles": {
    // etc.
    "elements": {
        "button": { ... },
        "h1": { ... },
        "heading": { ... },
    },
  },
  "templateParts": {}
}

أفضل طريقة لوصف عناصر JSON هي المكونات منخفضة المستوى للقوالب والكتل التي لا تحتاج إلى تعقيد الكتل. هم تمثيلات HTML البدائية التي لم يتم تعريفها في كتلة ولكن يمكن استخدامها عبر الكتل. كيف يتم دعمها في WordPress (ومكوِّن Gutenberg الإضافي) موصوف في ملف دليل محرر الكتلة وهذا برنامج تعليمي لتحرير الموقع بالكامل بواسطة كارولينا نيمارك.

على سبيل المثال ، تم تصميم الروابط بتنسيق elements كائن ولكنها ليست كتلة في حد ذاتها. ولكن يمكن استخدام ارتباط في كتلة وسوف يرث الأنماط المحددة في ملف elements.link الكائن في theme.json. هذا لا يلخص تعريف عنصر بشكل كامل ، على الرغم من أن بعض العناصر مسجلة أيضًا ككتل ، مثل كتل العنوان والأزرار - ولكن لا يزال من الممكن استخدام هذه الكتل داخل الكتل الأخرى.

فيما يلي جدول بالعناصر المتوفرة حاليًا للتصميم theme.json, بإذن من كارولينا:

كما ترى ، لا تزال الأيام الأولى وما زالت هناك حاجة إلى الانتقال من مكون Gutenberg الإضافي إلى WordPress Core. ولكن يمكنك أن ترى مدى سرعة القيام بشيء مثل تصميم جميع العناوين في قالب ما على مستوى العالم دون البحث عن المحددات في ملفات CSS أو DevTools.

علاوة على ذلك ، يمكنك أيضًا البدء في معرفة كيفية تكوين بنية theme.json نوع من أشكال طبقات الخصوصية ، من العناصر العالمية (على سبيل المثال headings) للعناصر الفردية (على سبيل المثال h1) وأنماط مستوى الكتلة (على سبيل المثال h1 الواردة في كتلة).

تتوفر معلومات إضافية حول عناصر JSON بتنسيق هذا اقتراح جعل WordPress و هذه التذكرة المفتوحة في GitHub في ملحق Gutenberg.

خصوصية JSON و CSS

دعونا نستمر في الحديث عن خصوصية CSS. لقد ذكرت سابقًا أن نهج JSON في التصميم يؤسس تسلسلاً هرميًا. وهذا صحيح. الأنماط التي تم تحديدها في عناصر JSON بتنسيق theme.json تعتبر أنماط سمة افتراضية. وأي شيء يحدده المستخدم في واجهة المستخدم للأنماط العامة سوف يلغي الإعدادات الافتراضية.

بعبارات أخرى: تحمل أنماط المستخدم خصوصية أكثر من أنماط السمة الافتراضية. دعنا نلقي نظرة على كتلة الأزرار للتعرف على كيفية عمل ذلك.

أنا استخدم إفراغ، سمة WordPress فارغة بدون نمط CSS. سأضيف كتلة زر على صفحة جديدة.

حسنًا ، نعلم أن WordPress Core يأتي مع بعض التصميم الخفيف. الآن ، سأنتقل إلى سمة TT3 الافتراضية من WordPress 6.1 وقم بتنشيطها. إذا قمت بتحديث صفحتي باستخدام الزر ، فسيغير الزر الأنماط.

يمكنك أن ترى بالضبط من أين تأتي هذه الأنماط الجديدة في TT3's theme.json ملف. يخبرنا هذا أن أنماط عنصر JSON لها الأسبقية على أنماط WordPress Core.

الآن سأقوم بتعديل TT3 عن طريق تجاوزه بامتداد theme.json ملف في نسق فرعي ، حيث يتم تعيين لون الخلفية الافتراضي لكتلة الزر على اللون الأحمر.

لكن لاحظ زر البحث في لقطة الشاشة الأخيرة. يجب أن يكون أحمر أيضًا ، أليس كذلك؟ يجب أن يعني هذا أنه تم تصميمه على مستوى آخر إذا كان التغيير الذي أجريته على المستوى العالمي. إذا أردنا التغيير على حد سواء الأزرار ، يمكننا القيام بذلك على مستوى المستخدم باستخدام واجهة مستخدم الأنماط العالمية في محرر الموقع.

قمنا بتغيير لون الخلفية لكلا الزرين إلى اللون الأزرق وقمنا بتعديل النص أيضًا باستخدام واجهة مستخدم الأنماط العامة. لاحظ أن اللون الأزرق من هناك له الأسبقية على أنماط السمات!

محرك النمط

هذه فكرة سريعة جدًا ، ولكنها جيدة ، عن كيفية إدارة خصوصية CSS في قوالب قوالب WordPress. لكنها ليست الصورة الكاملة لأنها لا تزال غير واضحة أين يتم إنشاء هذه الأنماط. يحتوي WordPress على أنماطه الافتراضية التي تأتي من مكان ما ، ويستهلك البيانات بتنسيق theme.json لمزيد من قواعد الأنماط ، وتجاوز تلك التي تحتوي على أي شيء محدد في الأنماط العالمية.

هل هذه الأنماط مضمنة؟ هل هم في ورقة أنماط منفصلة؟ ربما تم حقنها على الصفحة بتنسيق ?

هذا ما الجديد أسلوب المحرك نأمل أن تحل. إن Style Engine عبارة عن واجهة برمجة تطبيقات جديدة في WordPress 6.1 تهدف إلى تحقيق التناسق في كيفية إنشاء الأنماط ومكان تطبيق الأنماط. بمعنى آخر ، يأخذ كل المصادر الممكنة للتصميم وهو مسؤول بشكل فردي عن إنشاء أنماط الكتلة بشكل صحيح. اعلم اعلم. تجريد آخر فوق التجريدات الأخرى فقط لتأليف بعض الأنماط. لكن امتلاك واجهة برمجة تطبيقات مركزية للأنماط ربما يكون الحل الأكثر أناقة نظرًا لأن الأنماط يمكن أن تأتي من عدد من الأماكن.

نحن فقط نلقي نظرة أولى على Style Engine. في الواقع ، هذا ما تم إنجازه حتى الآن ، حسب التذكرة:

• تدقيق ودمج حيث يولد الكود CSS لدعم الكتلة في النهاية الخلفية بحيث يتم تسليمها من نفس المكان (على عكس أماكن متعددة). يغطي هذا قواعد CSS مثل الهامش ، والحشو ، والطباعة ، والألوان ، والحدود.
• قم بإزالة الأنماط المتكررة الخاصة بالتخطيط وإنشاء أسماء فئات دلالية.
• قلل عدد علامات الأنماط المضمنة التي نطبعها على الصفحة لدعم الكتلة والتخطيط والعنصر.

هذا هو الأساس لإنشاء واجهة برمجة تطبيقات واحدة تحتوي على جميع قواعد نمط CSS لموضوع ما ، أينما أتوا. إنه ينظف الطريقة التي سيضخ بها WordPress الأنماط المضمنة قبل 6.1 ويؤسس نظامًا لأسماء الفئات الدلالية.

يمكن العثور على مزيد من التفاصيل حول الأهداف طويلة المدى وقصيرة المدى لـ Style Engine في هذا اجعل مناقشة WordPress جوهرية. يمكنك أيضًا متابعة قضية تتبع و لوحة المشروع لمزيد من التحديثات.

العمل مع عناصر JSON

تحدثنا قليلاً عن عناصر JSON في ملف theme.json وكيف أنها أساسًا أساسيات HTML لتحديد الأنماط الافتراضية لأشياء مثل العناوين والأزرار والروابط ، من بين أمور أخرى. الآن ، دعونا ننظر في الواقع استخدام عنصر JSON وكيف يتصرف في سياقات التصميم المختلفة.

تحتوي عناصر JSON بشكل عام على سياقين: طابق عالمي و مستوى الكتلة. يتم تحديد أنماط المستوى العام بخصوصية أقل مما هي عليه على مستوى الكتلة لضمان أن الأنماط الخاصة بالكتلة لها الأسبقية للتناسق أينما يتم استخدام الكتل.

الأنماط العامة لعناصر JSON

لنلقِ نظرة على سمة TT3 الافتراضية الجديدة ونختبر كيفية تصميم أزرارها. ما يلي هو نسخة مختصرة ولصق من TT3 theme.json ملف (هنا ملف كود كامل) يعرض قسم الأنماط العامة ، ولكن يمكنك العثور على الكود الأصلي هنا.

{
  "version": 2,
  "settings": {},
    // ...
  "styles": {
    // ...
    "elements": {
      "button": {
        "border": {
          "radius": "0"
        },
        "color": {
          "background": "var(--wp--preset--color--primary)",
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":focus": {
          "color": {
            "background": "var(--wp--preset--color--contrast)",
            "text": "var(--wp--preset--color--base)"
          }
        },
        ":active": {
          "color": {
            "background": "var(--wp--preset--color--secondary)",
            "text": "var(--wp--preset--color--base)"
          }
        }
      },
      "h1": {
        "typography": { }
      },
      // ...
      "heading": {
        "typography": {
          "fontWeight": "400",
          "lineHeight": "1.4"
      }
      },
      "link": {
        "color": {
          "text": "var(--wp--preset--color--contrast)"
        },
        ":hover": {
          "typography": {
            "textDecoration": "none"
          }
        },
        ":focus": {
          "typography": {
            "textDecoration": "underline dashed"
          }
        },
        ":active": {
          "color": {
            "text": "var(--wp--preset--color--secondary)"
          },
          "typography": {
            "textDecoration": "none"
          }
        },
        "typography": {
          "textDecoration": "underline"
        }
      }
     },
    // ...
  },
  "templateParts": {}
}

تم تصميم جميع الأزرار على المستوى العالمي (styles.elements.button).

يمكننا تأكيد ذلك في DevTools أيضًا. لاحظ أن فئة تسمى .wp-element-button هو المحدد. يتم استخدام نفس الفئة أيضًا لتصميم الحالات التفاعلية.

مرة أخرى ، يحدث هذا التصميم على المستوى العالمي ، قادمًا من theme.json. عندما نستخدم زرًا ، سيكون له نفس الخلفية لأنهما يشتركان في نفس المحدد ولا توجد قواعد نمط أخرى تتجاوزه.

جانبا ، تمت إضافة ووردبريس 6.1 دعم لتصميم الحالات التفاعلية لعناصر معينة ، مثل الأزرار والروابط ، باستخدام الفئات الزائفة في theme.json - بما فيها :hover, :focusو :active - أو واجهة مستخدم الأنماط العامة. مهندس آلي ديف سميث يوضح هذه الميزة في فيديو يوتيوب.

يمكننا تجاوز لون خلفية الزر إما في theme.json (يفضل أن يكون ذلك في قالب فرعي نظرًا لأننا نستخدم سمة WordPress افتراضية) أو في إعدادات الأنماط العامة في محرر الموقع (لا حاجة إلى سمة فرعية نظرًا لأنها لا تتطلب تغيير رمز).

ولكن بعد ذلك ستتغير الأزرار دفعة واحدة. ماذا لو أردنا تجاوز لون الخلفية عندما يكون الزر جزءًا من كتلة معينة؟ هذا هو المكان الذي تلعب فيه أنماط مستوى الكتلة.

أنماط الكتلة للعناصر

لفهم كيف يمكننا استخدام الأنماط وتخصيصها على مستوى الكتلة ، دعنا نغير لون خلفية الزر الموجود في كتلة البحث. تذكر أن هناك كتلة زر ، ولكن ما نقوم به هو تجاوز لون الخلفية على مستوى كتلة كتلة البحث. بهذه الطريقة ، نطبق اللون الجديد هناك فقط بدلاً من تطبيقه عالميًا على جميع الأزرار.

للقيام بذلك ، نحدد الأنماط على styles.blocks الكائن في theme.json. هذا صحيح ، إذا حددنا الأنماط العامة لجميع الأزرار styles.elements، يمكننا تحديد الأنماط الخاصة بالكتلة لعناصر الأزرار الموجودة على styles.block، الذي يتبع هيكلًا مشابهًا:

{
  "version": 2,
  // ...
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": {
      "core/search": {
        "elements": {
          "button": {
            "color": {
              "background": "var(--wp--preset--color--quaternary)",
              "text": "var(--wp--preset--color--base)"
            }
          }
        },
        // ...
      }
    }
  }
}

أنظر لهذا؟ أضع background و text على خصائص styles.blocks.core/search.elements.button مع متغيرين CSS تم إعدادهما مسبقًا في WordPress.

النتائج؟ زر البحث الآن أحمر (--wp--preset--color--quaternary) ، وتحتفظ كتلة الأزرار الافتراضية بخلفيتها الخضراء الزاهية.

يمكننا أن نرى التغيير في DevTools أيضًا.

وينطبق الشيء نفسه إذا أردنا تصميم الأزرار المضمنة في كتل أخرى. والأزرار هي مجرد مثال واحد ، لذلك دعونا نلقي نظرة على مثال آخر.

مثال: تصميم العناوين في كل مستوى

دعنا نقود كل هذه المعلومات إلى المنزل بمثال. هذه المرة سوف:

• صمم جميع العناوين بشكل شامل
• صمم جميع عناصر العنوان 2
• عناصر عنوان النمط 2 في كتلة Query Loop

أولاً ، لنبدأ بالهيكل الأساسي لـ theme.json:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": { },
    // Block-level styles
    "blocks": { }
  }
}

هذا يحدد مخططًا لأنماطنا العالمية وعلى مستوى الكتلة.

صمم جميع العناوين بشكل شامل

دعونا نضيف headings الاعتراض على أنماطنا العالمية وتطبيق بعض الأنماط:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
    },
    // Block-level styles
    "blocks": { }
  }
}

يقوم هذا بتعيين لون جميع العناوين إلى اللون الأساسي المحدد مسبقًا في WordPress. دعنا نغير لون وحجم الخط لعناصر العنوان 2 على المستوى العالمي أيضًا:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": { }
  }
}

الآن ، تم تعيين جميع عناصر العنوان 2 لتكون اللون الأساسي المحدد مسبقًا بامتداد حجم الخط المرن. ولكن ربما نريد إصلاح fontSize لعنصر العنوان 2 عند استخدامه في كتلة بحث الاستعلام:

{
  "version": 2,
  "styles": {
    // Global-level syles
    "elements": {
      "heading": {
        "color": "var(--wp--preset--color--base)"
      },
      "h2": {
        "color": "var(--wp--preset--color--primary)",
        "typography": {
          "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)"
        }
      }
    },
    // Block-level styles
    "blocks": {
      "core/query": {
        "elements": {
          "h2": {
            "typography": {
              "fontSize": 3.25rem
            }
          }
        }
      }
    }
  }
}

لدينا الآن ثلاثة مستويات من الأنماط لعناصر العنوان 2: جميع العناوين ، وجميع عناصر العنوان 2 ، وعناصر العنوان 2 المستخدمة في كتلة Query Loop.

أمثلة السمة الحالية

بينما نظرنا فقط إلى أمثلة التصميم للأزرار والعناوين في هذه المقالة ، يدعم WordPress 6.1 تصميم عناصر إضافية. هناك جدول يحددها في "تحديد الأنماط باستخدام عناصر JSON" والقسم الخاص به.

ربما تتساءل عن عناصر JSON التي تدعم خصائص CSS ، ناهيك عن كيفية التصريح عنها. بينما ننتظر الوثائق الرسمية ، فإن أفضل الموارد التي لدينا ستكون theme.json ملفات للسمات الموجودة. سأقوم بتوفير روابط إلى السمات بناءً على العناصر التي يقومون بتخصيصها ، والإشارة إلى الخصائص التي يتم تخصيصها.

تأكد من إعطاء كل theme.json قم بتقديم مظهر جيد لأن هذه السمات تتضمن أمثلة ممتازة على التصميم على مستوى الكتلة في ملف styles.blocks موضوع.

اختتام

التغييرات المتكررة على محرر الموقع الكامل أصبحت ملف المصادر الرئيسية للتهيج لكثير من الناس، بما فيها مستخدمي Gutenberg البارعين في مجال التكنولوجيا. حتى قواعد CSS البسيطة جدًا ، والتي تعمل جيدًا مع السمات الكلاسيكية ، لا يبدو أنها تعمل مع سمات الحظر بسبب طبقات جديدة من الخصوصية غطينا في وقت سابق.

بخصوص أ اقتراح جيثب لإعادة تصميم محرر الموقع في وضع متصفح جديد ، سارة جودنج تكتب في منشور WP Tavern:

من السهل أن تضيع أثناء محاولة الالتفاف على محرر الموقع إلا إذا كنت تعمل ليلاً ونهارًا داخل الأداة. التنقل سريع ومربك ، خاصة عند الانتقال من تصفح القوالب إلى تحرير القالب لتعديل الكتل الفردية.

حتى بصفتي متسابقًا مبكراً متحمسًا في عالم محرر قوالب Gutenberg وموضوعات block-eye ، لدي الكثير من الإحباطات الخاصة بي. أنا متفائل ، على الرغم من ذلك ، وأتوقع أن محرر الموقع ، بمجرد اكتماله ، سيكون أداة ثورية للمستخدمين ومطوري السمات البارعين على حد سواء. هذه سقسقة الأمل يؤكد ذلك بالفعل. في غضون ذلك ، يبدو أننا يجب أن نستعد لمزيد من التغييرات ، وربما حتى رحلة وعر.

مراجع حسابات

أقوم بإدراج جميع الموارد التي استخدمتها أثناء البحث عن معلومات لهذه المقالة.

عناصر JSON

الأنماط العالمية

أسلوب المحرك

شكرا للقراءة! أرغب في سماع تأملاتك الخاصة حول استخدام سمات الكتلة وكيفية إدارة CSS الخاص بك.