Html5-boilerplate: النظر في استخدام HTMLLinter؟

كيف سيتم اختيار القواعد المستخدمة؟ بعض القواعد القياسية هي حقًا تفضيل شخصي. فمثلا:

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-double-quotes كلاهما صالح تمامًا HTML5 ولا أعتقد أن هذا النموذج يجب أن يختار النمط الذي يجب أن يكون الافتراضي.

https://github.com/yaniswang/HTMLHint/wiki/Tag-self-close كلاهما صالح HTML5 ، والأخير هو في الواقع الطريقة الأكثر حداثة للقيام بذلك كما هو سابق لـ XHTML ويسمح به في HTML5 للتوافق مع الإصدارات السابقة عند الترحيل من XHTML إلى HTML5 على حد علمي.

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-not-empty كلاهما صالح والأخير هو ما يستخدمه معظم الناس ، لكنه يعتبر طريقة سيئة.

الكثير من هذه القواعد مشكوك فيها وقد تتسبب في تمييز أجزاء من النموذج المعياري على أنها أخطاء أو تحذيرات. نتيجة لذلك ، أنا ضد إضافة هذا وأفضل ترك هذه التفضيلات للمطور وعدم تجميعها مع هذا المشروع. ربما تضيف قسم HTML linter إلى المستندات وتوفر روابط إلى linters مختلفة؟

quantumpacket كما ذكرت tag-self-close هناك دائمًا بعض المبررات على الأقل لاختيار أحدهما على الآخر وليس هنا حيث يمكن للمجتمع أن يزن تمامًا كما يمكنه على محتويات النموذج المعياري؟ في حالة عدم وجود مبرر ، فإننا ببساطة لا نضيف تلك القاعدة. كمرجع إذا نظرنا إلى جميع أنماط الكود لـ JS https://github.com/rcorp/standard-project-structure/issues/6 خاصة AirBNB ، يمكننا أن نرى أن هناك الكثير من القواعد ولكن كل منها لديه المنطق الذي سيقدره المطور.

لقد فهمت وجهة نظرك تمامًا ، لكن هذه مجرد قواعد. لا يتم فرض الأشياء التي لا نختارها. لذلك يمكن أن يكون نهجًا متساهلًا للغاية. ونموذج معياري للمطورين لإضافة / إزالة القواعد من .htmlhintrc

@ gaurav21r آسف لترك هذا باقية. أعتقد أن هذه ستكون فكرة جيدة. (هل أردت أن تقترح واحدة مع العلاقات العامة؟ سأضع علامة على هذه المساعدة المطلوبة في الوقت الحالي.)

بالنسبة للقيم التي يجب اختيارها ، ستكون نقطة البداية واضحة من المشروع نفسه. في حالة الأمثلة quantumpacket shared- نستخدم علامات الاقتباس المزدوجة ونستخدم سمات فارغة ولا نغلق ذاتيًا. من هناك ، أنا متأكد من أن الناس سيكون لديهم آراء.

roblarsen نود المساهمة في العلاقات العامة. لقد اخترنا بالفعل قاعدة بداية جيدة لمجموعة القواعد. https://github.com/rcorp/standard-project-structure/issues/13

انها تستخدم من قبل اثنين من المنظمات الكبيرة. سأرى ما إذا كانت تتطابق مع النموذج المعياري وليس لها رأي كبير. الباقي يمكننا مناقشته في العلاقات العامة نفسها!

أي تقدم في هذه المسألة؟

@ gaurav21r أي تحديث؟ إذا كانت الإجابة "لا" ، هل يريد أي شخص آخر أن يطعن في هذا؟

roblarsen إذا حدث أن @ gaurav21r غير قادر على المتابعة ،

AlexxNica تبدو جيدة. نحن دائما نحب المساعدة.

آسف للرد المتأخر جدا! roblarsenAlexxNica سيحاول القيام بذلك عن طريق 15. إذا لم يكن الأمر كذلك ، فسيسعدنا مساعدة من هو!

لا داعى للقلق!

الخامس عشر أتى وذهب! هذا مفتوح لمن يريد أن يحاول القيام بذلك!

هل نحن على يقين من أن HTMLHint هو الخيار الأفضل المتاح؟

AlexxNica ليس لدي أي خبرة في هذا المجال ، لذلك أنا على طول الطريق. يمكن لمن يريد أن يتولى هذا الأمر فتح بعض المناقشة هنا وسأبذل قصارى جهدي لتقديم الملاحظات كما هو مطلوب ، ولكن هذا بالتأكيد شيء في أيدي المجتمع.

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

· هل هو مفيد بما يكفي لتبرير الحاجة إلى التنفيذ؟
هل من السهل الإرسال والصيانة؟
· هل تم اختبارها من قبل شخص / نحن؟
· هل نرى تحسنًا حقيقيًا مقارنة بالنموذج الفعلي؟
· هل أجرينا الاختبارات وفقًا للكود الخاص بنا لمعرفة ما إذا كان علينا تغيير أي شيء حتى نتوافق مع المحلل؟ (حتى لا يتعثر المستخدمون مع وجود أخطاء على الشاشة أكثر مما يمكن أن تعرضه الشاشة)
· هل سيكون لها وجود طويل الأمد؟ (لا أعتقد أنه من الجيد تنفيذ شيء لن يكون موجودًا لفترة زمنية طويلة)
· ما هي سهولة استخدامه؟

roblarsen هل يمكنك التفكير في تغيير الملصقات على هذا؟ أعتقد أن " awaiting feedback " و (ربما) " HTML " سيكونان أكثر ملاءمة.

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

أعتقد أن هناك سؤالين هنا:

• هل يجب تضمين .htmlhintrc في مجلدات src / dist للمستخدمين؟
  الغرض من HTMLHint فقط هو استخدامه لفحص صفحات HTML الكاملة والمترجمة (على سبيل المثال ، كن افتراضيًا ، فإنه يتحقق من أن كل ملف يحتوي على علامة <title> لذلك فهو غير مناسب حقًا لمعظم لغات جانب الخادم أو النماذج. لذلك أعتقد أنها ذات قيمة محدودة لأن العديد من المستخدمين يستخدمون Angular أو React أو PHP أو ASP أو لغات قوالب مثل Liquid حيث إما أنها ستعطي العديد من الأخطاء أو لا تعمل على الإطلاق. يمكن للمستخدم تحرير جميع القواعد لجعلها لا تعرض الأخطاء ولكن بعد ذلك ، فإن هذا النوع من الضبط يلغي الغرض من تضمينه. وسيحتاج جميع المستخدمين إلى تثبيت مكون إضافي لـ IDE الخاص بهم حتى يتمكنوا من استخدامه. لا أعتقد أن عددًا كافيًا من المستخدمين يقومون بترميز صفحات الويب بتنسيق HTML خالص بدون تضمين تضمينه (أنا شخصياً أستخدم HTMLHint فقط عند ترميز رسائل البريد الإلكتروني بتنسيق HTML - وهو أمر رائع للعثور على الأخطاء) - ولا نقوم بتضمين أي ملفات تكوين JS أو CSS linters / hinter.

• هل يجب تضمين HTMLHint في نظام الإنشاء للتحقق من وجود أخطاء؟
  نعم ، أعتقد أن هذه قد تكون فكرة جيدة. يستخدم نظام البناء الخاص بنا حاليًا Gulp وهناك حزمة NPM ليتم دمجها: https://www.npmjs.com/package/gulp-htmlhint. سأبحث في هذا خلال الأيام القليلة القادمة. قد يتحقق هذا من وجود أخطاء HTML عند التجميع وقد يكون مفيدًا في العثور على المشكلات قبل نشر الموقع.

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

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

راجع للشغل ، لا أرى أسبابًا لاستخدام Gulp لمثل هذه المهام التافهة. من الأسهل والأكثر موثوقية دائمًا تجنب الطبقات الإضافية للنُسالة واستدعائها مباشرة من npm test (انظر المثال ).

IMO ، يجب عليك الابتعاد عن الأدوات غير القياسية.

يبدو الأمر كما لو أنك لا تستخدم أي مدقق على الإطلاق ، وأنا أتحدث من التجربة منذ ذلك الحين في Bootstrap v4-dev قاموا بالتحويل إلى htmlhint الذي لم يكتشف أي أخطاء حقيقية.

اقتراحي هو استخدام أداة التحقق الرسمية vnu.jar على الرغم من أنها تتطلب Java. يمكن أن يكون لديك برنامج نصي مجمّع يقوم بتشغيله إذا كانت Java متوفرة.

لقد أجريت تغييرًا مشابهًا مؤخرًا في Bootstrap (راجع https://github.com/twbs/bootstrap/pull/24149) لأنني كنت منزعجًا من حقيقة أننا كنا في الأساس بدون أي تحقق من صحة htmlhint.

للأسف ، لم يعد يتم الاحتفاظ بـ HTMLHint بنشاط (https://github.com/yaniswang/HTMLHint) وكما تقول

صراصير الليل + ما سبق