انتقالات العرض عبر المستندات: لماذا «دعم كل المتصفحات» ليس دقيقاً؟

لسنوات كان الفرق البصري بين تطبيق أصلي وموقع ويب يُختصر في لحظة واحدة: الانتقال بين الشاشات. التطبيق ينزلق بنعومة، والموقع يومض ثم يرسم صفحة جديدة من الصفر. هذا بالضبط ما جاءت واجهة انتقالات العرض (View Transitions API) لتحلّه، وفي 2026 صارت النسخة الأهم منها — انتقالات عبر المستندات، أي بين صفحتين مختلفتين فعلاً وليس داخل تطبيق صفحة واحدة — متاحة في متصفّحين من ثلاثة.

وهنا تحديداً تبدأ المشكلة. الجملة المنتشرة هذا العام هي «انتقالات العرض صارت متاحة في كل المتصفحات»، وهي جملة صحيحة ومضلّلة في الوقت نفسه، لأنها تخلط بين نسختين مختلفتين تماماً من الميزة.

نسختان، لا واحدة

الواجهة لها مسارا استخدام منفصلان، ولكل واحد جدول دعم مختلف:

• داخل المستند نفسه (same-document): انتقال بين حالتين في تطبيق صفحة واحدة، تستدعيه بجافاسكربت عبر document.startViewTransition(). هذا هو المسار الناضج.
• عبر المستندات (cross-document): انتقال بين صفحتين حقيقيتين أثناء تصفّح عادي، بلا أي جافاسكربت — سطران في CSS عبر قاعدة @view-transition. وهذا هو المسار الذي يهمّ المواقع التقليدية ومتعدّدة الصفحات، وهو الذي ما زال ناقصاً.

الخلط بينهما هو سبب معظم التدوينات المتناقضة هذا العام. من يتحدّث عن «دعم كامل» يقصد غالباً المسار الأول.

جدول الدعم كما هو فعلاً في 2026

القدرة	كروم	سفاري	فايرفوكس
انتقال داخل المستند (SPA)	111+	18+	144+
انتقال داخل المستند مع الأنواع (types)	125+	18.2+	147+
انتقال عبر المستندات (MPA)	126+	18.2+	قيد التنفيذ
المحدّد :active-view-transition	125+	18.2+	147+

الخلاصة من الجدول: فايرفوكس أغلق فجوة الـSPA بالكامل خلال 2026، لكنه لم يشحن انتقالات عبر المستندات في أي إصدار مستقر حتى الآن. والحالة المعلنة هي «قيد التنفيذ» لا «مشحون».

لماذا هذا النقص أقل خطورة مما تتخيّل

المفاجأة السارة أن هذه واحدة من أنظف حالات التدهور التدريجي في تاريخ منصّة الويب.

قاعدة @view-transition هي اشتراك اختياري مكتوب في CSS. المتصفّح الذي لا يفهمها يتجاهلها تماماً — لا خطأ في الطرفية، لا تعطّل، لا شاشة بيضاء. يتصفّح المستخدم بالطريقة القديمة: الصفحة القديمة تختفي والجديدة تظهر، تماماً كما كان الويب يعمل منذ ثلاثين سنة. لا شيء ينكسر.

الميزة التي تضيف متعة عند توفّرها ولا تكلّف شيئاً عند غيابها ليست مخاطرة تقنية — هي قرار منتج فقط.

وهذا يقلب طريقة اتخاذ القرار رأساً على عقب. السؤال ليس «هل أنتظر حتى يشحن فايرفوكس؟» بل «هل أقبل أن جزءاً من زوّاري يرى المسار العادي بلا رسوم؟». إن كانت الإجابة نعم — وهي نعم في الغالبية الساحقة من المواقع — فابدأ اليوم.

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

المطبّات التي لا يذكرها أحد

بعيداً عن جدول التوافق، هناك تفاصيل تكتشفها فقط بعد التطبيق:

• الأصل نفسه إجباري. الانتقال عبر المستندات يعمل بين صفحتين على الأصل ذاته (same-origin). الخروج إلى نطاق آخر يلغي الانتقال بصمت.
• view-transition-name لا بد أن يكون فريداً في اللحظة الواحدة. عنصران يحملان الاسم نفسه على الشاشة يُلغيان الانتقال كلّه، لا العنصر المكرّر وحده. مع قائمة مولّدة من بيانات، هذا خطأ سهل جداً.
• الميزة تصوّر لقطة، لا تحرّك عنصراً. ما يُحرَّك هو صورة للقديم وصورة للجديد. اختلاف نسبة الأبعاد بينهما ينتج تمطّطاً مرئياً يحتاج ضبطاً بـobject-fit.
• السرعة قبل الجمال. الانتقال يبدأ بعد أن يصبح المستند الجديد جاهزاً للعرض. صفحة بطيئة لن تُنقَذ برسوم جميلة، بل ستبدو أبطأ لأن المستخدم ينتظر ثم يرى حركة.
• احترام prefers-reduced-motion ليس اختيارياً. من يعاني من دوار الحركة يحتاج إلى إيقاف هذه الرسوم، وتجاهُل ذلك مشكلة إتاحة وصول حقيقية لا تفصيلة ذوق.

ولماذا يهمّ هذا لمؤشر التفاعل؟

هناك مكسب غير متوقّع. كثير من المواقع كانت تحقّق انتقالات مشابهة بمكتبات رسوم تعمل على الخيط الرئيسي — وهو الخيط نفسه المسؤول عن الاستجابة للنقرة. النتيجة كانت تدهوراً في مؤشر التفاعل حتى الرسم التالي (INP)، أحد مؤشرات تجربة الصفحة التي يقيسها جوجل.

الانتقال الأصلي لا يمرّ من هناك: المتصفّح يديره بنفسه، والصفحات متعدّدة المستندات لا تحتاج جافاسكربت أصلاً. أي أنك تحذف مكتبة من الحزمة، وتحسّن مؤشراً، وتحصل على تجربة أجمل — الثلاثة معاً، وهو أمر نادر.

Interop 2026: لماذا لم يُغلق الملف بعد

انتقالات العرض كانت ضمن مجالات تركيز مبادرة Interop لعام 2025، وهي الجهد السنوي المشترك بين آبل وجوجل ومايكروسوفت وموزيلا وIgalia لتقليص فروقات التنفيذ بين المحرّكات. أنهى سفاري ذلك العام بنتيجة تتجاوز 99% في هذا المجال تحديداً، لكن النتيجة الإجمالية عبر المحرّكات بقيت حول 90%.

لذلك قرّر الفريق ترحيل الملف إلى Interop 2026 مع توسيع نطاقه ليشمل الانتقالات عبر المستندات صراحةً. الرسالة الضمنية واضحة: الميزة مهمة بما يكفي ليُصرّ الجميع على إتمامها، ولم تكتمل بعد.

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

خطة تبنٍّ لا تندم عليها

1. ابدأ بموقع متعدّد الصفحات لا بتطبيق صفحة واحدة — هنا المكسب الأكبر مقابل أقل كود.
2. فعّل الانتقال الافتراضي أولاً (تلاشٍ بسيط) وانشره. لا تبدأ بمشهد معقّد.
3. أضف view-transition-name لعنصر واحد مميّز فقط — صورة المنتج مثلاً — وتأكّد أن الاسم فريد.
4. اختبر على فايرفوكس عمداً: هل تبدو التجربة مقبولة تماماً بلا أي حركة؟ إن لم تكن، فتصميمك يعتمد على الحركة أكثر مما يجب.
5. اربط كل شيء بـprefers-reduced-motion قبل النشر لا بعده.

أسئلة شائعة

هل أحتاج إطار عمل أو مكتبة لتفعيل الانتقال بين الصفحات؟

لا. في المواقع متعدّدة الصفحات يكفي إعلان @view-transition في CSS على الصفحتين، بلا سطر جافاسكربت واحد. المكتبات صارت لازمة فقط للمشاهد المعقّدة أو للتحكّم الدقيق في التوقيت.

ماذا يحدث لزائر فايرفوكس اليوم؟

يتصفّح الموقع بالطريقة المعتادة تماماً: الصفحة تتغيّر بلا رسوم انتقالية. لا رسالة خطأ ولا سلوك غريب — المتصفّح ببساطة يتجاهل القاعدة التي لا يعرفها.

هل تؤثّر هذه الانتقالات على ترتيب الموقع في البحث؟

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

الخلاصة

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