Un peu de lecture pour partager des idées
7studio opened this issue · 1 comments
Bonjour,
je suis ravi de pouvoir échanger avec vous sur des conventions/bonnes pratiques de développement.
Avant de commencer, félicitations pour cette initiative qui demande beaucoup de motivation et de temps.
Workflow
Versions des dépendances
Je ne sais pas si ça a raison d'être dans des guidelines mais npm semver calculator est vraiment très pratique pour savoir ce que l'on fait avec les numéros de version.
HTML
Avant d'attaquer, je voudrais savoir pourquoi vos guidelines HTML parlent de choses que vous n'utilisez plus (ex. : Classes conditionnelles) ? 😕
Même s'il est clairement identifié que vous n'employez plus ces méthodes pour chaque point, cela amène quand même une confusion dans la lecture.
Ces points ne devraient-ils pas être regroupés à la fin du document dans une même rubrique spéciale : "Support IE 10 et inférieur" ?
Passons aux questions intéressantes 😄
Généralités
Même si par le passé, faire disparaître le protocole dans les liens absolus a été un modèle à suivre,
cela semble maintenant être reconnu comme une "mauvaise pratique" par certains : h5bp / html5-boilerplate/ deprecate protocol relative URLs.
Il y a certainement une bonne raison derrière votre choix 😊 et je suis curieux de savoir.
Liens d’évitement
Je sais que les vieilles habitudes sont les plus dures à oublier mais je pense qu'il est temps de passer un bon coup de balai sur left: -9999px !
left: -100vw me semble une solution plus actuelle et donnera plus de sens à l'action qui est faite avec cette déclaration 😁
Microdata
L'utilisation des données structurées est une très bonne chose. Par contre, pour espérer un quelconque résultat il vaudrait mieux recommander de suivre les bénédictions de "dieu" Google sur les propriétés obligatoires (qui changent régulièrement 😒).
Google parle de tout ça dans sa doc ici et Bing a essayé de proposer aussi quelque chose mais bon : données, chemin de fer.
Pour compléter cette section, il serait peut être intéressant de faire un lien vers l'outil de test des données structurées proposé par Google comme cela est fait pour les Twitter Cards un peu plus loin.
Note perso :
Après plusieurs utilisations sur différents projets, je trouve que l'application de microdonnées vient parfois/souvent alourdir le markup HTML pour pas grand chose (hors chemin de fer) 😔 Inévitablement cela augmentera également le temps de développement et de saisie pour une gestion parfaite de schémas imbriqués (ex. : Event + Location).
Google nous promet beaucoup de chose en mettant en avant le format JSON-LD mais malheureusement je n'ai obtenu aucun résultat avec celui-ci…
L'immense avantage du dictionnaire schema.org reste qu'il offre une très bonne convention de nommage pour toutes les classes HTML sans prise de tête 😄
Meta spécifiques - SEO et réseaux sociaux
En tant qu'intégrateur feignant (ou peut être perfectionniste), je voulais relever que tous les <meta> qui sont listés ne sont pas obligatoires 😁
En effet, Twitter fait un fallback sur l'Open Graph s'il ne trouve pas ses propres données (cf. : Twitter Cards and Open Graph). Du coup, on se retrouve avec :
<!-- Le minimum syndical -->
<meta property="og:type" content="website">
<meta property="og:locale" content="language_TERRITORY">
<meta property="og:url" content="">
<meta property="og:site_name" content="">
<meta property="og:title" content="">
<meta property="og:description" content="">
<meta property="og:image" content="">
<!-- Facebook -->
<meta property="og:image:width" content="">
<meta property="og:image:height" content="">
<!-- Twitter Card -->
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@">
AMA il serait bon de rajouter une note pour expliquer que la valeur de og:title (valable pour twitter:title) ne doit/devrait pas être la même que celle de l'élément HTML <title>. Je ne l'invente pas, c'est Facebook qui le recommande dans ses bonnes pratiques.
Pour les utilisateurs de WP, je vous conseillerais de renseigner votre champ "Facebook Titre" pour ne pas vous retrouver dans ce cas 😒
Même si cela ne fait pas parti de vos guidelines, j'ai pu relever pendant mes tests que LinkedIn ne parsera pas l'Open Graph sans prefix="og: http://ogp.me/ns#" 😕
Pour compléter le Twitter Card Validator, voici deux autres outils permettant de valider l'Open Graph pour Facebook et pour Pinterest.
CSS
En lisant, toute la partie concernant CSS, il me semble évident que stylelint va rapidement intégrer votre workflow 😊
Généralités
J'ai vraiment du mal à croire qu'on utilise toujours le validateur W3C 😁 mais pourquoi pas.
Ne serait-il pas bon d'informer que cette validation doit se faire avant de préfixer le code ? Ou alors que les avertissements peuvent être oubliés ?
Si je ne me trompe pas, le validateur va émettre un avertissement pour chaque propriété préfixée…
Préfixes navigateurs
Sans langue de bois, je trouve cette partie sans grand intéret. Autoprefixer faisant parti du workflow de base, aucun fichier source ne devrait contenir de prefixes.
Intervalles de z-index
Loin de moi l'envie de troller, mais les intervalles me semblent disproportionnés. Un intervalle en 10 ou 100 serait largement suffisant 😐
Voici un article de Thierry Koblentz pour un avis supplémentaire : Managing Stacking Contexts in a "hostile" environment.
De plus, si on considère la note de traduction de Vincent De Oliveira dans son excellente traduction Comprendre z-index et les contextes d'empilement, je ne pense pas
qu'appliquer ce genre de règles serve vraiment à résoudre les conflits de chevauchements.
Je pense que Raphaël a dû bien réfléchir en prenant cette décision mais en maîtrisant les contextes d'empilement dans ses projets, on a rarement besoin de savoir compter jusqu'à 20 😉
WordPress
Tout est là non ? 😜
En espèrant que certains de ces points vous intéresseront 
Hello Xavier, voilà de belles pistes de réflexion en effet. Un grand merci !