تعديلات جزئية تعريفية

Barry Pollard

Noam Rosenthal

تاريخ النشر: 19 مايو 2026، تاريخ آخر تعديل: 8 سبتمبر 2026

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

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

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

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

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

البث خارج الترتيب

تتضمّن المجموعة الأولى من التغييرات واجهات برمجة تطبيقات جديدة لبث المحتوى بترتيب غير متسلسل باستخدام عناصر نائبة لتعليمات المعالجة وعنصر HTML‏ <template> مع السمة for. على سبيل المثال:

<div>
  <?marker name="placeholder">
</div>

...

<template for="placeholder">
  Here is some <em>HTML content</em>!
</template>

تتوفّر تعليمات المعالجة في XML منذ فترة طويلة، ولكن تم التعامل معها كتعليقات في HTML وتم تجاهلها. تغيّر واجهة برمجة التطبيقات الجديدة هذه الوضع وتضيف تعليمات المعالجة إلى HTML. على سبيل المثال، عندما يرى المتصفّح تعليمات المعالجة <?marker name="placeholder">، لا يتّخذ أي إجراء على الفور، كما كان يحدث من قبل، ولكن يمكن الرجوع إليها لاحقًا.

يبحث <template> العنصر الذي يتضمّن السمة for عن تعليمات المعالجة المقابلة التي تتضمّن السمة name ويستبدل المحتوى. في هذه الحالة، بعد التحليل، يصبح DOM على النحو التالي (مع تجاهل بعض الاختلافات في المسافات البيضاء):

<div>
  Here is some <em>HTML content</em>!
</div>

بالإضافة إلى السمة <?marker> الخاصة بعمليات الاستبدال، هناك أيضًا علامتان لتحديد النطاق، وهما <?start> و<?end>، تسمحان بعرض محتوى العنصر النائب المؤقت قبل معالجة النموذج:

<div>
  <?start name="another-placeholder">
  Loading…
  <?end>
</div>

...

<template for="another-placeholder">
  Here is some <em>HTML content</em>!
</template>

في هذه الحالة، يتم عرض السلسلة Loading… إلى أن يظهر <template>، ثم يتم استبدالها بالمحتوى الجديد.

من الممكن أيضًا تضمين تعليمات المعالجة في النماذج للسماح بتعديلات متعددة:

<ul id="results">
  <?start name="results">
  Loading…
  <?end>
</ul>

...

<template for="results">
  <li>Result One</li>
  <?marker name="results">
</template>

...

<template for="results">
  <li>Result Two</li>
  <?marker name="results">
</template>

...

سينتج عن ذلك رمز HTML التالي بعد تحليله ومعالجته:

<ul id="results">
  <li>Result One</li>
  <li>Result Two</li>
  <?marker name="results">
</ul>

مع تعليمات المعالجة النهائية في النهاية، في حال تمت إضافة المزيد من العناصر النائبة <template for="results"> إلى المستند لاحقًا

لماذا تعليمات المعالجة بدلاً من عناصر HTML العادية؟

هذا سؤال شائع لدى المستخدمين الذين يستخدمون واجهة برمجة التطبيقات هذه للمرة الأولى، مع اقتراحات باستخدام العنصر <slot> أو حتى العنصر <template>. كانت النسخة الأولية من هذا الاقتراح تعمل مع عناصر HTML العادية، ولكن تمّت إضافة تعليمات المعالجة أثناء تكرار التصميم. تسمح تعليمات المعالجة بتطبيق التصحيحات بدون التأثير في نموذج DOM. يتيح ذلك استخدامها في <head>، مثلاً لتحديث <title>، أو حتى داخل عناصر أخرى مثل <table> (لإضافة صفوف إضافية اختيارية، مثلاً).

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

عرض توضيحي

في هذا الفيديو، يتم تنفيذ تطبيق أساسي لألبوم صور باستخدام HTML المتدفّق:

يتم بث كلّ من الحالة والصور إلى HTML بعد التنسيق الأولي.

حالات الاستخدام

هناك العديد من حالات استخدام HTML التي يتم تصحيحها خارج الترتيب عند إقرانها ببث HTML:

• بنية الجزيرة نمط شائع رائج في أُطر عمل مثل Astro وهو بنية الجزر حيث يتم ترطيب المكوّنات بشكل مستقل فوق HTML ثابت. تتيح واجهة برمجة التطبيقات <template for> إمكانية التعامل مع المحتوى الثابت بطريقة مشابهة مباشرةً في HTML. يمكن أن تستخدم أُطر عمل JavaScript هذه الميزة أيضًا لإنشاء أقسام أكثر تفاعلية أو للتعامل مع المكوّنات.
• تسليم المحتوى عندما يكون جاهزًا بفضل بنية الجزر هذه، يمكن بث المحتوى عندما يكون جاهزًا، بدلاً من تأخيره بسبب المحتوى الذي يتطلّب معالجة إضافية، مثل البحث في قاعدة البيانات. في حين أنّ العديد من المنصات تسمح ببث HTML، إلا أنّ طبيعة HTML المتسلسلة تعني أنّه غالبًا ما يتم حجب المحتوى أو اللجوء إلى عمليات معقدة في JavaScript DOM. يمكنك الآن عرض المحتوى الثابت أثناء الانتظار، ثم إضافة المحتوى الأكثر تكلفةً والديناميكي في نهاية بث HTML.
• يمكن عرض HTML بالترتيب الأمثل لتحسين أداء تحميل الصفحة. يمكنك أيضًا تغيير الترتيب حتى عندما يكون جاهزًا. على سبيل المثال، القوائم الضخمة هي ميزة شائعة للتنقّل تتضمّن الكثير من HTML الذي لن يراه المستخدم إلى أن تصبح الصفحة تفاعلية. يمكن تسليم هذه المجموعة الكبيرة من HTML لاحقًا في مستند HTML لتحديد أولوية HTML الأكثر أهمية واللازم لتحميل الصفحة الأوّلي. لم يعُد الترتيب عائقًا عند استخدام HTML.

هذه مجرد بعض حالات الاستخدام، ونتطلّع إلى معرفة ما سيستخدمه المطوّرون في واجهة برمجة التطبيقات الجديدة هذه.

القيود والجوانب الدقيقة

تتضمّن واجهة برمجة التطبيقات بعض القيود والتفاصيل الدقيقة التي يجب الانتباه إليها:

• لا يمكن <template for> تعديل تعليمات المعالجة إلا ضمن العنصر الرئيسي نفسه لأسباب أمنية. تؤدي إضافة <template for> مباشرةً إلى العنصر <body> إلى منحه إذن الوصول إلى المستند بأكمله (بما في ذلك <head>).
• إنّ تعليمات المعالجة <?end> اختيارية، وفي حال عدم توفّرها، سيتم استبدال المحتوى بين العنصر <?start> ونهاية العنصر الحاوي.
• يمكن أن يؤدي نقل تعليمات المعالجة بعد بدء بث <template for> إلى عواقب غير متوقّعة أيضًا، حيث يستمر بث المحتوى الجديد إلى الموقع القديم.
• يُرجى العِلم أنّه عند إدراج <template for> بشكل ديناميكي باستخدام طريقة مثل setHTML أو السمة innerHTML، يكون "العنصر الرئيسي" للنموذج عند تحليله عبارة عن جزء مستند وسيط. وهذا يعني أنّ إدراج HTML باستخدام هذه الطرق لا يمكنه تعديل DOM الحالي، ويحدث التصحيح "في المكان" داخل الجزء. ومع ذلك، عند البث باستخدام طرق مثل streamHTMLUnsafe (سيتم تناولها قريبًا)، لا توجد أجزاء وسيطة، لذا يمكن للنماذج استبدال المحتوى الحالي.

حالة توحيد المقاييس

السمة <template for> هي جزء من معيار HTML ولكنّها غير متاحة بعد في جميع المتصفحات.

الإضافات المحتملة في المستقبل

تشمل بعض الإضافات المحتملة المستقبلية التي يتم النظر فيها ما يلي:

• عمليات تضمين من جهة العميل: على سبيل المثال، <template for="footer" src="/partials/footer.html">، أو حتى بدون تصحيح <template src="/partials/footer.html">. لمزيد من التفاصيل، يُرجى الاطّلاع على الشرح. تتوفّر هذه الميزة خلف علامة chrome://flags/#enable-experimental-web-platform-features.
• منع الكتابة فوق المحتوى الذي لن يتغير: ويمكن تحقيق ذلك باستخدام رقم مراجعة المحتوى أو نظام تحديد الإصدارات. سيسمح ذلك بالحفاظ على الحالة بين تغييرات المسار أو التحديثات الأخرى بدلاً من إعادة ضبط المحتوى.
• التحقّق من الأمان أثناء التحديث على سبيل المثال، <template for=icon safe><svg id="from-untrusted-source">...</svg></template>

Polyfill

لقد أصدر فريق Chrome template-for-polyfill متاحًا على npm للسماح للمواقع الإلكترونية باستخدام هذه الوظيفة الجديدة على الفور حتى قبل أن تصبح متاحة في المتصفّحات الأخرى.

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

طرق جديدة لإدراج HTML وبث المحتوى

لا يمكن تسليم كل المحتوى بتنسيق HTML. يهدف الجزء الثاني من العمل الذي أجراه Chrome في هذا المجال إلى تسهيل تعديل المحتوى باستخدام JavaScript.

تتوفّر حاليًا عدة طرق لإدخال رمز HTML بشكل ديناميكي في مستند حالي باستخدام JavaScript:

• setHTML
• setHTMLUnsafe
• innerHTML وouterHTML
• createContextualFragment
• insertAdjacentHTML

ومع ذلك، تعمل جميعها بطرق مختلفة قليلاً مع بعض الفروق الدقيقة التي قد لا يضعها المطوّرون في اعتبارهم دائمًا:

• هل سيتم استبدال المحتوى الحالي بالمحتوى الجديد أو إضافته إليه؟
• هل يتم تنظيف تنسيق HTML الذي قد يكون خطيرًا، مثلاً عن طريق إلغاء تسلسل العلامات <script>؟
• إذا لم يكن كذلك، هل يجب تشغيل <script>؟
• كيف تعمل مع Trusted Types؟

لم يتمكّن سوى عدد قليل من المطوّرين من إلقاء نظرة على واجهات برمجة التطبيقات هذه والإجابة عن هذه الأسئلة بثقة لكل منها.

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

مجموعة جديدة من واجهات برمجة التطبيقات الثابتة والمتدفّقة

عمل Chrome على مجموعة من واجهات برمجة التطبيقات والإضافات الجديدة إلى setHTML وsetHTMLUnsafe الحالية التي تعمل على حلّ هذه المشكلة، بالإضافة إلى توفير وظيفة البث.

ستكون هذه الميزات جاهزة لاختبار المطوّرين بدءًا من الإصدار 148 من Chrome باستخدام العلامة chrome://flags/#enable-experimental-web-platform-features، ومن المقرّر إطلاقها في الإصدار 155 من Chrome.

تتوفّر طرق لضبط المحتوى أو استبداله، بالإضافة إلى طرق لإدراج المحتوى قبل رمز HTML الحالي أو بعده. لكل طريقة مكافئات في مجموعة البث:

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

تتلقّى الإصدارات الثابتة رمز HTML جديدًا كمعلَمة سلسلة DOM، بالإضافة إلى خيارات اختيارية:

const newHTML = "<p>This is a new paragraph</p>";
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTML(newHTML);

تعمل إصدارات البث مع Streams API، مثل getWriter():

const contentElement = document.querySelector('#content-to-update');
const writer = contentElement.streamHTMLUnsafe().getWriter();

// Example stream of updating content
while (true) {
  await writer.write(`<p>${++i}</p>`);
  await new Promise((resolve) => setTimeout(resolve, 1000));
}

writer.close();

أو بدلاً من ذلك، من ردّ على عملية جلب باستخدام سلاسل الأنابيب:

const contentElement = document.querySelector('#content-to-update');
const response = await fetch('/api/content.html');

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(contentElement.streamHTMLUnsafe());

طريقة textStream() المريحة

تمت أيضًا إضافة textStream طريقة ملائمة، حيث يمكنك البث مباشرةً بدون الحاجة إلى الخطوة الوسيطة TextDecoderStream():

const contentElement = document.querySelector('#content-to-update');
const response = await fetch('/api/content.html');

response.textStream().pipeTo(contentElement.streamHTMLUnsafe());

options

تتيح لك الوسيطة options تحديد sanitizer مخصّص يكون تلقائيًا default، ما يعني إعدادات أداة التنظيف التلقائية. يتم استخدامها على النحو التالي:

const newHTML = '<p>This is a new paragraph</p>';
const contentElement = document.querySelector('#content-to-update');

// Only allows basic formatting
const basicFormattingSanitzer = new Sanitizer({ elements: ['em', 'i', 'b', 'strong'] });

contentElement.setHTML(newHTML, {sanitizer: basicFormattingSanitzer});

الطرق "غير الآمنة"

تتوفّر أيضًا إصدارات "غير آمنة" من كل واجهة من واجهات برمجة التطبيقات:

تؤدي هذه الطرق "غير الآمنة" إلى إيقاف أداة التنظيف تلقائيًا، ويمكنك تحديد أداة تنظيف مخصّصة إذا أردت ذلك. تسمح هذه الطرق أيضًا بتشغيل النصوص البرمجية باستخدام الخيار الاختياري runScripts، والذي يكون false تلقائيًا.

على غرار setHTML، فإنّ setHTMLUnsafe هي طريقة حالية، ولكن تمت إضافة مَعلمة الخيارات runScripts إليها للسماح باستخدامها مع تنفيذ النص البرمجي:

const newHTML = `<p>This is a new paragraph</p>
                 <script src=script.js></script>`;
const contentElement = document.querySelector('#content-to-update');

contentElement.setHTMLUnsafe(newHTML, {runScripts: true});

إنّ عبارة "غير آمن" في الطريقة تهدف إلى تذكير المطوّرين بالمخاطر المحتملة وكيفية تنظيف النصوص البرمجية أو تقييدها، وليس إلى القول بأنّه لا يجب استخدام هذه الطرق.

ويعتمد مدى "عدم الأمان" على مدى موثوقية البيانات التي يتم إدخالها. تعمل جميع الطرق الثابتة Unsafe مع كل من DOM String أو TrustedHTML كمعلمات html، كما تسمح باستخدام أدوات التعقيم. مع ذلك، فإنّ الغرض من runScript هو السماح بتنفيذ النصوص البرمجية، ولهذا السبب لا يتم استخدام أي أداة تنظيف تلقائيًا.

حالات الاستخدام

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

تشمل حالات الاستخدام ما يلي:

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

مرة أخرى، هذه مجرد أمثلة قليلة، ونحن متحمّسون لرؤية ما ستبتكرونه.

القيود والجوانب الدقيقة

تتضمّن واجهات برمجة التطبيقات الجديدة أيضًا بعض القيود والتفاصيل الدقيقة التي يجب الانتباه إليها:

• يتطلّب دمج البث مع Trusted Types API استخدام طريقة createParserOptions جديدة تتيح إدخال أداة تنظيف إلى أي عملية إعداد HTML. شاهد الفيديو التوضيحي لمزيد من التفاصيل حول دمج أنواع Trusted Types
• على غرار <template for>، يمكن أن يؤدي نقل العناصر التي يتم بثها إلى حدوث عواقب غير متوقعة أو أخطاء في البث.
• تعمل streamHTMLUnsafe بشكل مشابه للمحلّل الرئيسي من نواحٍ عديدة، بما في ذلك معالجة تعليمات <template for> عند إضافتها إلى المستند الرئيسي وتأجيل نصوص defer البرمجية إلى نهاية البث.

حالة توحيد المقاييس

يتم حاليًا العمل على إضافة طريقتَي الإدراج والبث الأحدث إلى معيار HTML، ولكنّهما غير متوافقتَين بعد مع جميع المتصفحات.

Polyfill

لقد أصدر فريق Chrome html-setters-polyfill متاحًا على npm للسماح للمواقع الإلكترونية باستخدام هذه الوظيفة الجديدة على الفور حتى قبل أن تصبح متاحة في المتصفّحات الأخرى.

يُرجى العِلم أنّ هذا الرمز المتوافق لا يتيح البث، بل يخزّن المحتوى مؤقتًا ويطبّقه عند اكتماله. وهي أقرب إلى polyfill لشكل واجهة برمجة التطبيقات من وظائفها.

بالإضافة إلى ذلك، يعتمد ضبط المحتوى الآمن على setHTML وSanitizer API غير المتوافق مع Safari.

استخدام كليهما معًا

على الرغم من أنّ هاتين واجهتَي برمجة تطبيقات منفصلتَين، فإنّ القوة الحقيقية تكمن في دمجهما. من خلال بث عناصر <template for> جديدة إلى HTML، يمكنك تعديل أجزاء مختلفة من المحتوى بشكل ديناميكي بدون الحاجة إلى استهداف كل جزء بشكل مباشر باستخدام مراجع JavaScript منفصلة إلى DOM.

يمكن تنفيذ تحميل صفحة أساسي بأسلوب SPA من خلال تحميل صفحة مخطط تتضمّن تعليمات معالجة، ثم بث نماذج كل صفحة جديدة إلى أسفل HTML لتضمينها في تعليمات المعالجة هذه.

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

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