هل هو مقبول لـ XHTML غير الصالح؟
https://stackoverflow.com/questions/3448
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد لاحظت أن الكثير من المواقع، بما في ذلك، تستخدم XHTML كلغة ترميزية ثم تفشل في الالتزام بالمواصفات.مجرد تصفح المصدر لـ SO هناك علامات إغلاق مفقودة للفقرات والعناصر غير الصالحة وما إلى ذلك.
فهل يجب على الأدوات (والمطورين) استخدام مستند XHTML إذا كانوا سينتجون علامة غير صالحة؟وهل ينبغي للمتصفحات أن تكون أكثر صرامة في قبولها للعلامات الضعيفة؟
وقبل أن يصرخ أي شخص منافقًا، تحتوي مدونتي على جزء واحد من العلامات غير الصالحة التي تتضمن رمز captha (أو حدث ذلك في آخر مرة قمت فيها بالتحقق) والتي تتضمن تصميم علامة noscript.
المحلول
هناك أسباب عديدة لاستخدام علامات صالحة.المفضل لدي هو أنه يسمح لك باستخدام التحقق من الصحة كشكل من أشكال اختبار الانحدار، مما يمنع العلامات المكافئة لـ "تعفن دلتا" من التسبب في مشاكل عرض حقيقية بمجرد وصول الأخطاء إلى كتلة حرجة.وفي الحقيقة، من الخطأ السماح بتراكم الأخطاء "الكسولة" مثل الأخطاء المطبعية والعلامات المتداخلة/غير المغلقة.العلامات الصالحة هي إحدى الطرق لتحديد الهوية المبرمجين عاطفي.
هناك أيضًا مشكلة تصحيح الأخطاء:يمنحك الترميز الصالح أيضًا خطًا أساسيًا ثابتًا يمكنك من خلاله العمل على مشكلات التوافق الحتمية عبر المتصفحات.لا ينبغي لأي مطور ويب يقدر وقته أن يبدأ في تصحيح مشكلات توافق المتصفح دون التأكد أولاً من أن العلامات على الأقل نحويا صالح — وأي ترميز آخر غير صالح يجب أن يكون له سبب وجيه لوجوده هناك.
(بالمناسبة، فشل موقع stackoverflow.com في كل من هذه الاختبارات والاقتراحات لإصلاح المشكلات كان انخفض.)
بعد كل ما قيل، للإجابة على سؤالك المحدد، ربما لا يكون من المفيد استخدام أحد أنواع مستندات XHTML إلا إذا كنت تخطط لإنتاج صالح (أو في الأقل جيدة التشكيل) الترميز.المزايا الأساسية لـ XHTML مستمدة من حقيقة أن XHTML هي XML، مما يسمح بمعالجتها وتحويلها بواسطة الأدوات والتقنيات التي تعمل مع XML.إذا كنت لا تخطط لإنشاء XML الخاص بك بشكل جيد في XHTML، فلا فائدة من اختيار هذا النوع من المستندات.من المحتمل أن تقوم أحدث مواصفات HTML 4 بكل ما تحتاجه، وهي أكثر تسامحًا.
نصائح أخرى
يجب أن نحاول دائمًا التحقق من صحتها وفقًا للمعايير.سنتأكد من أن موقع الويب سيُعرض ويعمل بشكل جيد على المتصفحات الحالية والمتصفحات المستقبلية.
لا أعتقد أنه إذا قمت بتحديد نوع مستند، فهناك أي سبب لعدم الالتزام بهذا النوع من المستندات.
يؤدي استخدام XHTML إلى تسهيل اكتشاف الأخطاء تلقائيًا، ويمكن التحقق تلقائيًا من كل تغيير بحثًا عن أي علامات غير صالحة.وهذا يمنع الأخطاء، خاصة عند استخدام المحتوى الذي تم إنشاؤه تلقائيًا.من السهل حقًا لمطور الويب الذي يستخدم محرك القوالب (JSP، ASP.NET StringTemplate، وما إلى ذلك) نسخ/لصق علامة إغلاق واحدة قليلة جدًا أو كثيرة جدًا.عندما يكون هذا هو خطأك الوحيد، يمكن اكتشافه وإصلاحه على الفور.لقد عملت ذات مرة في موقع يحتوي على 165 خطأ تحقق في كل صفحة، منها 2 أو 3 أخطاء فعلية.كان من الصعب العثور على هذه الأخطاء وسط فوضى الأخطاء الأخرى.كان من الممكن أن يمنع التحقق التلقائي هذه الأخطاء في المصدر.
وغني عن القول أن اختيار معيار والالتزام به لا يمكن أبدًا أن يفيد قابلية التشغيل البيني مع الأنظمة الأخرى (كاشطات الشاشة، وقارئات الشاشة، ومحركات البحث) ولم يسبق لي أن واجهت موقفًا لم يكن فيه حل XHTML الدلالي الصحيح مع CSS ممكنًا للجميع المتصفحات الرئيسية.
من الواضح أنه عند العمل مع أنظمة معقدة، ليس من الممكن دائمًا الالتزام بنوع المستند الخاص بك، ولكن هذا في الغالب نتيجة للتواصل غير المناسب بين الفرق المختلفة التي تعمل على تطوير أجزاء مختلفة من هذه الأنظمة، أو على الأرجح الأنظمة القديمة.في الحالة الأخيرة، ربما يكون من الأفضل عزل هذه الحالات وتغيير نوع مستندك وفقًا لذلك.
من الجيد أن تكون عمليًا ولا تلتزم بـ XHTML لمجرد أن شخصًا ما قال ذلك، بغض النظر عن التكاليف، ولكن مع المعرفة الحالية حول CSS والمتصفحات وأدوات الاختبار والتحقق من الصحة، تكون الفوائد في معظم الأحيان أكبر بكثير من التكاليف.
يمكنك القول إنني مصاب بالوسواس القهري فيما يتعلق بصلاحية XHTML.أجد أن معظم المشكلات المتعلقة بعدم صلاحية الكود تأتي من عدم معرفة المبرمجين الفرق بين HTML وXHTML.لقد كنت أكتب XHTML وCSS صالحين بنسبة 100% منذ فترة ولم أواجه أية مشكلات كبيرة في العرض مع المتصفحات الأخرى.إذا أبقيت كل شيء صالحًا، ولم تجرب أي شيء غريب جدًا في CSS، فستوفر على نفسك الكثير من الوقت في الإصلاحات.
لن أستخدم XHTML على الإطلاق فقط لإنقاذ نفسي من الضغط الفلسفي.لا يبدو أن أي متصفحات تتعامل معها مثل XHTML على أي حال.
سترفض المتصفحات الترميز السيئ إذا تم إرسال الصفحة بتنسيق application/xhtml+xml، ولكن نادرًا ما يحدث ذلك.هذا جيد.
سأكون أكثر قلقًا بشأن أشياء مثل الاستخدام المضمن لـ CSS وJavaScript مع Stack Overflow، فقط لأنها تجعل الصيانة أكثر صعوبة.
على الرغم من أنني أؤمن بالسعي للحصول على XHTML وCSS صالحين، إلا أنه غالبًا ما يكون من الصعب القيام بذلك لعدد من الأسباب.
- أولاً، يمكن تحميل بعض المحتوى عبر AJAX.في بعض الأحيان، لا يتم إدراج الأجزاء بشكل صحيح في DOM الموجود.
- ربما لم يتم إنتاج HTML الذي تشاهده في نفس المستند.على سبيل المثال، يمكن أن تتكون الصفحة من مكونات أو قوالب، ثم يتم تجميعها معًا قبل أن يعرضها المتصفح مباشرةً.وهذا ليس عذرًا، ولكن لا يمكنك افتراض أن HTML الذي تراه تم ترميزه يدويًا مرة واحدة.
- ماذا لو كانت بعض التعليمات البرمجية التي تم إنشاؤها بواسطة Markdown غير صالحة؟لا يمكنك إلقاء اللوم على Stack Overflow لعدم إنتاج كود صالح.
- أخيرًا، الغرض من DOCTYPE ليس مجرد القول "مرحبًا، أنا أستخدم رمزًا صالحًا" ولكنه أيضًا إعطاء المتصفح تنبيهًا لما تحاول القيام به حتى يتمكن على الأقل من الاقتراب من التحليل بشكل صحيح تلك المعلومات.
لا أعتقد أن معظم المطورين يحددون DOCTYPE ثم يفشلون صراحةً في الالتزام به.
على الرغم من أنني أتفق مع عبارة "إذا أصبح الأمر جيدًا، فلا تقلق بشأن ذلك"، إلا أنه من الجيد اتباع معيار ما، على الرغم من أنه قد لا يكون مدعومًا بشكل كامل في الوقت الحالي.لا يزال بإمكانك استخدام الجدول للتخطيط، لكنه ليس جيدًا لسبب ما.
لا، يجب ألا تستخدم XHTML إذا كنت لا تستطيع ضمان حسن الصياغة، وعمليًا لا يمكنك ضمان ذلك إذا كنت لا تستخدم مُسلسل XML لإنشاء العلامات.يقرأ حول إنتاج XML.
حسن التكوين هو ال الشيء الذي يميز XHTML عن HTML.يتوقف XHTML الذي يحتوي على خطأ ترميزي "واحد فقط" عن XHTML. يجب أن تكون مثالية في كل مرة.
إذا بدا أن موقع "XHTML" يعمل مع بعض الأخطاء، فذلك بسبب تتجاهل المتصفحات DOCTYPE وتفسير الصفحة كـ HTML.
يرى وكيل XHTML الذي يفرض تفسير الصفحات كـ XHTML.معظم الوقت لقد فشلوا فشلا ذريعا.وهذا هو أحد الأسباب التي تجعل مستقبل XHTML غير مؤكد لماذا تم استئناف تطوير HTML.
هذا يعتمد.كان لي ذلك مشكلة مع مدونتي حيث تسبب مقطع فيديو على YouTube في XHTML غير صالح، لكنه أصبح جيدًا.من ناحية أخرى، لدي رابط "Valid XHTML"، والجمع بين مطالبة "Valid XHTML" وXHTML غير الصالح ليس احترافيًا.
نظرًا لأن SO لا يدعي أنه صالح، أعتقد أنه مقبول، ولكن شخصيًا إذا كنت مكان جيف فسوف أشعر بالانزعاج وأحاول إصلاحه حتى لو كان يبدو جيدًا في المتصفحات الحديثة، ولكن بعض الأشخاص يفضلون المضي قدمًا وإنجاز الأمور بالفعل بدلاً من إصلاح الأخطاء غير الموجودة.
طالما أنه يعمل في IE وFF وSafari (أدخل متصفحًا آخر هنا) فيجب أن تكون على ما يرام.لا يعد التحقق من الصحة بنفس أهمية عرضه بشكل صحيح في متصفحات متعددة.فقط لأنها صالحة، لا يعني أنها ستعمل في IE بشكل صحيح، على سبيل المثال.
قم بتشغيل Google Analytics أو ما شابه ذلك على موقعك وتعرف على نوع المتصفحات التي يستخدمها المستخدمون لديك، ثم حدد المتصفحات التي تحتاج إلى دعمها أكثر والقلق بشأن المتصفحات الأقل أهمية عندما يكون لديك وقت فراغ للقيام بذلك.
أقول، إذا تم عرضه بشكل جيد، فلا يهم إذا كان بكسلًا مثاليًا.
يستغرق الأمر بعض الوقت لإعداد الموقع وتشغيله بالطريقة التي تريدها، وسيؤدي الرجوع وإجراء التغييرات إلى تغيير الطريقة التي تظهر بها الصفحة قليلاً، ثم يتعين عليك الإصلاح أولئك مشاكل.
الآن، أنا لا أقول أنه يجب عليك إنشاء صفحات ويب قذرة، لكنني لا أرى أي سبب لإصلاح ما لم يتم كسره.لن تقوم المتصفحات بإسقاط الدعم لتصحيح الأخطاء في أي وقت في المستقبل القريب.
لا أفهم سبب انشغال الجميع بمحاولة جعل مواقع الويب الخاصة بهم متوافقة مع المعايير بينما لا تزال بعض المتصفحات تواجه مشكلات في عرض التعليمات البرمجية القياسية بشكل صحيح.لقد عملت في تصميم الويب لمدة 10 سنوات تقريبًا وتوقفت عن البرمجة المزدوجة (اقرأ:اختراق CSS)، وتغيير الأشياء الغبية حتى أتمكن من وضع زر على موقعي.
أعتقد أن استخدام <div> سيجعلك غير صالح بغض النظر، وسيصبح من الصعب جدًا القيام بأي JavaScript/AJAX رئيسي بدونه.
هناك الكثير من المعايير ويتم "تطبيقها" أو دعمها بشكل سيء للغاية لدرجة أنني لا أعتقد أن ذلك مهم.لا تفهموني خطأ، أعتقد أنه يجب أن تكون هناك معايير ولكن نظرًا لعدم تطبيقها، لا أحد يتبعها، وهي دوامة هبوطية هائلة.
بالنسبة إلى 99.999% من المواقع المتوفرة، لن يكون الأمر مهمًا حقًا.المرة الوحيدة التي كان الأمر فيها مهمًا، قمت بتشغيل إدخال HTML من خلال HTMLTidy إلى XHTML، ثم قمت بتشغيل المعالجة عليه.
إلى حد كبير، إنها بديهية المبرمج القديم:لا تثق بأي مدخلات.
