سؤال

مثل العديد من المطورين الذين يعملون على مواقع الويب لبرنامج Internet Explorer، يبدو أنني صادف الكثير من الأخطاء التي تسببها سيئة السمعة hasLayout علم.

أنا أفهم ما يفعله هذا العلم وكيف يعمل (بالنسبة للجزء الأكبر). تفسير جيد قرأته في اليوم الآخر (على الرغم من أنني لا أستطيع العثور على المصدر) هو ذلك hasLayout في IE يعني أساسا "جعل هذا العنصر مستطيل".

من الواضح أنها أكثر تعقيدا من ذلك، لكنها تلخص جيدا مع ذلك (في رأيي).

ما لا أفهمه هو السبب في أن المتصفح يستخدم هذا العلم. عند البحث عن إجابة، وجدت واحدة بدا منطقية:

كان على Internet Explorer التعامل مع قانون قديم قديم من قبل CSS كان حقا على قدم وساق. كقرار معماري لجعل المتصفح سهل لإضافة CSS إليه، hasLayout تم استخدام العلم لتحريك بعض خصائص CSS حتى يتم تقديم الصفحة بشكل صحيح. هذا التواريخ العودة إلى حوالي وقت IE4.

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

رؤية كيف hasLayout العلم هو مصدر الكثير من الأخطاء في Internet Explorer، هل يعرف أي شخص لماذا لا يحتاج هذا العلم والمتصفحات الأخرى إلى ذلك؟

هذا شيء أود أن أعرف بحتة من الفضول إذا كان لدى أي شخص أي نظريات أو يحدث لمعرفة الإجابة. أود أن أفهم المزيد حول لماذا (أو لماذا لا) هذا العلم مفيد.

هل كانت مفيدة؟

المحلول

تم إعادة كتابة Netscape Renderer بالكامل بعد NS4. لم يحظ محرك تقديم "ترايدنت" في هذا الحب. هذه جعل شعور العمل الجيد - أي استمرار التحسن بشكل تدريجي بينما تم إعادة كتابة NS، وجزئيا بسبب هذا (وجزئيا بسبب ترتيب التوزيع الخاص به ... تمكن من التقاط حصة ضخمة من السوق ...

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

الآن، أن النقطة الأخيرة هي مفتاح: يعد برنامج Renderer للمتصفح تجريقا، مما يتيح لك إنشاء في خطوط بضعة أسطر توضياف شيء من شأنه أن يستغرق المئات أو الآلاف من خطوط التردد المنخفض المستوى وتعويض الأحداث. ومثل كل التجريدات البرمجة، فإنها تسرب قليلا ... هذا صحيح بالنسبة ل IE، Netscape، Firefox، Opera، WebKit ... وكل متصفح لديه المطورين يعملون بشكل محموم لفصل التسريبات في التجريدات. إلا، لمدة خمس سنوات، أي لم يفعل ذلك. آخر تم توصيل التسريبات، لكن محرك التقديم أصبح أكثر فأكثر مثل الغربال.

معا، هذه للعوامل تتآمر لفضح أشياء مثل hasLayout.

نصائح أخرى

من الصعب جدا معرفة ذلك دون أن تكون قادرا على إلقاء نظرة على شفرة المصدر الخاصة بهم.

الروابط التالية هي الأكثر إعلانية وجدت حتى الآن:

أول واحد يقتبس وثيقة قديمة تحتوي على جملة ممتعة للغاية:

داخليا، وجود تخطيط يعني أن العنصر مسؤولا عن رسم محتواه الخاص.

والثاني يقول:

يبدو أن نموذج الكائن داخل Explorer هو مختلفي لنموذج المستند ونموذج التطبيق التقليدي الخاص بهم.

وضع حد سواء معا، تخميني هو أن العناصر مع hasLayout في الواقع، ويندوز في Win32 API Sense - أي الأشياء CreateWindow يتعامل مع. العناصر دون hasLayout ثم ليس لديك "نافذة" الخاصة بهم، ولكن يتم رسمها من قبل الأقرب hasLayout- الجديل، باستخدام نوع من رمز التخطيط (مثل فصول تخطيط QT إلى حد ما). نظرا لأن "النوافذ" الحقيقية فقط لديها رمز التخطيط (الذي يرسم خفض التخطيط الخاص به)، فهي تلك التي "لها تخطيط"، لذلك hasLayout.

إذا كان هذا هو الحال، فسيكون هناك رمز تخطيط مسارات رمز مختلفا (واحد ل hasLayout, ، والتي يجب أن تضع "Windows" حتى يتم استخلاصها لاحقا باستخدام نظام رسم النافذة العادي، والذي يرسم أطفال hasLayout "نافذة" باليد أثناء رسم "النافذة"). نظرا لأن جميع الكود يحتوي على أخطاء (وتقول أدلة anedoctal IE <= 6 لديه أكثر من المتوسط)، فستكون كلاهما مسارات التعليمات البرمجية مختلف الأخطاء، شرح لماذا إضافة أو إزالة hasLayout (يؤدي التبديل الفعال إلى مسار التعليمات البرمجية الأخرى) إلى تغيير مجموعة الأخطاء التي تؤثر على العنصر المعني. ليس فقط ذلك، ولكن نظرا لأن لديك مسارين رمز يعملان في نفس المستند، فإن اكتساح من كل مسارات الكود ستكون مصدرا غنيا آخر للحشرات الدقيقة.

ربما تجنب المتصفحات الأخرى المشكلة ببساطة باستخدام بنية لا تحتوي على مسار تخطيط مزدوج.

إذا كان تخميني صحيحا، أود أن أقول أنه إذا استخدمت أداة لإظهار كل الأطفال، فإن المستعرض يستخدم، فستكتشف أن كل مرئي hasLayout عنصر لديه واحد، في حين أن عناصر تخطيط أقل لا تملك واحدة.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top