LayoutNG

من المقرر إطلاق LayoutNG في Chrome 76، وهو محرك تصميم جديد يتخلّله جهود متعددة لسنوات متعددة. هناك العديد من التحسينات الفورية والمثيرة، والمكاسب الإضافية في الأداء وميزات التخطيط المتقدمة القادمة.

الميزات الجديدة

  1. يؤدّي ذلك إلى تحسين عزل الأداء.
  2. دعم أفضل للنصوص البرمجية بخلاف اللاتينية.
  3. إصلاح العديد من المشاكل حول الأعداد العشرية والهوامش.
  4. إصلاح عدد كبير من مشاكل التوافق مع الويب.

يُرجى العِلم أنّه سيتم إطلاق تنسيق LayoutNG على مراحل. في الإصدار 76 من Chrome، يتم استخدام LayoutNG للتنسيق المضمّن والكتلة. وسيتم استبدال عناصر التصميم الأساسية الأخرى (مثل تجزئة الجدول والإطار المرن والشبكة والكتل) في الإصدارات اللاحقة.

التغييرات المرئية للمطوِّر

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

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

عائمة

يُعيد LayoutNG تنفيذ العناصر العائمة (float: left; وfloat: right;) لحل عدد من المشاكل المتعلقة بصحة البيانات بشأن وضع الأعداد العشرية مقارنةً بالمحتوى الآخر.

محتوى متراكب

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

يتم عرض صورة عائمة على سطح الصفحة في سطر النص العلوي
الشكل 1أ، محرك التصميم القديم
يتداخل النص مع الصورة العائمة على اليمين
النص الصحيح على اليسار والصورة العائمة على اليمين
الشكل 1ب، LayoutNG
يتم وضع النص بجانب الصورة العائمة على اليسار.

قد تحدث المشكلة نفسها في سطر واحد. يوضح المثال أدناه عنصر حظر بها هامش سالب بعد عنصر عائم (#895962). يجب ألا يتداخل النص مع عدد عشري.

سطر نص معروض فوق مربّع برتقالي
الشكل 2أ، محرّك التصميم القديم
يتداخل النص مع العنصر البرتقالي العائم
النص الصحيح على يمين المربع البرتقالي
الشكل 2ب، LayoutNG
يتم وضع النص بجانب العنصر البرتقالي العائم.

تنسيق تحديد موضع سياق

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

أصبح الموضع المطلق والثابت أكثر توافقًا مع مواصفات W3C ويتوافقان بشكل أفضل مع السلوك في المتصفحات الأخرى. تظهر الاختلافات بين الاثنين بشكل أكثر وضوحًا في حالتين:

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

اللغات التي تُكتب من اليمين إلى اليسار وأوضاع الكتابة العمودية

تم تصميم LayoutNG من الألف إلى الياء لدعم أوضاع الكتابة العمودية ولغات RTL، بما في ذلك المحتوى ثنائي الاتجاه.

نص ثنائي الاتجاه

يتيح LayoutNG استخدام أحدث خوارزمية ثنائية الاتجاه المحدّدة في معيار Unicode. لا يؤدي هذا التحديث فقط إلى إصلاح أخطاء العرض المختلفة، ولكنه يتضمّن أيضًا ميزات غير متوفّرة، مثل دعم الأقواس المزدوجة (يُرجى الاطّلاع على خطأ Chromium رقم 302469.)

تدفقات متعامدة

يحسّن LayoutNG دقة تخطيط التدفق الرأسي، بما في ذلك، على سبيل المثال، موضع الكائنات في الوضعية الكاملة وحجم مربعات التدفق المتعامدة (خاصةً عند استخدام النسبة المئوية). من بين 1,258 اختبارًا في مجموعات اختبار W3C، نجح 103 اختبار في اجتياز 103 اختبار لم يكتمل اختبار المحرك القديم في LayoutNG.

المقاس الأساسي

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

تنسيق النص وفواصل الأسطر

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

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

الانضمام عبر حدود العناصر

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

في LayoutNG، يمكن الانضمام الآن حتى إذا كانت الأحرف في عناصر مختلفة. سيتم حفظ عمليات الربط أيضًا عند تطبيق نمط مختلف. (راجِع الخطأ رقم 6122 في Chromium.)

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

تُظهر الصور أدناه عرض HTML التالي في محرك التخطيط القديم وLayoutNG، على التوالي:

<div>&#1606;&#1587;&#1602;</div>
<div>&#1606;&#1587;<span>&#1602;</span></div>
الرسم البياني الصحيح على اليسار والعرض غير صحيح على اليمين مفصولاً
الشكل 3a، محرك التصميم القديم
ملاحظة كيف يتغير شكل الحرف الثاني
يتم عرض الرسومات البيانية المجمّعة المناسبة.
الشكل 3ب، LayoutNG
اصبحا النسختين متطابقتين

الأحرف المرتبطة الصينية واليابانية والكورية (CJK)

على الرغم من أنّ Chromium يتوافق بالفعل مع الأحرف المُرفقة ويفعِّلها تلقائيًا، هناك بعض القيود: لا يمكن استخدام الأحرف المدمجة التي تتضمّن رموز CJK متعددة في محرك التصميم القديم بسبب تحسين العرض. يزيل LayoutNG هذه القيود ويتوافق مع الأحرف المرتبطة بغض النظر عن النص البرمجي.

يوضح المثال أدناه عرض ثلاثة أحرف ثلاثية تقديرية باستخدام الخط Adobe SourceHanSansJP:

مجموعة الأحرف الوسطى لا تشكل رباطًا
الشكل 4a، محرّك التنسيق القديم
ميغاهرتز تنشئ حروفًا ربطًا بشكل صحيح
ولكن لا ينطبق ذلك على كل من マョン و10点
يتم عرض الحروف المركبة الصحيحة
الشكل 4b، LayoutNG
تشكل كل المجموعات الثلاث حروفًا ثلاثية كما هو متوقّع.

عناصر الحجم إلى المحتوى

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

يوضّح المثال أدناه قطعة صفراء بحجم المحتوى. حيث يستخدم خط Lato الذي يستخدم المسافة بين T و-. يجب أن تتطابق حدود المربع الأصفر مع حدود النص.

مسافة بيضاء لاحقة تظهر في نهاية حاوية النص
الشكل 5a، محرّك التنسيق القديم
ملاحظة المسافة البيضاء اللاحقة بعد آخر T
لا تحتوي حدود النص على مسافة إضافية
الشكل 5b، LayoutNG
ملاحظة كيف تتطابق الحواف اليسرى واليمنى للمربع مع حدود النص

التفاف السطر

على غرار المشكلة الموضّحة أعلاه، إذا كان محتوى كتلة المحتوى على شكل محتوى أكبر (عرضًا) من حجم الكتلة، يمكن أحيانًا أن يلتف المحتوى بدون داعٍ. هذه الحالة نادرة جدًا ولكنها تحدث أحيانًا لمحتوى مختلط الاتجاه.

يتم عرض فاصل سطر سابق لأوانه يتسبب في زيادة المسافة
الشكل 6a، محرّك التصميم القديم
ملاحظة فاصل الأسطر غير الضروري والمسافة الإضافية على اليسار
عدم إظهار مسافة أو فواصل أسطر غير ضرورية
الشكل 6b، LayoutNG
ملاحظة كيف تتطابق الحواف اليسرى واليمنى للمربع مع حدود النص

معلومات إضافية

للاطّلاع على معلومات أكثر تفصيلاً حول مشاكل التوافق والأخطاء التي تم إصلاحها من خلال LayoutNG، يُرجى الاطّلاع على المشاكل المرتبطة أعلاه أو البحث في قاعدة بيانات أخطاء Chromium عن الأخطاء التي تم وضع علامة Fix-In-LayoutNG (في إطارها مثبّت) على الأخطاء.

إذا كنت تشك في أن LayoutNG قد تسبب في تعطل أحد المواقع الإلكترونية، يُرجى تقديم تقرير خطأ، وسنتحقق من ذلك.