لون OKLCH في CSS الحديث: لماذا يتفوق وكيف تشحنه

OKLCH هو أول فضاء لوني يشحنه CSS ويستطيع المصممون فعلاً التفكير فيه بمنطق. الفرق التي ما زالت تبني لوحاتها بالهكس تخسر بهدوء كل نقاش حول التباين والوضع الداكن، دون أن تعلم أصلاً أنها تخوضه.

الهكس لم يكن يوماً فضاءً لونياً، بل كان تسلسلاً نصياً

الهكس اختصار لـ sRGB. القيمة #4A90E2 ليست مواصفة لون، بل ثلاثية من قيم القنوات الحمراء والخضراء والزرقاء مضغوطة في ستة أحرف. صُمم sRGB لشاشات CRT في أوائل التسعينيات، لا لإدراك الإنسان البصري.

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

"الهكس لم يكن يوماً فضاءً لونياً، بل كان تسلسلاً نصياً، وما زلنا نتجادل حول السطوع منذ ذلك الحين."

HSL ادعى أنه أصلح المشكلة ولم يفعل

جاء HSL وأعطى المصممين لغة: تدرج لوني، وإشباع، وسطوع. بدا كأنه نظام. لكنه لم يكن. قناة السطوع في HSL ما زالت تُترجم إلى قيم sRGB في الخلفية، أي أنه يرث المشكلات الإدراكية نفسها التي يعاني منها الهكس.

اللونان hsl(220, 70%, 50%) وhsl(45, 70%, 50%) متساويان اسمياً في السطوع. افتحهما جنباً إلى جنب. الأصفر يبدو أفتح بوضوح. HSL أعطاك كلمات أفضل لنفس الرياضيات المعطوبة.

OKLCH متجانس إدراكياً

بُني OKLCH على فضاء OKLab الذي طوره Björn Ottosson عام 2020 تحديداً لمعالجة عدم التجانس الإدراكي في الفضاءات السابقة. حرف L في OKLCH يعني السطوع المُدرَك، معايَراً وفق استجابة النظام البصري البشري للضوء.

قيم L المتساوية في OKLCH تعني سطوعاً مُدرَكاً متساوياً. ليس تقريباً. وليس "غالباً إذا تشابهت الصبغة". متساوياً فعلاً. هذه الخاصية لم يقدمها أي فضاء لوني سابق في CSS، وهي تغير كل شيء في طريقة تفكيرك بتوليد اللوحات.

الأسباب الثلاثة التي تجعل OKLCH يفوز

سطوع متجانس إدراكياً، واستيفاء تدرج لوني متوقع، ودعم النطاق اللوني الواسع. كل واحد منها يصلح علة محددة في لوحتك الحالية، ومعاً يشكلون سير عمل لوني يتوسع عبر السمات والمكونات وأنواع الشاشات.

السبب الأول: انجراف السطوع مات

في أنظمة الهكس وHSL، انجراف السطوع ضريبة خفية تدفعها على كل لوحة. تضبط blue-50 وamber-50 على ما يبدو صحيحاً بالعين، ثم يتباعدان على شاشات مختلفة، ويتصارعان في الوضع الداكن، وحسابات التباين لا تثبت أبداً.

في OKLCH، يحمل blue-50 وamber-50 رقم السطوع نفسه، وهذا الرقم يمثل السطوع المُدرَك نفسه. نقلت Tailwind v4 لوحتها بالكامل إلى OKLCH لهذا السبب تحديداً. وإن كنت تستخدم مقاييس ألوان Radix UI، فأنت تستفيد أصلاً من التجانس الإدراكي حتى لو لم تر كلمة OKLCH في التوثيق.

السبب الثاني: استيفاء التدرج اللوني سليم

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

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

السبب الثالث: P3 وRec2020 في المتناول

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

يستطيع OKLCH وصف ألوان P3 وRec2020 بشكل أصلي. القيمة oklch(0.60 0.28 260) زرقاء نابضة موجودة في P3 وخارج نطاق sRGB. المتصفحات الحديثة تعرف كيف تتعامل معها، وإرشادات Apple للون Display P3 تشير إلى هذا الاتجاه منذ سنوات. نظام التصميم الذي ينتقل إلى OKLCH الآن هو أيضاً النظام الجاهز حين يصبح P3 التوقع الافتراضي.

الترحيل من الهكس إلى OKLCH في أربع خطوات

تدقيق، تحويل، إعادة توليد، إعادة تدقيق. الترحيل ميكانيكي بالنسبة لـالرموز الأولية ويتطلب حكماً بالنسبة لـالرموز الدلالية. ترحيل كامل لنظام تصميم متوسط الحجم يستغرق أياماً لا أسابيع. وتثبيت الرموز الجديدة في بنية متغيرات Figma نظيفة قبل أن تبدأ يوفر أكبر قدر من الوقت.

الخطوة الأولى: دقق اللوحة الحالية

صدّر كل رمز لوني في نظامك. حوّل كل قيمة هكس إلى OKLCH باستخدام أداة مثل oklch.com أو إضافة PostCSS OKLCH. رتب حسب قيمة L وانظر إلى عمود السطوع عبر التدرجات اللونية.

العلل تعلن عن نفسها فوراً. سيكون blue-300 عند L=0.72 بينما yellow-300 عند L=0.87. رموز يفترض أن تحمل الوزن البصري نفسه بعيدة عن ذلك تماماً. هذا التدقيق هو الدليل الذي يجعل قرار الترحيل سهل التبرير أمام أي معترض.

الخطوة الثانية: حوّل الأوليات إلى OKLCH

خذ المقياس الأولي، أي التدرج المرقم الخام وليس الرموز الدلالية، وحوّله إلى OKLCH. قرّب قيم السطوع إلى خطوات ثابتة عبر المحطات الإحدى عشرة كلها: 0.97 و0.93 و0.86 و0.75 و0.65 و0.54 و0.45 و0.37 و0.27 و0.19 و0.13.

لا تحاول الحفاظ على قيم الهكس الأصلية بدقة. الهدف هو إصلاح التناقض. blue-500 المحوّل وred-500 المحوّل لن يطابقا القيم القديمة بكسلاً ببكسل، وهذا هو الهدف بالضبط. النظام يتحسن، لا يتغير فحسب.

الخطوة الثالثة: أعد توليد التدرجات

مع خطوات سطوع نظيفة ومتسقة، تصبح إعادة توليد التدرجات عبر الألوان عملية جدولية. اضبط عمود L، واختر الصبغة لكل لون (الأزرق يحمل عادة صبغة أكثر من البني والأصفر قبل القص)، وعدّل عمود H، ثم ولّد.

النتيجة أن blue-500 وred-500 يبدوان بالوزن البصري نفسه للمرة الأولى في نظامك. قرارات لوحة ألوان العلامة التي كانت أحكاماً اعتباطية صارت خيارات مبدئية لها إحداثي تشير إليه.

الخطوة الرابعة: أعد تدقيق إمكانية الوصول

لوحة جديدة، فحص تباين جديد. يجعل OKLCH توقع التباين أسهل لأن السطوع صار يعني ما يقوله. اقتران رمزين بقيمتي L معروفتين يمنحك تقديراً قوياً لنسبة تباينهما قبل أن تفتح أداة الفحص.

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

---

تريد نظام ألوان يصمد عبر الأوضاع والتدرجات والشاشات الحديثة دون انجراف في السطوع؟ تصمم Brainy أنظمة لوحات أصلية بـ OKLCH تُشحن على شكل متغيرات Figma وخصائص CSS مخصصة ورموز Tailwind، مع فحص التباين منجز مسبقاً.

---

المزالق الأربعة في OKLCH

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

مشكلة النطاق هي الأشد لدغاً. حين تكتب oklch(0.60 0.32 260) فإن قيمة الصبغة هذه خارج sRGB. متصفحات سطح المكتب تتعامل مع ذلك بالقص إلى أقرب لون في sRGB، ما قد يزيح التدرج اللوني الظاهر. الحل إما البقاء ضمن صبغة آمنة لـ sRGB للرموز الأساسية، أو حصر قيم النطاق الواسع خلف media query مع إبقاء تصريح احتياطي فوقها.

تدرج لوحة OKLCH العملي

تدرج عملي من 11 خطوة بخطوات سطوع ثابتة، يستخدم الأزرق عند التدرج اللوني 260 كمرجع. خطوات السطوع متطابقة عبر كل تدرج لوني في نظامك. فقط الصبغة والتدرج اللوني يتغيران لكل عائلة لونية.

:root { --blue-50: oklch(0.97 0.02 260); --blue-100: oklch(0.93 0.05 260); --blue-200: oklch(0.86 0.09 260); --blue-300: oklch(0.75 0.14 260); --blue-400: oklch(0.65 0.18 260); --blue-500: oklch(0.54 0.22 260); --blue-600: oklch(0.45 0.20 260); --blue-700: oklch(0.37 0.17 260); --blue-800: oklch(0.27 0.13 260); --blue-900: oklch(0.19 0.09 260); --blue-950: oklch(0.13 0.06 260); }

لتوليد الأحمر (تدرج 25) أو العنبري (تدرج 75) أو الأخضر (تدرج 145)، أبقِ عمود L متطابقاً عبر المحطات الإحدى عشرة كلها. اضبط C بحسب سعة الصبغة الطبيعية للتدرج: الأصفر والأخضر يحملان صبغة أقل من الأزرق قبل أن يخرجا من نطاق sRGB. اضبط H على التدرج المستهدف. هذا هو نظام اللوحة بأكمله.

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

دعم المتصفحات ونافذة الترحيل الآمنة

OKLCH مدعوم في كل متصفح رئيسي صدر منذ 2023. Chrome 111 وSafari 15.4 وFirefox 113 وEdge 111 كلها تشحن دعماً كاملاً لـ OKLCH. التغطية العالمية فوق 93% حتى منتصف 2025. نافذة الترحيل مفتوحة.

الحل الاحتياطي لأي متصفح لا يدعم OKLCH سطر واحد. صرّح بقيمة الهكس الاحتياطية أولاً، ثم قيمة OKLCH. المتصفحات التي لا تفهم OKLCH تتجاهله وتستخدم الهكس. والتي تفهمه تستخدم القيمة الأفضل.

color: #4a7de8; /* sRGB fallback */ color: oklch(0.54 0.22 260); /* OKLCH for modern browsers */

تولّد Tailwind v4 لوحتها بـ OKLCH بشكل أصلي. وقد اتجهت Linear ورموز التصميم في Sail من Stripe وإرشادات Apple للألوان للمطورين نحو أنظمة متجانسة إدراكياً. الصناعة حسمت أمرها. السؤال هو متى ينضم فريقك.

الأسئلة الشائعة

هل OKLCH صعب التعلم؟

نظام الإحداثيات مختلف عن الهكس وHSL لكنه ليس معقداً. L هو السطوع من 0 إلى 1. C هي الصبغة، أي درجة الإشباع تقريباً. H هو التدرج اللوني بالدرجات. حين تستوعب أن L تعني السطوع المُدرَك وC تعني الحيوية اللونية، يصبح النظام بديهياً أسرع مما كان HSL.

هل أستطيع استخدام OKLCH في Figma اليوم؟

لا يعرض Figma لون OKLCH بشكل أصلي في منتقي الألوان حتى 2025. سير العمل العملي هو تعريف الرموز بـ OKLCH في ملف رموز عبر Tokens Studio أو ملف متغيرات CSS متزامن مع متغيرات Figma، ثم استخدام تصدير الكود في Figma للتحقق من القيم. محرك العرض في Figma يتولى التحويل داخلياً.

هل يكسر OKLCH قيم الهكس الحالية عندي؟

لا. يمكنك إدخال OKLCH تدريجياً، رمزاً برمز. قيم الهكس الحالية تستمر في العمل تماماً كما كانت. الترحيل إضافي، وليس استبدالاً.

ما الفرق بين LCH وOKLCH؟

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

كيف أحول الهكس إلى OKLCH؟

استخدم oklch.com أو إضافة PostCSS oklch أو ملعب مواصفة CSS Color 4. الصق قيمة الهكس، واقرأ إحداثيات OKLCH، وقرّب L وC إلى منزلتين عشريتين، وقرّب H إلى أقرب درجة صحيحة. هذه هي قيمة رمزك العملية.

هل يؤثر OKLCH على متطلبات إمكانية الوصول؟

متطلبات تباين WCAG معرّفة بناءً على اللمعان النسبي في sRGB، لا سطوع OKLCH. أما APCA فهو أقرب إلى النماذج الإدراكية ويتوافق بشكل أطبع مع قيم L في OKLCH. عملياً، يجعل OKLCH توقع التباين أكثر بداهة لأن L يتتبع السطوع المُدرَك، لكنك ما زلت بحاجة إلى تمرير أزواج الرموز الدلالية عبر أداة فحص التباين. العملية نفسها، لكن التفكير فيها مسبقاً أسهل.

التحول الذي يفتحه OKLCH فعلاً

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

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

إن أردت بناء بنية الرموز الكاملة فوق هذه اللوحة، فورقة بنية متغيرات Figma تغطي الطبقة الدلالية. أما لتطبيق هذا العمل على الوضع الداكن، فإن أنظمة ألوان الوضع الداكن تكمل من حيث تنتهي هذه.

تريده مبنياً لك؟ وظّف Brainy.