تنسيق Discourse باستخدام المتغيرات: دعوة لبساطة الدلالات

[manuel (Manuel Kostka)]

متابعةً للنقاش من Styling Discourse with variables: Show & Tell:

لقد أضفنا مؤخرًا العديد من متغيرات CSS إلى Discourse. تجعل هذه المتغيرات تخصيص السمات وتخصيص جوانب واجهة المستخدم أسهل بكثير. للعديد من التغييرات، لن تحتاج بعد الآن إلى استهداف عناصر محددة جدًا في HTML، وبدلاً من ذلك قم بتغيير متغير واحد فقط.

أنا أقدر تمامًا الجهد المبذول لتحسين تجربة تخصيص سمات Discourse! ومع ذلك، لست مقتنعًا تمامًا بأن نهج إضافة الكثير من متغيرات CSS كما هو مشترك في الموضوع أعلاه هو الحل الأمثل. أردت مشاركة بعض الأفكار حول السبب.

لقد كنت أجرب هذا النهج بنفسي من خلال Canvas Theme Template، والذي يوفر في الأساس مجموعة من المتغيرات القابلة للتعديل لبناء سمات أساسية:

:root {
  /* Layout */
  --d-max-width: 1110px;
  --canvas-nav-space: 0.75rem;
  --canvas-content-padding: 1.5rem;
  --canvas-topic-list-padding: 0.8em;
  
  /* Base Styles */
  --canvas-background: var(--secondary);
  --canvas-surface: var(--secondary);
  --canvas-border: 1px solid var(--primary-500);
  --canvas-border-light: 1px solid var(--primary-200);
  
  /* Border Radius */
  --d-border-radius: 2px;
  --d-border-radius-large: 2px;
  --d-button-border-radius: 2px;
  --d-input-border-radius: var(--d-button-border-radius);
  --d-nav-pill-border-radius: var(--d-button-border-radius);
  
  /* Button Styles */
  --canvas-button-padding: 0.5em 0.65em;
  --canvas-button-primary-padding: 0.5em 0.65em;
  
  /* Header */
  --canvas-header-height: 4rem;
  --canvas-header-background: var(--header_background);
  --canvas-header-border: none;
  --canvas-header-shadow: var(--shadow-header);
  
  /* Sidebar */
  --d-sidebar-width: 17em;
  --d-sidebar-background: var(--secondary);
  --canvas-sidebar-border: 1px solid var(--primary-low);
  --canvas-sidebar-scrollbar: var(--scrollbarWidth);
  --d-sidebar-row-height: 2.2em;
  --d-sidebar-highlight-background: var(--primary-low);

  /* And several more... */
}

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

الحمل المعرفي وقابلية الاكتشاف

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

نقص منطق التتالي

يقوم التنفيذ الحالي بتعيين قيم ثابتة مباشرة للمتغيرات دون إنشاء تسلسل هرمي مناسب للتتالي:

--d-sidebar-link-color: var(--primary-high);
--d-nav-background-color--active: transparent;
--table-border-width: 1px;

هذا يعني عدم وجود وراثة من متغيرات أكثر عمومية مثل --link-color أو --border-width. إذا كنت أرغب في إجراء تغييرات منهجية، فأنا بحاجة إلى تحديث متغيرات محددة متعددة بدلاً من تغيير قيمة تأسيسية واحدة.

فجوة التصميم والتطوير

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

نهج بديل يحتضن بنية المكون

أعتقد أنه يمكننا تحقيق نفس الهدف بشكل طبيعي أكثر من خلال الجمع بين المتغيرات الدلالية الأساسية مع استهداف المكونات الموثوقة. بدلاً من وجود قائمة طويلة من المتغيرات المحددة، ماذا لو كان بإمكاننا الاعتماد على فئات مكونات فريدة ومسماة باستمرار في جميع أنحاء Discourse؟ أشياء مثل .d-sidebar و .d-topic-list و .d-header.

ثم قم بإقران ذلك بمجموعة أصغر من المتغيرات التأسيسية التي تتتالي بالفعل بالطريقة التي من المفترض أن تعمل بها CSS:

/* Set the design foundation */
:root {
  --d-border-width: 2px;
  --d-surface-color: #3498db;
  --d-space-1: 1rem;
}

/* Override at the component level when you need to */
.d-topic-list,
.d-sidebar {
  --d-border-width: 1px;
}

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

[RGJ (Richard - Communiteq)]

@manuel

بالنسبة لي، يبدو هذا أشبه بكيفية عمل CSS بشكل طبيعي

حسنًا، أعتقد أن الطريقة التي يعمل بها CSS بشكل طبيعي هي ببساطة تخطي المتغيرات والقيام بما يلي:

/* تعيين أساس التصميم */
body {
  border-width: 2px;
  background-color: #3498db;
  margin: 1rem;
}

/* تجاوز الإعدادات على مستوى المكون عند الحاجة */
.d-topic-list,
.d-sidebar {
  border-width: 1px;
}

ربما أنا فقط كبير في السن.
المشكلة الحقيقية هي هذا

@manuel

ماذا لو كان بإمكاننا الاعتماد فقط على فئات المكونات الفريدة والمتسقة التسمية في جميع أنحاء Discourse

مثال: استهداف .btn أو button ببساطة:

.btn {
    border: 1px solid red;
}

يفوت أزرار المشاركات ولكنه يستهدف رابط “المشاهدات” وقائمة الهامبرغر.

[manuel (Manuel Kostka)]

@RGJ

حسنًا، أعتقد أن الطريقة الطبيعية لعمل CSS هي ببساطة تجاهل المتغيرات

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

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

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

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

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

[jordan.vidrine]

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

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

@manuel

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

هذا صحيح لبعض العناصر، ولكنه ليس صحيحًا لبعض العناصر الأخرى. أي أمثلة أخرى يمكنك مشاركتها ستكون رائعة!

@manuel

الحمل المعرفي وقابلية الاكتشاف

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

هذه بالتأكيد مشكلة. أحد الأساليب التي نفكر فيها (على الأقل تجريبيًا في الوقت الحالي) هو محرر يتماشى مع ما يفعله shadcn هنا:

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

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

@manuel

أشياء مثل .d-sidebar و .d-topic-list و .d-header.

ثم قم بإقران ذلك بمجموعة أصغر من المتغيرات الأساسية التي تتتالي بالطريقة التي من المفترض أن تعمل بها CSS:

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

---

@manuel

أحب فقط أن أرى نفس طاقة التحديث مطبقة على بنية CSS لأنني مقتنع بأن الفوائد طويلة الأجل لكل من تجربة المطور والمستخدم ستكون تحويلية.

أتفق معك

[awesomerobot (Kris)]

@RGJ

مثال: استهداف .btn أو button ببساطة:

الإجابة المختصرة هي لا تفعل ذلك

من الأفضل بكثير استهداف فئة زر ثانوية، btn-default، btn-primary، btn-flat — هذه الفئات الثانوية تمثل نوعًا مرئيًا من الأزرار.

.btn و button هما بشكل أعم “هذا زر” بدلاً من أي مظهر معين.

[awesomerobot (Kris)]

@manuel

هذا يبدو وكأنه حل “أسهل” يتجنب المشكلة الأصعب: المواءمة الكاملة لهندسة التصميم مع التصميم المعياري للإطار.

هذا هو بالضبط ما هو عليه. ليس لدينا حاليًا النطاق الترددي للشروع في إعادة كتابة شاملة لـ HTML و CSS الخاصة بنا جنبًا إلى جنب مع كل سمة نحافظ عليها، خاصة بالنظر إلى أننا لم ننتهِ بعد من رحلة تحديثات Ember التي تستغرق عدة سنوات.