HTML5 Boilerplate vs. HTML5 Reset

Question

Salut tout le monde - HTML5 Boilerplate et Réinitialisation HTML5 sont deux modèles HTML, CSS et JavaScript intégrant un grand nombre de bonnes pratiques modernes. Leurs objectifs sont en grande partie les mêmes :

• Développement Web rapide, robuste et moderne
• HTML5 (bien sûr !)
• Normalisation inter-navigateurs (y compris la prise en charge d'IE6 et des navigateurs mobiles)
• Amélioration progressive et dégradation progressive
• Optimisation des performances
• Pas un cadre, mais le point de départ de votre prochain projet

De toute évidence, leurs fonctions sont très similaires. En quoi leurs implémentations sont-elles différentes (par exemple, les corrections CSS spécifiques à IE sont peut-être réalisées à l'aide de techniques différentes) ? Sont-ils du tout différents en termes de portée ? Il semble que HTML5 Boilerplate soit un peu plus large (outils de construction, configuration du serveur, etc.), mais il est difficile de savoir où il va au-delà de HTML5 Reset lorsqu'il s'agit du site réel que les gens verront.

Answer 1

En général, les deux projets visent à fournir un point de départ solide aux développeurs travaillant sur des projets Web. Ils permettent de se débarrasser d'une grande partie du texte passe-partout fastidieux et source d'erreurs que de nombreux développeurs se retrouvent à recréer pour chaque projet. Les détails de leur démarche sont légèrement différents, mais pour l'essentiel, ils aboutissent aux mêmes résultats.

HTML5Boilerplate a, comme vous l'avez noté, ajouté quelques éléments de build-script pour aider les développeurs à suivre les meilleures pratiques pour accélérer leurs pages en termes d'éléments côté serveur, tels que les futurs en-têtes d'expiration, etc. alors que le projet HTML5Reset est plus axé sur la sémantique, le contenu et le style. Par exemple, HTML5Reset présente davantage d'exemples de structure pour le contenu de la page en HTML5 (pour aider à montrer aux gens comment utiliser certains des nouveaux éléments), alors que HTML5Boilerplate ne le fait pas.

Les éléments relatifs au temps de réponse et à la vitesse des pages que comprend HTML5Boilerplate sont de plus en plus importants, car de plus en plus d'utilisateurs se retrouvent sur des plateformes mobiles, et Google augmente l'effet les temps de réponse des pages ont sur le classement des pages . De nombreux articles montrent qu'une légère augmentation du temps de réponse des pages a un impact négatif mesurable sur la façon dont votre site est perçu. utilisés et perçus ( surtout dans un contexte de commerce électronique ...souvent une page plus lente de 100ms obtiendra un pourcentage moins élevé de choses vendues).

En ce qui concerne le CSS, la majorité de la section de style de réinitialisation pour les deux projets est très similaire, avec quelques différences mineures dans le réglage de la ligne de base. Les corrections spécifiques à IE, cependant, sont en grande partie les mêmes, HTML5Boilerplate affirmant un peu plus de contrôle que HTML5Reset sur la façon dont IE stylise certaines choses comme les éléments de formulaire (c'est-à-dire les cases à cocher / boutons radio et les états valide / invalide).

Les deux principaux domaines CSS que HTML5Boilerplate couvre et que HTML5Reset ne couvre pas sont les classes d'aide communes qui permettent de rendre les sites plus accessibles, telles que .hidden et .visuallyhidden Il s'agit de rendre l'impression plus similaire d'un navigateur à l'autre, ainsi que de réaliser des économies et d'améliorer l'accessibilité, par exemple en rendant les images d'arrière-plan transparentes (pour ne pas gaspiller l'encre) et en ajoutant l'URL réelle aux liens et le titre aux abréviations.

Je vous conseille vivement de lire les informations sur les deux projets et de les comparer côte à côte, car les similitudes, mais aussi les différences (et le raisonnement qui les sous-tend) sont très instructives et m'ont aidé à mieux décider quelles parties de chaque projet je voulais utiliser.

En fin de compte, comme pour tout projet de type "bibliothèque", vous devez, en tant que développeur, comprendre ce que vous faites et probablement ajuster votre base de référence pour répondre aux besoins particuliers du projet.

Answer 2

Je travaille dans un environnement où les développeurs précédents ont forcé l'entreprise à utiliser les deux types d'outils. JQuery et Prototype ...et c'est le bordel. Non seulement nous devons travailler hors du mode de compatibilité, mais il suffit de penser aux frais généraux supplémentaires que cela entraîne. Lors du débogage, Prototype "détourne" les messages de débogage dans Firebug, ce qui entraîne encore plus de travail. Et ce qui est le plus exaspérant, c'est que j'ai passé des mois à défaire ce fouillis et que je commence tout juste à en avoir fini avec lui.... et juste au moment où je suis sur le point de tirer un trait sur Prototype, il semble que je trouve toujours une autre section qui en dépend...

C'est pour cette raison que je plaide à chaque fois contre les combinaisons de cadres qui ont des objectifs similaires. Par exemple, peu importe à quel point vous pouvez penser que Grilles YUI c'est que, si vous chargez la totalité Cadre de travail YUI il vaut mieux ne pas faire de Jquery, Moo ou Prototype. Vous ne feriez que vous embourber inutilement. Cela tue le temps de chargement (qui détruit l'expérience de l'utilisateur ) et ne fait que donner aux développeurs des maux de tête et du travail inutile.

Considérez cette phase de votre site comme la construction des fondations. Vous avez la possibilité d'utiliser tout ce que vous voulez, mais vous devez faire attention à ne pas vous mettre dans un coin, pour ainsi dire. Utilisez donc les outils les mieux conçus et les plus performants disponibles en fonction de vos ressources. N'utilisez pas quelque chose pour faire joli ! Nous avons la chance que de nombreux outils de très haute qualité soient gratuits, ce qui nous laisse le choix. Mais sachez que vous orientez l'avenir de votre site et que vous serez peut-être la personne qui, comme moi, devra faire face aux conséquences de vos décisions hâtives.

Donc, à moins que vous n'ayez JAMAIS l'intention d'utiliser un autre framework, je recommande Reset... ou même simplement de faire du CSS conforme aux normes de qualité supérieure.

Answer 3

Vous pouvez utiliser l'un ou l'autre...

Comme @murtaugh l'a dit (http://5by5.tv/bigwebshow/45), vous n'avez pas besoin d'apprendre quoi que ce soit lorsque vous commencez avec Reset. D'après mon expérience, je travaille dans un département R&D, lorsque vous avez besoin de faire une démonstration ou des itérations rapides, vous pouvez utiliser Reset (ou Boiler si vous le connaissez déjà). Lorsque j'ai besoin de construire le produit pour le déploiement, je me tourne vers Boiler simplement parce qu'il y a plus de choses. Cela fonctionne pour moi, mais maintenant que je connais les deux, je peux facilement utiliser l'un ou l'autre.

Answer 4

En fait, j'ai presque envie de dire que l'utilisation de la traditionnelle reset.css est la meilleure... Je ne rencontre aucun problème de compatibilité dans mes applications mobiles. Cependant, je développe ces applications à l'aide du framework jQuery mobile.

Je suppose donc que tout dépend du type d'outils que vous utilisez. Phonegap ne semble pas avoir de problèmes pour compiler mon code dans tous les OS. Et l'affichage de mon code source dans les émulateurs semble parfaitement correct...

Je ne vois donc pas vraiment l'intérêt d'un boilerplate, sauf si l'on cherche à réaliser des polyfills.