اختيار لون من الشاشة في تطبيق ويب: عينة أم لون معتمد للعلامة؟
اجعل التقاط اللون من الشاشة وسيلة اختيارية لملء حقل اللون، لا الطريق الوحيد لإكمال طلب التصميم. اعرض القيمة المختارة وأتح تصحيحها، وافصل الاختيار عن الاعتماد. النقر على بكسل لا ينبغي أن يغيّر جميع صفحات العلامة أو يؤكد طلب إنتاج.
قد تسمح بوابة لطلبات التصاميم للعميل باختيار لون من صورة مرجعية. هذا مفيد للتعبير عن تفضيل أولي. أما إذا كان لديه رمز لون معتمد أو مواصفة جاهزة، فأتح إدخالها مباشرة بدلاً من إلزامه بأخذ عينة من الشاشة.
ما القيمة التي تجمعها؟
توضح وثائق EyeDropper من Chrome أن اختيار البكسل يعيد قيمة لون بنظام sRGB وبصيغة ست عشرية مثل #RRGGBB. بيّن هذا المعنى بجوار الحقل وفي السجل المحفوظ. تسمية الحقل «اللون» فقط لا تخبر الموظف التالي بنوع المرجع الذي وصله.
تصف الوثيقة قيمة بكسل من الشاشة، ولا تعد بأنها تطابق لوحة ألوان معتمدة أو مادة ملموسة أو نتيجة طباعة. لا تحوّل أداة مساعدة إلى هذا الوعد. إذا احتاج الإنتاج نظام ألوان آخر أو عينة مادية من المورد، فاتفق على تسليم تلك المرجعية مع المختص المسؤول بشكل مستقل.
في مثال افتراضي لطلب تصميم، يمكن حفظ القيمة بعنوان «لون مطلوب من الشاشة» إلى أن يعتمد المسؤول المواصفة. هذه توصية لتنظيم العمل، وليست وظيفة تتحقق بها الواجهة البرمجية من دليل العلامة أو من صلاحية الشخص للاعتماد.
وضع مؤقت يبدأ باختيار الشخص
تذكر الوثائق أن فتح أداة الالتقاط يحتاج إلى إجراء من المستخدم، مثل الضغط على زر. ثم يوضّح المتصفح أن وضع الاختيار نشط، ولا تعاد قيمة اللون إلا بعد اختيار بكسل. هذه ليست وسيلة لقراءة الشاشة سراً في الخلفية.
استخدم تسمية واضحة مثل «اختر لوناً من الشاشة»، واشرح أن مفتاح Escape يلغي العملية. توضح الوثيقة أن الخروج بهذه الطريقة ينهي طلب الاختيار دون نتيجة؛ لذلك اجعل الإلغاء مساراً عادياً لا رسالة خطأ عامة مخيفة.
توصيتنا أن تبقى القيمة السابقة كما هي عند الإلغاء. وبعد الاختيار الناجح يظهر الرمز ومعاينة اللون، لكن لا يحفظ الطلب إلا بإجراء الحفظ المتفق عليه. مربع المعاينة يرافق القيمة المكتوبة ولا يحل محلها.
حافظ على مسار يعمل دون الأداة
تطلب إرشادات Chrome التحقق من توافر الواجهة قبل استخدامها. نجاح عرض على حاسوب المطور لا يثبت دعم جميع هواتف العملاء أو متصفحاتهم. اطلب قائمة بالأجهزة والمتصفحات المستهدفة واختبارها فعلياً.
يجب أن يعمل الإدخال اليدوي للرمز، وأي لوحة ألوان متفق عليها، بصورة مستقلة عن أداة الالتقاط. من لا يستطيع استخدامها ينبغي أن يتمكن من إرسال الطلب. حدّد صيغة الرمز المقبولة والتحقق منها ورسائل التصحيح المفهومة. هذه متطلبات للتطبيق؛ فحص توافر الواجهة لا ينشئها تلقائياً.
تشرح الوثيقة أيضاً أن التطبيق يستطيع إيقاف وضع الاختيار عندما تتغير حالته بصورة جوهرية. حدّد ما يحدث إذا غادر العميل الطلب أو بدّل العنصر المستهدف أو فتح تفاعلاً مهماً آخر أثناء الالتقاط. لا تسمح بتطبيق نتيجة متأخرة على حقل لون يخص عنصراً مختلفاً.
اختبر وصول اللون إلى الطلب الصحيح
استخدم صورة اختبار غير حساسة وطلبات افتراضية، واطلب عرض الحالات التالية:
- لا تبدأ الأداة إلا بعد الإجراء الصريح المخصص لها.
- يظهر الرمز والمعاينة في الحقل المقصود.
- يحافظ Escape على القيمة السابقة دون حفظ تغيير.
- يمنع تبديل العنصر انتقال نتيجة قديمة إلى العنصر الجديد.
- يبقى الإدخال اليدوي والإرسال متاحين عند غياب الأداة.
- يعرض الطلب بعد حفظه وإعادة فتحه الرمز نفسه وحالته الأولية أو المعتمدة بوضوح.
- يظل اعتماد التصميم النهائي إجراءً مسجلاً مستقلاً.
تختبر هذه الحالات سير العمل المتفق عليه، ولا تمنح شهادة دقة ألوان أو إتاحة شاملة. دوّن نطاق الأجهزة والنتائج المتوقعة ضمن معايير قبول التطبيق.
أسئلة قبل التنفيذ
هل يستطيع العميل لصق رمز علامته الموجود؟ اطلب حقلاً يدوياً للصيغة المقبولة. واتفق على معالجة مرجع لوني من نوع آخر بدلاً من تحويله أو تغيير تسميته بصمت.
هل اختيار اللون من الشعار يعني اعتماده؟ لا. حدّد من يؤكد المواصفة النهائية وأي ملفات أصلية أو مراجع معتمدة يستند إليها القرار.
هل تحتاج كل بوابة طلبات هذه الميزة؟ ليس بالضرورة. إذا كانت لوحة ثابتة أو ملفات العميل تجيب عن الحاجة، فقد لا تضيف الأداة الكثير. ناقش مسار الطلب والاعتماد الحقيقي عند تحديد نطاق تطبيق الويب.
المصدر والحدود
تدعم وثيقة Chrome Developers فحص التوافر والاختيار بمبادرة المستخدم وإخراج sRGB الست عشري والإلغاء. أما معنى الحقل والإدخال البديل وحماية ارتباط النتيجة بالعنصر ومراحل الاعتماد فهي متطلبات مقترحة، وليست وظائف جرى تنفيذها أو اختبارها هنا.